Ann.Dev

I gave a talk recently about the state of software supply-chain attacks, and the part people kept asking about afterwards wasn’t the industry-wide statistics — it was the two compromises I’d pulled apart by hand. This post is the written version of that part. Part 2 will pull back to the wider picture (XZ Utils, tj-actions, Trivy, and what actually helps); this one stays on the two incidents I looked at directly.

Optimizing Selective Docker Builds in a Turborepo Monorepo on GitHub Actions

Our GitHub Actions matrix containers build workflow was always building every container image in our Turborepo monorepo — even if only a few packages had actually changed. This not only resulted in increased build time but also inflated our operational cost. In this post, I’ll will outline how we tackled this issue and implementing a robust solution that leverages Turborepo’s dry-run capabilities and GitHub Actions caching to build Docker images only for the changed packages.

Yesterday I encountered a nasty surprise after upgrading Hyprland to version 0.46.2—it crashed on startup, leaving me unable to log into my Wayland session. If you’re experiencing this problem, here’s a temporary workaround so you can keep working until a fix arrives.

The Issue

Hyprland 0.46.2 appears to crash immediately upon launch, preventing you from getting into your usual tiling window manager environment.

Update Dec 29 2024: hyprutils-git Caused Compatibility Issues

After some further digging, I discovered my Hyprland crash was caused by the AUR hyprutils-git package. I had previously switched to hyprutils-git from the AUR because I was also using hyprpolkitagent-git. Because of this, the entire Hyprland ecosystem ended up depending on the hyprutils-git package, which broke compatibility with the stable release of Hyprland in the last few updates.

Hyprland is not just a tiling window manager; it’s a gateway to a highly customized and efficient Linux environment. In this second part of our guide, let’s explore some advanced features to enhance your Hyprland setup.

In the previous part, we’ve covered the basics of setting up and configuring Hyprland. We’ve done a lot of work, and it would be a shame to lose it. So, first, let’s start by saving our configurations using GNU Stow in a GitHub repository.

Hyprland is a dynamic tiling window manager built for the modern Wayland display server protocol. In this guide, we’ll walk you through the process of setting up Hyprland on your Linux system.

Why Wayland?

First and foremost, performance and reduced input lag. Wayland is a modern replacement for X11, and it has much cleaner architecture, better application separation, and improved HiDPI hardware support.

What is a Tiling Window Manager and Why Should I Care?

So, a tiling window manager, as opposed to a floating window manager, organizes your windows in a non-overlapping, grid-like pattern. It will give you a superhuman ability to fly through your windows and workspaces with hotkeys and improve your productivity.

Welcome to my new series of posts aimed at crafting a robust local development environment that mirrors your production setup in the cloud. The essence is to provide a playground where you can debug, test, and get a feel of your applications before they hit the production stage. Over the span of these posts, we’ll be tinkering with various tools and technologies, knitting them together to form a setup that’s not only developer-friendly but also educative.

[Read More]

This is part 3 of EOS quick-start. Please makesure you have completed [Part 2] Install from sources and have all requirements installed.

Before we begin

First things first: By voting you are accepting the EOS Constitution. Make sure you have read it!

As we already stated in [Part 1] Introduction, EOS is in many ways a social experiment in governance. One of the aspects of this is voting for block producers and you vote matters. There are currently few ways to vote for EOS block producers currently available:

This is part 4 of EOS quick-start. Please makesure you have completed [ Part 2 ] Install from sources and have all requirements installed.

Also refer to [ Part 1 ] Introduction for basic information on EOS.IO

Run EOS.IO Local Testnet

after the build successfully finished, you need to run

nodeos --config-dir ./config --data-dir ./data

this will generate data and config folder with default config.ini  file in you working folder, then stop it with Ctrl + C.

This is part 2 of EOS quick-start. Please refer to [ Part 1 ] Introduction for basic information on EOS.IO

Installation and configuration

In EOS.IO there are three main progreams that weare going to use througout this tutorials:

• nodeos is n EOS node daemon
• keosd is a wallet keys daemon
• cleos is a cli - command line interface tool

Option 1. Run Docker image

This is the simplest and easiest way. Just run the following command to get into EOS enabled shell:

docker run -it eosio/eos:latest /bin/bash

Option 2. Build using build script

So according to the README on https://github.com/EOSIO/eos, all I need to do to run local testnet is:

What the heck is EOS, and why should I care?

According to EOS.IO: EOS is a software that introduces a blockchain architecture designed to enable vertical and horizontal scaling of decentralized applications.

But what does it mean?..