Few months ago I switched my home workstation and media center to Micro OS desktop and I cannot imagine switching back to normal distribution.
After some consideration I realized it should work fine (even better) on the notebook I am using for work.
Dochazka is a long-term project to replace the obsolete Attendance & Time Tracking system used by the Prague office since 2007. Dochazka is a complex system consisting of three major components:
- RESTful backend App::Dochazka::REST (with lots of help from Web::MREST)
I once had a bad dream.
I started good, a sunny day. I had just fixed an issue and push it to my fork, in order to create a Pull Request. I was happy. It felt awesome to have found a fix so elegant. Two lines of code.
Bug reports can be a great source of information, but usually finding the information requires extensive work in reading through all of the discussions and understanding the details about it.
Could it be that machine learning can be used to extract meaningful information out of that? That's what this project is about.
I want to learn more about the efforts of standardizing ARM boot for embedded boards - EBBR. I'll try to get it working on the Olinuxino A64 (https://www.olimex.com/Products/OLinuXino/A64/A64-OLinuXino/open-source-hardware) board, by compiling and programing bootefi enabled Uboot to SPI flash chip. After that it should be possible to install Linux distributions to the eMMC using standard images and installation method, to be verified with OpenSuse.
Bisection is a well known method of localizing which commit caused a regression in a code repository. git-bisect is a particularly used tool for this problem in git repositories. However it is often the case that the failure is probabilistic in nature - either because we don't have a reliable reproducer of the failure and thus not reproducing a problem on a particular commit does not mean the problem is not still present there, or because of inherent variability of e.g. performance regressions. Bisection for such failures is problematic as it takes only one false result for the bisection to end up in an unrelated part of code history. So in these cases we usually have to heavily extend runtime of a reproducer or do multiple test runs or multiple bisection runs to minimize a chance of error.
The aim of the project is to implement stochastic bisection for git. I.e., a method that will count with the fact that test results at each point of code history have some error rate and provide points in code history to test to find commit in code history that is with high probability introducing the regression in the smallest possible number of tests. Then we can use this method for bisection of performance problems in our performance testing grid Marvin.