<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>~/kobi-medrish</title><link>https://kobimedrish.com/</link><description>Recent content on ~/kobi-medrish</description><generator>Hugo -- 0.146.0</generator><language>en-us</language><lastBuildDate>Sat, 13 Sep 2025 10:30:05 +0300</lastBuildDate><atom:link href="https://kobimedrish.com/index.xml" rel="self" type="application/rss+xml"/><item><title>Scaling NixOS with "Import All and Enable" Pattern</title><link>https://kobimedrish.com/posts/scaling_nixos_with_import_all_and_enable_pattern/</link><pubDate>Sat, 13 Sep 2025 10:30:05 +0300</pubDate><guid>https://kobimedrish.com/posts/scaling_nixos_with_import_all_and_enable_pattern/</guid><description>&lt;p>The default structure of a fresh NixOS installation makes a lot of sense, two files,
which are intended to be used as the bases for future changes and represent
a single machine with the bare minimum, upon which this first installation is being done.
For the sake of consistent language I will call them two high level modules.&lt;/p>
&lt;h1 id="the-problem-with-all-in-one-configuration-files">The problem with &amp;quot;all in one configuration files&amp;quot;&lt;/h1>
&lt;p>The initial installation creates two high level modules, configuration.nix
and hardware-configuration.nix but what happens when we want to add zfs configuration or
setup home-manger, or maybe declare neovim and emacs. The cohesion of this high level modules gets
fuzzier by every such addition. Unrelated configurations get coupled together, Understating where something
starts and ends and the ability to change it becomes a nightmare.&lt;/p></description></item><item><title>Intro to Yocto, part 4 - Yocto for raspberry pi4, build, boot, and cross compile</title><link>https://kobimedrish.com/posts/yocto_for_raspberry_pi4_clone_build_boot/</link><pubDate>Mon, 21 Jul 2025 22:00:07 +0300</pubDate><guid>https://kobimedrish.com/posts/yocto_for_raspberry_pi4_clone_build_boot/</guid><description>&lt;hr>
&lt;p>&lt;strong>All posts in this series:&lt;/strong>&lt;/p>
&lt;ol>
&lt;li>&lt;a href="https://kobimedrish.com/posts/rolling_you_own_linux_distro_with_yocto">Intro to Yocto, part 1 - Rolling your own Linux distro with yocto&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://kobimedrish.com/posts/hands_on_introduction_to_bitbake">Intro to Yocto, part 2 - Hands-On Introduction to BitBake&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://kobimedrish.com/posts/building_a_poky_yocto_project_image_for_qemu">Intro to Yocto, part 3 - Building a Poky (Yocto Project) Image for QEMU&lt;/a>&lt;/li>
&lt;li>(current) &lt;a href="https://kobimedrish.com/posts/yocto_for_raspberry_pi4_clone_build_boot">Intro to Yocto, part 4 - Yocto for raspberry pi4, build, boot, and cross compile&lt;/a>&lt;/li>
&lt;/ol>
&lt;hr>
&lt;h1 id="preface">Preface&lt;/h1>
&lt;p>The goal of this post is to customize the Yocto reference distribution, Poky
to create a bootable image for the Raspberry Pi4. This involves aspects of what is
often termed as &amp;ldquo;board bring-up&amp;rdquo;, specifically adapting the build system for new
hardware. And will also cover cross-compilation.&lt;/p></description></item><item><title>Intro to Yocto, part 3 - Building a Poky (Yocto Project) Image for QEMU</title><link>https://kobimedrish.com/posts/building_a_poky_yocto_project_image_for_qemu/</link><pubDate>Wed, 16 Jul 2025 22:29:45 +0300</pubDate><guid>https://kobimedrish.com/posts/building_a_poky_yocto_project_image_for_qemu/</guid><description>&lt;hr>
&lt;p>&lt;strong>All posts in this series:&lt;/strong>&lt;/p>
&lt;ol>
&lt;li>&lt;a href="https://kobimedrish.com/posts/rolling_you_own_linux_distro_with_yocto">Intro to Yocto, part 1 - Rolling your own Linux distro with yocto&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://kobimedrish.com/posts/hands_on_introduction_to_bitbake">Intro to Yocto, part 2 - Hands-On Introduction to BitBake&lt;/a>&lt;/li>
&lt;li>(current) &lt;a href="https://kobimedrish.com/posts/building_a_poky_yocto_project_image_for_qemu">Intro to Yocto, part 3 - Building a Poky (Yocto Project) Image for QEMU&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://kobimedrish.com/posts/yocto_for_raspberry_pi4_clone_build_boot">Intro to Yocto, part 4 - Yocto for raspberry pi4, build, boot, and cross compile&lt;/a>&lt;/li>
&lt;/ol>
&lt;hr>
&lt;p>After looking at why you should build your own distribution in &lt;a href="https://kobimedrish.com/posts/rolling_you_own_linux_distro_with_yocto">Rolling you own Linux distro with Yocto&lt;/a>,
And then looking on how &lt;a href="https://kobimedrish.com/posts/hands_on_introduction_to_bitbake">bitbake works&lt;/a>, it is time to dip our toes in the water and create first
real image out of poky reference repository and actually run it using a virtual machine.&lt;/p></description></item><item><title>Intro to Yocto, part 2 - Hands-On Introduction to BitBake</title><link>https://kobimedrish.com/posts/hands_on_introduction_to_bitbake/</link><pubDate>Wed, 09 Jul 2025 18:47:34 +0300</pubDate><guid>https://kobimedrish.com/posts/hands_on_introduction_to_bitbake/</guid><description>&lt;hr>
&lt;p>&lt;strong>All posts in this series:&lt;/strong>&lt;/p>
&lt;ol>
&lt;li>&lt;a href="https://kobimedrish.com/posts/rolling_you_own_linux_distro_with_yocto">Intro to Yocto, part 1 - Rolling your own Linux distro with yocto&lt;/a>&lt;/li>
&lt;li>(current) &lt;a href="https://kobimedrish.com/posts/hands_on_introduction_to_bitbake">Intro to Yocto, part 2 - Hands-On Introduction to BitBake&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://kobimedrish.com/posts/building_a_poky_yocto_project_image_for_qemu">Intro to Yocto, part 3 - Building a Poky (Yocto Project) Image for QEMU&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://kobimedrish.com/posts/yocto_for_raspberry_pi4_clone_build_boot">Intro to Yocto, part 4 - Yocto for raspberry pi4, build, boot, and cross compile&lt;/a>&lt;/li>
&lt;/ol>
&lt;hr>
&lt;h1 id="preface">Preface&lt;/h1>
&lt;p>This post is based on a &lt;a href="https://a4z.gitlab.io/docs/BitBake/guide.html">tutorial&lt;/a> by Harald Achitz. As I was following
it I was adding notes to it for context, and clarity. Filling in the blanks I came across and
refactoring the structure for readability.&lt;/p></description></item><item><title>Keeping Nix Secrets with Sops: Integration and Applications</title><link>https://kobimedrish.com/posts/keeping_nix_secrets_with_sops_integratoin_and_applictions/</link><pubDate>Sun, 29 Jun 2025 18:47:34 +0300</pubDate><guid>https://kobimedrish.com/posts/keeping_nix_secrets_with_sops_integratoin_and_applictions/</guid><description>&lt;p>When setting up a full NixOS system—or even just a standalone Home Manager module—secrets are often a core part of the
configuration. With nix being declarative, it makes a lot of sense to integrate them into the nix configurations, but
this needs to be done in a secure manner, so even if your configurations are put on public display your secrets will
stay safe(case in point &lt;a href="https://github.com/p3t33/nixos_flake">my repository&lt;/a> that are a reference for this post).&lt;/p></description></item><item><title>Intro to Yocto, part 1 - Rolling your own Linux distro with yocto</title><link>https://kobimedrish.com/posts/rolling_you_own_linux_distro_with_yocto/</link><pubDate>Sun, 27 Oct 2024 11:00:32 +0300</pubDate><guid>https://kobimedrish.com/posts/rolling_you_own_linux_distro_with_yocto/</guid><description>&lt;hr>
&lt;p>&lt;strong>All posts in this series:&lt;/strong>&lt;/p>
&lt;ol>
&lt;li>(current) &lt;a href="https://kobimedrish.com/posts/rolling_you_own_linux_distro_with_yocto">Intro to Yocto, part 1 - Rolling your own Linux distro with yocto&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://kobimedrish.com/posts/hands_on_introduction_to_bitbake">Intro to Yocto, part 2 - Hands-On Introduction to BitBake&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://kobimedrish.com/posts/building_a_poky_yocto_project_image_for_qemu">Intro to Yocto, part 3 - Building a Poky (Yocto Project) Image for QEMU&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://kobimedrish.com/posts/yocto_for_raspberry_pi4_clone_build_boot">Intro to Yocto, part 4 - Yocto for raspberry pi4, build, boot, and cross compile&lt;/a>&lt;/li>
&lt;/ol>
&lt;hr>
&lt;p>This post is the first in a series that will cover embedded development from the perspective of
OS development, starting with the need of such solution, the moving parts, the basic configuration that
can be used on a raspberry pi and anything else that might be relevant.&lt;/p></description></item><item><title>lsp and cross compilation pitfalls</title><link>https://kobimedrish.com/posts/lsp_and_cross_compilation_pitfalls/</link><pubDate>Sun, 13 Oct 2024 22:11:32 +0300</pubDate><guid>https://kobimedrish.com/posts/lsp_and_cross_compilation_pitfalls/</guid><description>&lt;h2 id="about">About&lt;/h2>
&lt;p>The aim of this tutorial is to go over the creation of the compilation database(compile_commands.json) for
cland lsp using cmake, and then more importantly expand on its limitations when it comes to cross compilation.&lt;/p>
&lt;h2 id="resources">Resources&lt;/h2>
&lt;p>You can get all the source described bellow at the following &lt;a href="https://github.com/p3t33/compilation_database">repository&lt;/a>.&lt;/p>
&lt;h2 id="creating-the-source-code">Creating the source code&lt;/h2>
&lt;h3 id="understanding-the-include-search-order-by-clang-plus-plus-g-plus-plus">Understanding the include search order by clang++/g++&lt;/h3>
&lt;p>standard headers such as iostream or pthread(posix) are located by the compiler at standard paths, other headers(foo.h)
need to be specified using the directory they are located in using -I directive.&lt;/p></description></item><item><title>Advanced workflows with tmux</title><link>https://kobimedrish.com/posts/advanced_workflows_with_tmux/</link><pubDate>Thu, 03 Oct 2024 11:00:32 +0300</pubDate><guid>https://kobimedrish.com/posts/advanced_workflows_with_tmux/</guid><description>&lt;p>There are many videos and posts dealing with tmux and how to use it, most of them
only deal with its basic use, meaning explaining tabs, panes, session and at best the
use of tmux as a daemon. I am on the other hand want to focus on the impact that tmux has had on
my workflow and the ways I use it to reduce context switching friction.&lt;/p>
&lt;p>By understanding the moving parts of your tool and your interface with it you can carve a friction free
workflow that suits you specifically, concentrating on the task at hand instead of wasting
time and energy to bring the things you need together and then scrambling form one context to the
next, just to repeat it again and again with each system restart.&lt;/p></description></item><item><title/><link>https://kobimedrish.com/books/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://kobimedrish.com/books/</guid><description>&lt;p>The list below includes books that have shaped my perspective and influenced the
way I live my life, as well as some that I find thought-provoking and entertaining.
These are books that I can wholeheartedly recommend.&lt;/p>
&lt;p>This list is regularly updated. Be sure to revisit often!&lt;/p>
&lt;h2 id="behavioral-economics">Behavioral economics&lt;/h2>
&lt;h4 id="thinking-fast-and-slow-by-kahneman-daniel">Thinking, Fast and Slow by Kahneman Daniel.&lt;/h4>
&lt;p>This book defines the dual processes that influence our thoughts and decisions.
It distinguishes between the intuitive, quick &amp;ldquo;System 1&amp;rdquo; and the more analytical, slow
&amp;ldquo;System 2.&amp;rdquo; This book has profoundly changed my understanding of how decisions
are made, highlighting the often unconscious influence of our immediate reactions
versus our considered responses. It&amp;rsquo;s insights have reshaped my perception of
rationality and decision-making, and the ideas of this book can be found implicitly
in many of the books in this list.&lt;/p></description></item></channel></rss>