标签：#ux

Two audio players do not make a fair before-and-after test. If the second player restarts from zero or takes half a second to load, the user is no longer comparing two versions of the same moment. They are comparing two memories. That is a weak way to evaluate any audio effect. It is especially weak for AI processing. A denoiser can remove a fan while softening consonants. A de-reverb model can reduce the room tail while making the voice sound less natural. The output may be cleaner without being better. The preview therefore has one job: let the listener switch quickly enough to hear both the improvement and the damage. The rule I use is deliberately boring. Both versions should contain the same edit and play from the same position. Switching should not restart playback or create a pause. The interface should not hint that one version is supposed to win. Two independent <audio> elements fail surprisingly quickly. Each owns its playback state, buffering behavior, clock, and seek operation. The user ends up finding the same position twice and comparing one sound with a memory of another. A better interface has one transport and one version control: [ Play ] [ Original | Processed ] 00:18 ━━━━━━━ 00:42 The transport decides where playback happens. The segmented control decides which signal is audible. One transport, two signals For a short preview, I decode both files into AudioBuffer s, start them at the same AudioContext time and offset, and route each through its own GainNode . Both sources run; only one gain is open. decodeAudioData() decodes complete file data and resamples it to the context's sample rate. The decoded buffers can then share the same audio clock. See the MDN documentation for format and loading details. The core is small: const context = new AudioContext (); const originalGain = context . createGain (); const processedGain = context . createGain (); originalGain . connect ( context . destination ); processedGain . connect ( context . destination )

1. O problema que o Fzf resolve Quem vive no terminal conhece a cena: Ctrl+R para buscar um comando no histórico, mas a busca é linear e só mostra um resultado por vez; cd para um diretório profundo, mas é preciso lembrar (ou digitar) o caminho inteiro; git checkout para uma branch, mas primeiro é necessário rodar git branch e copiar o nome exato. Em todos esses casos, o gargalo é o mesmo: escolher um item entre muitos, digitando cada vez mais texto até sobrar só um. O fzf (fuzzy finder) resolve isso de um jeito genérico: ele pega qualquer lista de linhas — histórico de comandos, arquivos, branches, processos, o que for — e transforma essa lista em um filtro interativo, digitado em tempo real, onde não é preciso acertar a grafia exata nem a ordem das letras. Basta digitar pedaços do que se lembra e o fzf ordena os resultados por relevância. 2. O que é o Fzf Fzf é um filtro de linha de comando escrito em Go, de código aberto, mantido por Junegunn Choi. Ele não sabe nada sobre arquivos, git ou processos — a única coisa que ele faz é ler linhas da entrada padrão ( stdin ) e devolver, na saída padrão ( stdout ), a linha (ou linhas) selecionada interativamente. Essa simplicidade é o que o torna tão versátil: qualquer comando que produza uma lista de texto pode ser "encanado" ( | ) para dentro do fzf. # a ideia básica: qualquer lista vira um menu interativo ls | fzf history | fzf git branch | fzf ps aux | fzf Na prática, o fzf raramente é usado sozinho dessa forma — o valor real aparece quando ele é integrado ao shell e a outras ferramentas, o que este artigo cobre a partir da próxima seção. 3. Instalando o Fzf O fzf está disponível nos principais gerenciadores de pacote: # Debian/Ubuntu sudo apt install fzf # Fedora sudo dnf install fzf # Arch Linux sudo pacman -S fzf # macOS (Homebrew) brew install fzf Também é possível instalar via git, o que traz um script auxiliar de configuração dos atalhos de shell (usados na próxima seção): git clone --depth 1 https://github.com/j

If you’re a designer, you’ve probably had the same problem I’ve had: there are dozens of UI/UX design...

Buildroot builds a cross-compiler, a Linux kernel and a complete root filesystem from source, driven by one Kconfig-style configuration file. Starting from the qemu_arm_vexpress_defconfig that ships with Buildroot 2026.05.1, two commands produce a bootable ARM system you can run under QEMU. The images you ship are the ones in output/images/ ; output/target/ looks like a root filesystem but must never be copied to a device. This post starts a new hands-on series on Buildroot for embedded Linux. By the end of this part you will have built a working Buildroot root filesystem for an ARM target, booted it under QEMU, and understood which generated directories are safe to ship. Later parts add your own packages, a BR2_EXTERNAL tree, kernel and bootloader integration, and reproducible image output. If the choice between build systems is still open, our earlier Yocto vs Buildroot comparison covers it; this series assumes the decision is made. What you need A Linux host, several gigabytes of free disk space, and a network connection. No development board is needed for this part; QEMU stands in for the hardware. On a Debian or Ubuntu host, this covers the mandatory packages the manual lists, plus the ncurses development files that menuconfig needs: raghu@techveda.org:~$ sudo apt install build-essential diffutils patch gzip bzip2 perl tar cpio unzip rsync file bc findutils gawk wget libncurses-dev One rule from the manual is worth stating plainly: build everything as a normal user. Buildroot never needs root, and running it as root exposes your host to any package that misbehaves during installation. The command above is the only one in this post that uses sudo . Getting Buildroot and choosing a target Download and unpack the current stable release — 2026.05.1 at the time of writing — from buildroot.org/downloads , and work from that directory. Buildroot ships ready-made configurations for many boards and emulated machines, one file each in configs/ , and make list-defconfigs

It’s been a while since I wrote a blog post. Recently, I decided to get back into writing and document something I’ve been playing around with: setting up a small homelab environment on an Oracle Cloud Free Tier VPS. As a software engineer, I’ve always been interested in what happens behind the scenes when an application moves from my laptop to an actual server. Things like networking, deployment, Linux, containers, firewalls, and DNS are all areas I’ve wanted to understand better through actual hands-on experience rather than just reading about them. The fact that I could do all of this on a free VPS made it even better. Why I Started This Experiment I initially set up an Oracle Cloud Free Tier VPS running Ubuntu with: 1 GB RAM 1 vCPU Ubuntu Linux A public IP address I wasn't planning to host anything serious on it. The main goal was simply to use it as a small playground where I could experiment with infrastructure and improve my Linux and system administration skills. Interestingly, the last time I regularly worked with a VPS was probably around seven years ago. Back then, a few friends and I used to rent servers and set up Call of Duty 4 multiplayer servers. We'd spend hours messing around with the server configuration and, of course, playing on it afterwards. Things have changed quite a bit since then. These days, I'm much more interested in software engineering, DevOps, infrastructure, and homelabbing. So I thought it would be fun to take a free VPS and see how much I could actually do with it. First Challenge: K3s on 1 GB of RAM One of the first things I wanted to try was K3s, the lightweight Kubernetes distribution. I wanted to get a basic Kubernetes environment running and use it to experiment with container orchestration. That plan didn't last very long. After installing K3s and starting the server, I noticed the memory usage climbing pretty quickly. With only 1 GB of RAM, there wasn't much room left for anything else. Once I started thinking about running

I'm use neovim in cli like in my home but im not use Ide before in my live my first try pc is arch linux and neovim So I think I'm the best person to ask what is special in neovim 1: is so lightweight use ram is just 50-20 mb ram 2: you can config anything in lua language 3: open into terminal ssh protocol edit in code into server 4: vim keybinding like Vim / Neovim Keybindings Cheat Sheet Navigation (Normal Mode) h / j / k / l : Move Left / Down / Up / Right w / b : Jump forward / backward by word e / ge : Jump to end of current / previous word 0 / ^ / $ : Go to start of line / first non-blank char / end of line gg / G : Go to first line / last line of file { / } : Jump to previous / next paragraph Ctrl + u / d : Scroll Half-page Up / Down Ctrl + b / f : Scroll Full-page Up / Down Editing & Insert Mode i / I : Insert before cursor / at start of line a / A : Append after cursor / at end of line o / O : Open new line below / above current line u : Undo Ctrl + r : Redo . : Repeat last editing command Cutting, Copying & Pasting x : Delete character under cursor dw : Delete word dd : Delete (cut) line d$ / D : Delete from cursor to end of line yy / Y : Yank (copy) line yw : Yank word p / P : Paste after / before cursor Search & Replace /pattern : Search forward for pattern ?pattern : Search backward for pattern n / N : Jump to next / previous match * / # : Search word under cursor forward / backward :%s/old/new/g : Replace all occurrences in file :%s/old/new/gc : Replace all occurrences with confirmation prompt Visual Mode v : Character-wise visual mode V : Line-wise visual mode Ctrl + v : Block-wise visual mode y : Yank selection d : Delete selection > / < : Indent / Outdent selection Text Objects (Inside / Around) ci" : Change inside quotes ( "..." ) ca" : Change around quotes (includes quotes) di( : Delete inside parentheses da( : Delete around parentheses yi{ : Yank inside curly braces Buffers, Windows & Tabs :w : Save file :q : Quit buffer :wq / :x : Save and quit

Conteúdo 1. Apresentação - Omarchy 2. Praticidade 3. Agentes de IA 4. Desuso do Mouse 5....

Dan Finneran discusses the risks of unowned AI-generated code in production and demonstrates how eBPF can intercept and control AI API traffic in Kubernetes. He explains how kernel-level socket hooks enable transparent prompt filtering, model swapping, token limits, and syscall restrictions to secure AI agents without modifying application source code or restarting containers. By Dan Finneran

As the appetite for “authenticity” grows online, content creators are buying up empty boxes for luxury goods—and resellers are cashing in for “crazy prices.”

Getting your folder or file to github can be a bit of an off vibe due to the many steps especially if it's your first commit, but getting these steps right will make it easy for the other folders or files you will push afterwards.Let’s dive in CREATING A LOCAL FOLDER Depending on the OS you are using you can use Git Bash or the Terminal. For Linux which is what I am using I will use the Terminal First Step Start by creating a folder in the terminal: mkdir your project folder name . then change directory: cd ~/to the folder you have just created Now we need to format our folder by creating a few files inside it Data file README.md code file if you will be using code. To check if you have created these files inside your folder: run:, ls This calls out all the files that are inside your folder. Let's tackle the files we have just added. Data Folder Run command: mkdir data This creates a data folder. This is where you will add your data e.g Excel or CSV files that you will be using to run your analysis or your project. README.md Run command: touch README.md This where you will give an overview of your work, the reason you are doing the analysis,how you collected your data,the tools you used to run the analysis..Basically README.md is a file that guides anyone who goes through your analysis or project on the steps you took while doing your analysis or project.Think of it as the introduction at the start of your favourite book or novel. To write all of this you will run the command echo "#give your project a name or describe your project" >README.md README.md uses markdown language reason for the # at the beginning of the quotation.When writing the headings or subtitles use capital letters or proper style. For subtitles you need to add two ## at the beginning. If you want to write more content without overwriting what you have previously written inside the README.md file you will need to use double greater signs(>>) at the end of the quotation,run: echo #your message” >>R

A rollback plan tells you how to undo an AI change, but not what breaks first when the change stays in place. Most production incidents do not begin with a deliberate rollback; they begin with an unexpected failure mode that the author never tested. I now treat a passing fault drill as a precondition for reviewing any AI-generated server patch. The drill runs on a disposable server before a human reads a single line of the diff. Why a rollback plan is not enough A rollback plan answers a question about the past: how do we return the system to a known state? A fault drill answers a question about the future: what happens when this change meets a condition the author did not imagine? The second question decides whether you get paged at 3 a.m. A change with a perfect rollback can still fail in a way that nobody notices until the data is gone. Free model access changes the economics of this argument, because generation stops being the bottleneck and verification starts. When a draft is nearly free, the cheapest verification is the one that breaks the change on purpose. A rollback plan is documentation; a fault drill is evidence. Documentation tells you what should happen, while evidence tells you what actually happens on a real service manager. The fault drill in five steps The workflow assumes two cheap resources: a model that generates failure hypotheses from a diff, and a server that can be destroyed after the drill. MonkeyCode's free model access covers the first, and its free server option covers the second, so a drill costs almost nothing. Disclosure: This article was prepared as part of MonkeyCode's product outreach. Any ephemeral VM or container host works if you prefer a different provider. 1. Generate failure modes before you apply anything Ask the model to enumerate failure modes for the diff, and forbid it from proposing fixes, because fixes are a distraction at this stage. The prompt below is the one I use, and it produces a catalog that the drill can test.

A surprising share of "the app is down" pages resolve to a name-resolution problem, not a broken service. The service is fine; the client can't turn a name into an address. dig is the precision tool for proving that in seconds instead of guessing. Think about it as a resolution chain, not "is DNS broken" When a name fails, work the chain: which resolver did the client ask, what did that resolver return, and does it match what authoritative DNS actually says? Most incidents live in the gap between those three. The method is boring and reliable: observe the symptom, form a hypothesis about where in the chain it breaks, test with one query, read the evidence, fix, then validate. The single most important habit: query the name from the same host and the same resolver the app uses. Running dig from your laptop proves nothing about what the pod or VM sees. The record types worth knowing You don't need all of them, but you need to recognize them: A / AAAA — name to IPv4 / IPv6 address. The usual suspect. CNAME — an alias pointing at another name. A stale or wrong CNAME sends traffic somewhere unexpected. MX — mail routing. TXT — SPF, DKIM, domain verification, and other metadata. NS — which servers are authoritative for a zone. SOA — the zone's serial and TTL defaults; the serial tells you whether a change has propagated. PTR — reverse lookup, IP back to name. The commands that actually earn their place Start with the quick answer, then get precise. dig +short api.internal.example.com +short strips everything except the answer. If it prints an IP, resolution works from this host. If it prints nothing, you have a real failure to chase. Empty output is a signal, not an error. dig api.internal.example.com A The full form. Read the status in the header: NOERROR with an ANSWER section is good; NXDOMAIN means the name genuinely doesn't exist; SERVFAIL points at a broken upstream or DNSSEC issue. Also note which SERVER answered at the bottom — that's the resolver you're actually

The tunnel comes up. wg show prints a recent handshake. The client has its address inside the tunnel. And not a single byte reaches the internet. Almost every guide answers this with "open UDP 51820 in the firewall". You already did that — it is why the handshake works at all. The problem is somewhere else, and UFW makes the distinction easy to miss: Entering a machine and traversing it are two different permissions. ufw allow 51820/udp lets packets arrive at the server. Your clients' traffic does not stop there — it goes through the box and out the public interface. That path lives in the FORWARD chain, which UFW denies by default and which no allow rule touches. The four things to check, in order 1. IP forwarding — and the file that overwrites the other file This is the one that costs hours, because the setting looks done. UFW loads its own sysctl file at startup, and it takes precedence over the system one. A value you carefully set in /etc/sysctl.conf can be silently overwritten on the next ufw enable . The right place is /etc/ufw/sysctl.conf : net / ipv4 / ip_forward = 1 net / ipv6 / conf / default / forwarding = 1 net / ipv6 / conf / all / forwarding = 1 Then check the effective value, not the file you just edited: sysctl net.ipv4.ip_forward 2. Forwarding, which is not the same as ingress Targeted, and the one to prefer: sudo ufw route allow in on wg0 out on eth0 Or globally, in /etc/default/ufw : DEFAULT_FORWARD_POLICY = "ACCEPT" The second opens forwarding for every interface. It is a good ten-second diagnostic and a poor permanent configuration. 3. NAT, which UFW never adds on its own Without it, packets leave carrying their tunnel address, which nothing on the internet knows how to answer. In /etc/ufw/before.rules , at the very top , before the *filter line: *nat :POSTROUTING ACCEPT [0:0] -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE COMMIT Two classic mistakes here: putting this block after *filter (it is then ignored), and copying eth0 without chec

For most of Linux gaming's history, the story has been the same: Linux users want to play games, game companies don't care about Linux users, and the community builds its own tools to bridge the gap. Valve changed that with Proton and the Steam Deck. But the storefronts held out. Epic, GOG, and Microsoft all stayed away from native Linux support, leaving their games accessible only through community-built launchers or not at all. That's changing. Three things happened this month that point to a tipping point. Epic Games is building a native Linux launcher In a Discord AMA reported by GamingOnLinux on August 14, 2026, an Epic Games developer confirmed that a native Linux version of the Epic Games Store launcher is coming "soon." Not for the preview release of the upcoming store overhaul, but after that. The developer's exact words, screenshotted from Discord: "Soon <-- but not for the preview release. As you can imagine, we need to do more than simply have a build of the launcher that can run natively on Linux." This isn't a vague promise from a community manager. It's a developer in an AMA saying the work is happening. Epic was also recently hiring a Security Engineer to champion Linux anti-cheat, which suggests broader plans for Linux support beyond just the launcher. The context matters. Epic has been the holdout. Tim Sweeney has historically been dismissive of Linux as a gaming platform, and Epic's anti-cheat (BattlEye, Easy Anti-Cheat) has been a recurring blocker for Linux compatibility even when games would otherwise run fine through Proton. A native launcher doesn't solve the anti-cheat problem, but it signals a shift in how Epic views the platform. GOG is working on a Linux version of GOG Galaxy GOG separately confirmed to GamingOnLinux that work is in progress on a Linux version of GOG Galaxy. No timeline, no details, just confirmation that it's happening. GOG is a smaller player than Epic, but they matter for a different reason: they're the DRM-free storef

Introduction I did something stupid. I built a superhero-themed Nuxt app, connected it to an Anthropic model through Amazon Bedrock , and gave it a tool that deletes files from my computer. In fact, if I wasn't careful, it could have deleted all my files! The first time I tried it, I didn't use any sort of approval mechanism. And as you expected it just deleted things. Then I looked into how my coding agent works, and I learned about tool approvals. I learned that AI SDK 7 has a tool approval at the model-call level. It works by pausing for an approval, showing an approval window, and then deleting it. I then put Kiro CLI behind the same interface using Agent Client Protocol (ACP). Watch the full video on YouTube . Prerequisites You need: Node.js 22 or later. AI SDK 7 requires Node.js 22 and uses ECMAScript modules (ESM). npm 11 or another package manager that works with Nuxt 4. AWS credentials available through the standard provider chain. Access to an Amazon Bedrock model in your AWS Region. The AWS CLI if you want to list the inference profiles available to your account. An authenticated Kiro CLI installation for the optional ACP section. Step 1: Create the Nuxt app Create the project and install the versions used in the recorded demo: npx nuxi@latest init nuxt-agent-approval cd nuxt-agent-approval npm install \ nuxt@4.5.2 \ vue@3.5.41 \ ai@7.0.66 \ @ai-sdk/vue@4.0.66 \ @ai-sdk/amazon-bedrock@5.0.57 \ @aws-sdk/credential-providers@3.1111.0 \ @nuxt/ui@4.10.0 \ zod@4.4.3 npm install -D @iconify-json/lucide@1.2.123 Register Nuxt UI and expose the Amazon Bedrock settings through server-side runtime config: // nuxt.config.ts export default defineNuxtConfig ({ modules : [ ' @nuxt/ui ' ], css : [ ' ~/assets/css/main.css ' ], runtimeConfig : { awsRegion : process . env . AWS_REGION ?? ' us-west-2 ' , bedrockModelId : process . env . NUXT_BEDROCK_MODEL_ID } }) Add the two Nuxt UI imports: /* app/assets/css/main.css */ @import "tailwindcss" ; @import "@nuxt/ui" ; You can c

Most designers don't lose time in the design phase; they lose it in the tool-switching phase. You...

How Linux file permissions actually work under the hood, why symbolic mode is your best friend, and how to stop blindly typing chmod 777. Every Linux engineer has been there. You write a brand-new bash script, try to run it from your terminal, and hit an immediate roadblock: $ ./backup.sh bash: ./backup.sh: Permission denied You open your search engine or ask a chat assistant for help. Within seconds, you find an answer that tells you to run: chmod 777 backup.sh You run the command, hit enter, and the script runs. Problem solved, right? Not quite. In fact, you just opened the digital front door of that file to every single user and background service on the entire operating system. When I started managing Linux servers years ago, permissions felt like a strange puzzle of three-digit math problems. People kept throwing numbers around: 755 for scripts, 644 for web pages, 600 for SSH keys, and 777 whenever something broke and nobody knew why. I memorized those numbers like cheat codes in a video game. But whenever I had to handle a real permission problem, like giving a development team write access to a shared log folder without letting them delete each other's files, memorized numbers fell apart. Here is the secret: you do not need to do binary math or memorize three-digit codes to master Linux permissions. Linux has a built-in, human-readable permission syntax called symbolic mode . Once you understand how Linux looks at files, who owns them, and what actions each permission controls, chmod becomes one of the most intuitive tools in your terminal. Let's break down how it all works step by step. 1. What chmod Actually Does The name chmod stands for change mode . In Unix and Linux systems, every single file and directory has a "mode". That mode determines who is allowed to read it, write to it, or run it. When you run chmod , you are simply updating those access bits inside the Linux filesystem inode. To see the current mode of your files, open any terminal and run ls

When I first got interested in cybersecurity, I thought it was all about tools. Nmap, Metasploit, Wireshark, Burp Suite. I downloaded them all, watched tutorials, and felt like a hacker. But the first time I tried to customize a scan or parse a weird log file, I hit a wall. I didn't know how to code. And in cybersecurity, that's like trying to be a chef without knowing how to use a knife. This article is for people who want to move beyond clicking buttons. Whether you're a beginner deciding where to start or a security analyst who wants to automate boring tasks, programming will change how you work. I'll cover why programming matters, what languages to learn, the concepts you'll actually use, projects to build, and how to think like both an attacker and a defender. Why programming isn't optional anymore Cybersecurity used to be more forgiving. You could run a vulnerability scanner, read the report, and call it a day. But threats have gotten more complex, and so have the defenses. Today, you need to: · Write scripts to analyze thousands of log lines in seconds. · Automate repetitive tasks like phishing email analysis or IP reputation checks. · Understand the code behind vulnerabilities so you can explain them to developers. · Build custom tools when existing ones don't fit your environment. · Test your own code for flaws before attackers find them. If you can't read or write code, you're limited to what someone else built. That's not a career; that's a hobby. Programming gives you the ability to solve problems no tool can solve out of the box. What "programming for cybersecurity" actually means It's not software engineering. You don't need to build a full web application or master design patterns. Instead, you use code as a tool for investigation, automation, and exploitation (ethically, of course). Different roles need different levels of programming: · SOC analysts might write Python scripts to correlate logs or query APIs. · Penetration testers write proof-of-conc

Lea's pushing back on light/dark mode implementations that display three state options for visitors: light, dark, and system. Dark mode toggles: two states are enough originally handwritten and published with love on CSS-Tricks . You should really get the newsletter as well.

Part 1 of 2. This part covers getting a kernel that can actually host virtual machines. Why bother I wanted a box that could run a dozen Android instances at once — real ones, not emulated-on-x86 ones — to benchmark peer-to-peer sync behaviour at scale. Native arm64 Android on native arm64 silicon, no translation layer, enough cores and RAM to make the peer count interesting. The Minisforum MS-R1 looked ideal. It's built on the CIX P1 ("Sky1"), a 12-core ARMv9 SoC, and it's one of the first genuinely affordable ARM desktops with server-class amounts of memory. Google's Cuttlefish — AOSP's official virtual device — runs arm64 Android guests on arm64 hosts with KVM acceleration, with a --num_instances=N flag that does exactly what I wanted. Everything lined up. Then I hit this: $ sudo modprobe vhost_vsock modprobe: FATAL: Module vhost_vsock not found in directory /lib/modules/6.6.10-cix-build-generic This post is what it took to fix that. If you have this hardware and want to run VMs on it, you'll hit the same wall, and there are four separate traps between you and the other side. I hit all of them so you don't have to. Rough time: an afternoon. Most of it is a compile you can walk away from. The problem: no vhost, no Cuttlefish Cuttlefish uses vsock — a virtual socket transport — for all communication between the host and its guest VMs. ADB, logs, control messages, everything. Without /dev/vhost-vsock , Cuttlefish doesn't start. It's not a soft dependency. The kernel Minisforum ships is 6.6.10-cix-build-generic . Check what it thinks about virtualization: grep -E 'VHOST' /boot/config- $( uname -r ) On mine, the output was more interesting for what was missing than what was there: # CONFIG_VHOST_NET is not set CONFIG_VHOST_VSOCK doesn't appear at all — not even as "is not set". That happens when the parent CONFIG_VHOST symbol is disabled, so Kconfig never emits the dependent symbols. The vendor didn't disable vsock specifically; they disabled the entire vhost subsyste