Cedric has been contributing for a long time to EFL. He is known as the borker due to his work on optimizing the core libraries and triggering side effect bugs which tend to take years to be discovered.
Most developers make use of SSH servers on a regular basis and it’s quite common to be a bit lazy when it comes to the admin of some of them. However, this can create significant problems because SSH is usually served over a port that’s remotely accessible. I always spend time securing my own SSH servers according to some best practices, and you should review the steps in this article yourself. This blog post will expand upon these best practices by offering some improvements. Setup SSH Server Configuration The first step is to make the SSH service accessible via only the local network and Tor. Tor brings a few benefits for an SSH server: Nobody knows where users are connecting to the SSH server from. Remote scans need to know the hidden service address Tor uses, which reduces the risk of automated scan attacks on known login/password and bugs in the ssh server. It’s always […]
EFL is undergoing a huge API refactor; the goal of this change is to simplify API usage while simultaneously making it more powerful. One major component that required improvement was animation management. Legacy In the past, Ecore_Animator was the only object in charge of providing information about when to animate something; this had a few limitations and problems. The first problem is handling the lifecycle of the object: it must be manually destroyed once the animation is completed or when the object that uses it is destroyed. There was no way to link the object lifecycle with another object in any way or form. The animator object was built with the idea that there is one, and only one, global frame rate for the entire application. This is becoming less true today as moving to Wayland provides the ability to get the animation tick from the compositor on a per-window […]
As I illustrated in my previous article, the current capability of the Linux Kernel scheduler is far from giving us the most efficient use of the hardware we have; this needs to be fixed. The kernel community is hard at work attempting to fix this issue, and we should understand how they intend to do so to make sure that user space applications will be ready to take advantage of it. The Direction Taken by the Kernel Community Obviously this is easier said than done; even so, there is huge work being completed in the Kernel community to fix this issue. The solution is simple to describe, but very hard to implement as it touches one of the core components of Linux. Essentially, the scheduler should incorporate the work of cpuidle and cpufreq, and both cpuidle and cpufreq should be eliminated. Amit Kucheria offers a great read on this subject, […]
Multi core, heterogeneous embedded devices have been available for some time, but we are still learning a lot about how to use them to their full potential. My colleague and I have been trying to understand how the kernel scheduler affects the responsiveness of the user interface and how to maximize and stabilize the frame rate without consuming excessive energy. We want to improve the usage of that little battery so many people complain about! This article will focus on how CPU and Kernel interact from the user space point of view. Later, in another blog post, we will look at how to design libraries and applications to be as energy efficient as possible. There is still a lot that could be covered on other subsystems like the GPU or network, but these are big topics that are beyond the scope of this article. CPU Management in Today’s Linux Kernel […]