Hello and welcome to my little nock of the internet. Here I have my blog which mainly contain posts about tech, the outdoors, my journey as a PostDoc, cooking, and some times mead brewing.
A bit of background information before you step into my world of crazy. I am Lars, a.k.a. looopTools, a Software Engineer and PostDoc living in East Jutland, Denmark. My research focus on the application of generalised deduplication in real world storage systems. This includes the design, implementation, and evaluation of prototypes and more complex systems. I have 10+ years of experience from industry mainly through student positions, but also as self-employed consultant, or full-time employee. I mainly work in low-level user space, high-level kernel space, and storage systems in general. Besides research and software development, I also love the outdoors and try to go out as often as possible (not enough at the moment) and I am an aspiring author currently working on a few different novels. I also dabble in being a more advance home cook and baker, which you may see some posts about. Finally I like the ancient art of brewing mead, a.k.a. honey wine, and experiment with different flavour combinations and ageing times.
In my last post; Why I don’t think The Digital Markets Act will matter too much… for Apple. I talked about The Digital Markets Act and why I do not believe it will have an enormous effect on Apple overall. In that post, I mentioned the term sideloading [1,2], which is the main thing Apple seems to “fear” with the digital markets act. The reason Apple fears it (they claim) is the threat to the security and privacy of their customers. In particular, the latter is an area Apple has been championing for years to differentiate itself from Google and the likes. But is there any hold to these claims? Well, sort of yes, and in this blog post, I will outline what the threats (that I know of) are and why Apple is sort of right. Before we continue, I do like the intent of the digital markets act, and I do not like the monopoly Apple has on App distribution for iOS and iPadOS.
What is sideloading?
Sideloading is the approach of loading data (Apps, media, etc.) onto a device following none conventional ways or ways not approved by the device manufacturer. For iPhones and iPads, that could be installing an App without going through Apple’s App Store. Again for iPhones, an example of this is Cydia.
Sideloading on Android is quite common, and F-Droid has existed for a long time now, serving as an alternative to the Google Play store (or whatever Google/Alphabet calls it now). The scene is very different on iOS and iPadOS for the simple reason that it requires the user to jailbreak (see: Why I don’t think The Digital Markets Act will matter too much… for Apple which makes it significantly more challenging to sideload apps.
What is the problem with sideloading, and why Apple is sort of right?
Let us, for a second, imagine a world where iOS and iPadOS were more open and allowed for sideloading. What would be the issue with this? Well, nothing on the surface, really, not to the end-user, but Apple would lose money as they do earn a lot from the App Store. But below the surface, many problems can start to materialise, which can later be exposed to the end-user. What am I talking about?
Since day one of the App Store launch, Apple has run checks (in one form or the other) of the Application a developer submits to the store. These checks are performed even across versions. As a result, it is not uncommon to hear a developer complain that the newest version of the developer’s App is being rejected, even with “minor” changes. These checks include, but are not limited to:
- UI checks
- Uphold privacy rules
- Resource usage
The first check is meant to look at the Application and identify if it looks and behaves according to Apple’s design guidelines. Unfortunately, I know quite a few Apps that have failed this check in the past. This may seem like nitpicking from Apple, but the purpose is 100% valid; Provide our users with a similar user interface across all Apps, and they will feel more at home. With this check, Apple ensures that they can control this and provide (in some opinions) a better overall experience when using an iOS or iPadOS unit. Personal note: As someone who occasionally has to use Android, I wish this was a thing on Android.
The second is to ensure that a third party does not steal your data against your will. I do not think I need to go into details about why this is important. But this is also one of the reasons I do not really like Apps developed in Flutter and other alternatives, as they can trick this check.
Resource Usage, Apple have some standards for how an App should behave, and they have a test that evaluates the Apps behaviour over time and under different loads. This is meant to ensure that Apps behaviour nicely and (hopefully) do not drain your battery in no time (looking at you WhatsApp) or hug all your phone resources. These tests are less strict for a game as games require more resources.
Finally, maliciousness. Apple has never fully stated what this check includes, and I believe they never will. Additionally, I can only provide half a guess towards what the check may do and test, so I will not do that. But the purpose of the check is to avoid viruses, malware and so on being deployed on iOS and iPad devices, which is a good thing.
Clearly, these steps are all a good thing that Apple do. However, if you sideload an app, Apple has no way of performing this quality assurance, which is their most prominent argument against sideloading. The “problem” for people who want to open up the Apple ecosystem and allow for sideloading is that it is a damn valid point. There are fewer viruses and malware reported for iOS and iPadOS than on Android, and my guess is that is partly due to the App Store and how difficult it is to get a malicious app on the store and for people to download it. So even though I would like to see officially supported sideloading on iOS (I would not use it, though), I fully understand Apple, and they are sort of right.
The European Commission has been working on The Digital Markets Act for a while, and it has been deemed (by many) to be a problem for Apple. The general concept of why is explained by TechLinked in this video EU about to ruin Apple’s whole career. It has been deemed an issue because the act will require Apple to allow site loading applications onto iOS and iPadOS devices (e.g., installing them from outside of the Apple App store). One quick thing, this is not limited to Apple; this would also be a requirement for Google on Android. Companies such as Epic Games has sought after for quite a while (Epic Games v. Apple (Wikipedia)), where Apple’s counter-argument has been that it would present an unprecedented security risk on Apple devices and thereby expose users. There is some truth to Apple’s claims here, as Apple does some (I am not sure how much) security validation of applications in the App store and has removed Apps that have had security issues. But still, it is a limitation that does cause some level of restriction of Apple’s mobile devices and locks them to the Apple ecosystem. But is this act really such a big problem for Apple? I would argue no, actually NO! In this post, I will explain why.
Before we continue, I will state that I am a loyal Apple user (loyal and loyal… my work computers are in general Linux by choice) and have used iPhone as my primary phone since 2008; I have only had Android phones as work phones. Just to make it clear that there may be some bias in the following thought.
So why do I not think The Digital Markets Act will be a problem for apple? Well two reasons
- Customer loyalty and satisfaction
Let us start with Customer loyalty and satisfaction, why it is important, and why it is the most important of the two reasons.
First, Apple as a brand has such a devout following, partly due to the shit just work factor.
When you buy an Apple product, it has a tendency just to work, and that is a massive reason for Apple users to continue to buy them, but it is not just limited to hardware.
iWorks, iCloud, iTunes Music, and so on to the App Store just works.
It is straightforward, easy, and handles a lot of stuff for you, like secure pay for Applications (I have even had to get refunds for a few Apps, and it was super easy).
This alone increases user will to use the App Store simply from a convenience perspective. A competing App store would need to provide at least the same ease and simplicity even to be considered a competitor to the App store. Another thing, if we do not look at free games, Apps on the App store tends to have pretty high quality or go into obscurity. So, therefore, the Apps that do get downloaded (in general) do have a high quality, and I think this is an important factor of the App store as it gives satisfaction to the user. They do not have to handle sub-quality Apps. They just need to handle Apps. This leads me to think that sideloading of Apps for most users is not relevant. I also believe that companies that only offer sideloaded will be met with some distrust. The question will not be “wonder what Apple did for them to do this”, but rather it will be “are they trying to avoid something Apple is doing to protect us”. This ties back into customer loyalty. In conclusion, it results in customer loyalty and satisfaction, making it a) difficult to make a competitor to the App store and b) making it difficult for a single company to provide a sideloaded app. Finally, something I have really been wondering… how would you promote your sideloaded App to people? YouTube? Odysee? Twitter? Where would such an advertisement be most successful?
So next Jailbreaking has existed for a long time and has for those who desired sideloading Apps been a solution to the “problem”. Where App Stores such as Cydia has been available for a while, and many more can be found on zeejb.com, allowing for sideloading apps onto an iOS device. Naturally, with the requirement to jailbreak your phone. But that is not the important point. The critical point is that the option (although complicated) already exists, and I do not know anyone in real life who jailbreak their phone. Why? There is no reason, really, due to Apple’s App Store. Could a potential competitor be the solution to avoid jailbreaking? I doubt it.
I have a hard time seeing an iOS user opting to install an alternative to Apple’s App store unless there is a damn good reason. I predict that we will see a flourish at the beginning of alternative App stores and some companies offering sideloaded Apps. Then after a while, most of the new stores will die, leaving one, two, or maybe three competitors alive (the once able to provide similar services to Apple). Companies that provide sideloaded apps outside the App store will either join an alternative, rejoin Apples, or join both. For the simple reason, distributing and promoting Apps for the companies will become a tedious and annoying task that may harm revenue more than using Apple’s store.
In the end, it will have a limited impact on Apple as most users (I predict) will stick with the App store and look at the alternatives as a weird “novelty” option. But I may be wrong.
Last year I started QueryC++ a SQL Query build for modern C++ which allows constructing SQL queries in C++ without using
Making code cleaner, increases maintainability, and reduces the risk of syntax errors.
I released QueryC++ under the BSD3-Clause License and it is still under this license. I chose this license to make QueryC++ as easy as possible for others to use and integrate as part of their software library tools box. This has been great as (at least) one company now are using QueryC++, a fact I am proud of.
Some said that QueryC++ did not receive enough of my attention, and therefore, they could not recommend using it, and it was (in its current state) too limited in terms of functionality. Although I agree on the attention part, I can’t entirely agree with the feature part. In its current state, QueryC++ can be used in production. It actually already is.
In this post, I will outline the current status of QueryC++ and future plans.
QueryC++ is current major version is 3, and the perceptive may have realised we skipped version 2. This is explained later, and QueryC++ has moved from C++17 to C++20. We currently offer CMake, Make, and waf.io as build systems, although I know that there is currently work being done to add xmake (I will talk a little about this later).
The focus has since the beginning been on supporting PostgreSQL queries. That is because I mostly use PostgreSQL and often get QueryC++ tested through my work. There is full support for simple SELECT, INSERT, DELETE, and UPDATE queries in PostgreSQL, although not all data types are fully supported yet. This is the current status; I will cover why we skipped version 2.
Skipping Version 2?
This discussion came up with users of QueryC++ during the move from C++17 to C++20. Currently, QueryC++ only support C++20, but some have expressed a desire for C++17 support. But we were unsure how to do that well in the current scheme of things. Some suggested keeping an alternative version of QueryC++ built for C++17 similar to others that run a parallel version scheme, i.e. lower compatibility equals lower semantic version numbers. We are still thinking about this, as QueryC++ doesn’t rely much on C++20 features yet. This means that it is impossible, and therefore this is still up for discussion.
Adding Integration Tests
I have been ignorant, and I apologise for the issues this may have caused some (even though only one team reported the issue).
For those who do not know, I am dyslexic, and my brain sometimes plays tricks on me when reading results in
FOREIGN KEY being spelled
FOREIGN KEY in QueryC++.
This error was only discovered recently (fix in version 3.0.5).
However, this clearly shows that the tests of QueryC++ are not advanced enough.
I will rectify this as soon as possible (although probably first in April).
I will extend these tests at the integration test, where queries are run against a live PostgreSQL database and added support for more databases.
Adding more types
We have been at a stalemate about adding additional supported types to QueryC++. This will change during March and April, where more time will be allotted to the development of QueryC++. The focus will still be on adding more PostgreSQL compatible types, but we will also add as many common types along the way as possible. This includes constraints.
More on MariaDB and MySQL
Some have shown interest in support for MariaDB and MySQL; however, the interested party cannot provide development time for adding support to this. Therefore, I officially ask for help in adding support for MariaDB and MySQL.
The Conan package will come; I am just not exactly sure when yet. But it is a priority. I hope to get it done in April or May.
Adding xmake, why?
So I found a new build system called xmake, and I have seen it get some traction in the C++ community. But since QueryC++ already support Make, CMake, and waf.io, I thought this would be enough. However, what xmake is trying to achieve speaks to me, and I would like to support this approach. Therefore, I will add xmake as an additional support build system.
The funding from Aarhus University will end by the end of March. Therefore, I may start seeking for funds for the development of QueryC++ although currently it is still not needed.
This is the current status and a small peak of the future plans of QueryC++.
This is not a review, it is simply a recommendation of an awesome application
I am both a Linux and (to somes surprise) a macOS user, and switch betweeen Fedora with Gnome as DE and macOS on a daily basis. Therefore, I try to setup both my Linux and macOS box to work in similar fashions and one thing I had been missing on macOS for a while was sending windows to one side of the screen like META + left/right-arrow under Gnome or sending a window to another display.
Now I wrote I had been missing it for a while, indicating that I have solved the problem. Well I have not solved the problem myself by coding, no, no. I found an application and this is Rectangle an application for macOS developed by Ryan Hanson. And to be honest this application solves all my needs on macOS and then some, in extension to do so much more. I have been using Rectangle since the May of 2019 and I honestly have loved it ever since.
It is highly configurable and allows you to record alternative key-bindings if you need it (I have not found the need). Additionally, it is very light on resource usage, a problem I have had with alternatives. Furhtermore, Rectangle is open source (github.com/rxhanson/Rectangle) which have allowed me to look through the code and though I have not been through all the code I have been through some, and I like what I see.
Therefore I whole heartly recommend Rectangle to any macOS user.
In the Fedora community, there have been some confusions since this was seen by different users Slack drops Fedora support March 2022. However, this is a truth with modifications and sometimes the Fedora. The support is actually only being dropped for native RPM package for Fedora (and RedHat). Slack will still be available to be used through the browser just as it always has been.
What is all the fuss about then? There is still support right? Indeed, but some reason people prefer the desktop applications. This means that people have been in a slight panic, about what happens next. Well the answer is pretty easy… Use the Slack Flatpak instead. There is no reason to panic just use Flatpak.
Additionally, more and more distros, including Fedora, seems to be moving away from native packages, to systems such as Flatpak and Snap. SO moving to these tools is simply a good idea. But why the are moving to these at all? The reason is to ease the lives of maintainers. Currently making a (“proper”) release for every distribution is really time consuming, to you a deb package, RPM, what ever ArchLinux uses, and so on. With Flatpack or alternative, you need one release and it will (is supposed) to work across all distributions,
So that Slack drops the native RPM package doesn’t matter, they still support Flatpack and at the moment that is actually more important than a native package.
This is my take on it at least.