标签：#ux

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is free and source-available on Github. Star git-lrc to help devs discover the project. Do give it a try and share your feedback. You've been using the terminal for months/ years. Maybe you cd into a folder, ls around, run your script, and call it a day. That's fine. That's like knowing how to boil water and calling yourself a chef. But the terminal has layers . It's basically an onion that occasionally makes you cry, usually around 12 AM when a script fails silently and you have no idea why. So grab your coffee and let's talk about the command line tricks that actually make your life better. Not the "did you know ls -la shows hidden files" tier tips. Your Terminal Has A Memory. Use It. Most devs mash the up arrow like it's 2007 and they're trying to beat a Flash game. Stop that. Press ctrl-r instead. It searches your command history live. Type a few letters, it finds the last matching command. Press ctrl-r again to cycle back further. Found it? Hit Enter to run it, or the right arrow to drop it into your prompt so you can edit it first. ctrl-r ( reverse-i-search ) ` docker run ` : docker run -it --rm -v $( pwd ) :/app node:20 bash Pair this with ctrl-w (delete last word) and ctrl-u (nuke the line back to the cursor) and you'll start editing commands like you're speedrunning a text adventure. And if you're the type who types a whole essay of a command and then realizes you forgot something at the start, ctrl-a jumps to the beginning of the line and ctrl-e jumps to the end. No more holding the left arrow key like it owes you money. Pro tip: if you're a TUI fan and ctrl-r's default search feels a bit flat, check out McFly xargs Is The Friend Who Actually Shows Up Pipes ( | ) are great. They pass output from one command into another. But sometimes you don't want to pass output as input , you want to pass it as arguments . That's where xargs comes in, and once you get it,

The Linux Foundation has launched Akrites, a new industry-wide initiative aimed at defending the world's most critical open source software against a rapidly evolving generation of AI-enabled cyber threats. By Craig Risi

Sparrow is Raku automation framework comes with useful plugins people can use to automate infrastructure. Scc plugin allows to check Linux essential configuration files for security compliance. Here some examples: Sysctl $ sudo sysctl -a | s6 --plg-run scc@check = sysctl 12:24:07 :: [task] - run plg scc@check=sysctl 12:24:07 :: [task] - run [scc], thing: scc@check=sysctl [task run: task.bash - scc] [task stdout] 12:24:08 :: abi.cp15_barrier = 1 12:24:08 :: abi.setend = 1 12:24:08 :: abi.swp = 0 12:24:08 :: abi.tagged_addr_disabled = 0 12:24:08 :: debug.exception-trace = 0 12:24:08 :: dev.cdrom.autoclose = 1 12:24:08 :: dev.cdrom.autoeject = 0 12:24:08 :: dev.cdrom.check_media = 0 12:24:08 :: dev.cdrom.debug = 0 12:24:08 :: dev.cdrom.info = CD-ROM information, Id: cdrom.c 3.20 2003/12/17 12:24:08 :: dev.cdrom.info = 12:24:08 :: dev.cdrom.info = drive name: 12:24:08 :: dev.cdrom.info = drive speed: 12:24:08 :: dev.cdrom.info = drive # of slots: 12:24:08 :: dev.cdrom.info = Can close tray: 12:24:08 :: dev.cdrom.info = Can open tray: 12:24:08 :: dev.cdrom.info = Can lock tray: 12:24:08 :: dev.cdrom.info = Can change speed: 12:24:08 :: dev.cdrom.info = Can select disk: 12:24:08 :: dev.cdrom.info = Can read multisession: 12:24:08 :: dev.cdrom.info = Can read MCN: 12:24:08 :: dev.cdrom.info = Reports media changed: 12:24:08 :: dev.cdrom.info = Can play audio: 12:24:08 :: dev.cdrom.info = Can write CD-R: 12:24:08 :: dev.cdrom.info = Can write CD-RW: 12:24:08 :: dev.cdrom.info = Can read DVD: 12:24:08 :: dev.cdrom.info = Can write DVD-R: 12:24:08 :: dev.cdrom.info = Can write DVD-RAM: 12:24:08 :: dev.cdrom.info = Can read MRW: 12:24:08 :: dev.cdrom.info = Can write MRW: 12:24:08 :: dev.cdrom.info = Can write RAM: 12:24:08 :: dev.cdrom.info = 12:24:08 :: dev.cdrom.info = 12:24:08 :: dev.cdrom.lock = 0 12:24:08 :: dev.raid.speed_limit_max = 200000 12:24:08 :: dev.raid.speed_limit_min = 1000 12:24:08 :: dev.scsi.logging_level = 68 12:24:08 :: dev.tty.ldisc_autoload = 1 12:24:08

Users judge a mobile app in the first few seconds, and they judge it harshly. A slow launch, stuttering scroll, or a device that runs hot will sink an otherwise good app faster than a missing feature. Performance isn't one metric — it's four distinct areas, each with its own causes and fixes. Here's how to keep all of them healthy. Startup time — the first impression Time from tap to usable screen is the metric users feel most. Every extra second measurably increases abandonment. The usual culprits are doing too much before the first frame: heavy synchronous work at launch, loading data you don't yet need, and oversized bundles. Fixes: Defer non-essential initialization until after the first screen renders Lazy-load features and screens instead of loading everything upfront Show a real first screen fast, then hydrate data — don't block on the network Trim your dependency footprint; every library adds to startup cost Rendering — kill the jank Smooth means hitting the device's frame budget (about 16ms per frame for 60fps). Dropped frames show up as stutter during scrolling and animation. The main causes are doing heavy work on the UI thread and rendering more than you need. Virtualize long lists so only visible rows render (FlatList, RecyclerView equivalents) Move expensive work off the main thread Avoid unnecessary re-renders — in React Native, memoize and keep render functions cheap Optimize images: right-sized, cached, and in efficient formats Memory — don't get killed The OS terminates apps that use too much memory, and users read that crash as your bug. Leaks and oversized assets are the main offenders. Watch for retained references, unbounded caches, and full-resolution images held in memory. Load and decode images at display size, release resources when screens unmount, and cap in-memory caches. Battery and network — the invisible costs Users blame the app that drains their battery even if they can't name why. The big drains are aggressive polling, chatty netwo

Abertura Eu sempre participei de comunidades de tecnologia: grupos de estudo do Google,...

Both vulnerabilities allow untrusted users to gain root privileges.

Lost an evening to this, so you don't have to. The fix everyone hands you is a single checkbox that quietly downgrades how your Mac stores its password. The clean alternative — Kerberos, the exact thing your iPhone already uses — is "impossible" according to three sources I dug up, one of them Apple's own Heimdal source. They're wrong. What follows is the whole path: why it breaks, why the popular fix is the bad one, and the two setups that actually work (a one-shot command and a hands-off automount). My Mac mini shares a folder over SMB. My iPhone mounts it fine. My Linux box: $ smbclient -L 192.168.0.153 -U tmlr%remote session setup failed: NT_STATUS_LOGON_FAILURE Same username, same password, rejected. Every "fix" on the internet ends with "turn on Windows File Sharing for that user on the Mac." That works, and it's the wrong answer. Here's why, and what to do instead. The problem The credentials are correct — the iPhone's connecting just fine. The handshake even completes; run it with -d3 and you'll see the full NTLMSSP exchange finish before the Mac rejects you. So this isn't networking, isn't the password, isn't the SMB dialect. It's authentication, and only Linux hits it. Why: two doors, one account macOS keeps several credentials for a local account, not one. Look: $ dscl . -read /Users/tmlr AuthenticationAuthority AuthenticationAuthority: ; ShadowHash ; HASHLIST:<SALTED-SHA512-PBKDF2,SRP-RFC5054-4096-SHA512-PBKDF2> ; Kerberosv5 ;; tmlr@LKDC:SHA1.XXXX ; LKDC:SHA1.XXXX ; Two things matter in there: HASHLIST is SALTED-SHA512-PBKDF2 (login) and an SRP verifier. There is no NT hash. There's a Kerberosv5 identity in a realm called LKDC:SHA1.<40 hex> . SMB auth has two doors into this account: NTLMv2 — validates against a stored NT hash. Linux smbclient and mount.cifs knock here. Kerberos — validates against the Mac's built-in Local KDC (LKDC), which every Mac runs. Apple clients knock here. Your iPhone walks through the Kerberos door and never touches the NT hash

I wanted to understand how malloc actually works under the hood. Most explanations I found online described what an allocator does, but completely skipped over the "why" behind its design decisions. Rather than stopping at theory, I decided to build a cross-platform allocator in C that implements malloc , calloc , realloc , and free from scratch. This article documents the design of that allocator, the architectural tradeoffs I faced, and the core concepts I had to learn along the way. Table Of Contents Design Decisions Architecture Modern Allocator Strategies Core Concepts What's Next Project Overview A custom memory allocator does not create physical memory. Instead, it requests pages of raw virtual memory from the operating system and manages how that memory is partitioned, reused, resized, and released by the application. The goal of this educational project is to implement C's core memory management API using a modular, cross-platform architecture inspired by design principles found in modern allocators, rather than relying on legacy, single-platform tricks. Design Decisions #1: Why I am Skipping sbrk While many classic tutorials use sbrk for educational implementations, I deliberately chose a 100% mmap -based approach for two major reasons: sbrk is a fragile global bottleneck. It works by moving a single pointer (the program break) up and down. This means the allocator assumes it owns a contiguous line of memory. If a third-party library or another thread in the program secretly calls sbrk behind the scenes, the allocator's memory layout can break instantly. mmap , by contrast, provides isolated, independent chunks of memory. Cross-Platform Symmetry. Windows has absolutely no equivalent to sbrk , but it has a direct equivalent to mmap : VirtualAlloc . If we used sbrk , our architectural abstraction ( os_alloc ) would become awkward because Linux would deal with a moving pointer while Windows dealt with independent pages. Using mmap keeps the abstraction perfec

If you've been monitoring Linux servers for any length of time, there's a good chance node_exporter was the first thing you installed. It's lightweight, reliable, and exposes a huge amount of machine metrics for Prometheus to scrape. For years, it has been the default answer. As your infrastructure grows, though, your monitoring stack usually grows with it. First comes log collection. Then traces. Before long you're running node_exporter , a log shipper, and maybe another telemetry agent. Each component has its own configuration, service unit, upgrade cycle, and failure modes. Grafana Alloy changes that by consolidating those responsibilities into a single telemetry agent. This post walks through migrating from node_exporter to Alloy on a real fleet, one server at a time, while maintaining continuous visibility throughout the process. These are the exact steps that survived contact with production on the Irin monitoring stack, not the idealized version that looks clean in a diagram. TL;DR If you're already running node_exporter , don't replace it overnight. Install Grafana Alloy alongside it, configure Alloy's built-in prometheus.exporter.unix component, verify that metrics are reaching your remote Prometheus instance, and only then retire node_exporter. Migrating one server at a time minimizes risk, preserves visibility, and positions your infrastructure for logs, traces, and future telemetry without deploying additional agents. The real difference is the direction of travel Before getting started, it's worth understanding what actually changes. This isn't simply replacing one monitoring agent with another. node_exporter is a server. It listens on a port, typically 9100,and waits for Prometheus to connect and scrape metrics. That means every monitored machine needs an open endpoint, network connectivity from Prometheus, firewall rules, and scrape configurations. Alloy flips that model around. Instead of waiting for Prometheus to connect, Alloy collects metrics loca

Installing Docker on Ubuntu should be simple, but in practice several Docker-shaped options compete for the same command name, each with different packaging, upgrade behavior, and security implications. This guide compares every major install path so you can pick the one that fits your machine. The options you will encounter include: docker.io from Ubuntu repositories docker-ce from Docker's official APT repository Docker from Snap Docker Desktop manually downloaded .deb packages the Docker convenience script rootless Docker Although they all provide container tooling, they are not interchangeable packages. The best choice depends on whether the machine is a developer workstation, a CI runner, a small server, a self-hosting box, or a production host. My default recommendation is calm but firm: for most technical users on normal Ubuntu machines, install Docker Engine from Docker's official APT repository. Use Ubuntu's docker.io only when distribution integration matters more than upstream Docker packaging. Avoid the Snap package unless you specifically want Snap behavior and understand its limits. Rootless Docker is worth knowing about, but it is not automatically the best default for every machine. This guide explains the tradeoffs, covers post-install security, and gives you clean installation paths for each method. Once Docker Engine is running, the Docker Cheatsheet is your daily command reference, and the Docker Compose Cheatsheet covers multi-container setups. Both sit alongside Git, VS Code, and CI/CD guides in Developer Tools: The Complete Guide to Modern Development Workflows . Quick Recommendation The table below summarizes which install path fits common scenarios. Use case Recommended install Developer workstation Docker official APT repo CI runner Docker official APT repo, version pinned if needed Small self-hosted server Docker official APT repo Production server Docker official APT repo, controlled upgrades Ubuntu-only conservative system Ubuntu docker.

Redpanda is a Kafka-API-compatible streaming platform written in C++ with no JVM and no ZooKeeper. This guide installs Redpanda on Ubuntu 24.04, secures it with a Let's Encrypt certificate and SASL/SCRAM authentication, tunes the kernel for production, verifies with a producer/consumer test, and exposes Redpanda Console behind Nginx basic auth. By the end, you'll have a secured, production-tuned single-node Redpanda cluster with a web console. Prerequisite: Ubuntu 24.04 server sized per Redpanda's CPU/memory requirements , non-root sudo user, and a domain A record (e.g. redpanda.example.com ). Install Redpanda $ sudo apt update $ curl -1sLf 'https://dl.redpanda.com/nzc4ZYQK3WRGd9sy/redpanda/cfg/setup/bash.deb.sh' | sudo -E bash Warning: Only run vendor setup scripts you trust — piped curl | sudo bash runs with root privileges. $ sudo apt install redpanda -y $ rpk --version Open the Firewall Port Service Purpose 9092 Kafka API Producer/consumer traffic 8082 Pandaproxy (HTTP) REST access for non-Kafka clients 8081 Schema Registry Avro/Protobuf schema versioning 9644 Admin API Monitoring, config, health checks 33145 Internal RPC Inter-node communication $ sudo ufw allow 9092,8082,8081,9644,33145/tcp $ sudo ufw allow 80/tcp $ sudo ufw allow 443/tcp $ sudo ufw reload Issue a Let's Encrypt Certificate Redpanda ships with plaintext networking by default, fine for a lab, not for anything else. $ sudo apt install certbot -y $ DOMAIN = redpanda.example.com $ EMAIL = admin@example.com $ sudo certbot certonly --standalone -d $DOMAIN --non-interactive --email $EMAIL Certbot stores certs under /etc/letsencrypt/live , readable only by root. Redpanda runs as its own redpanda user, so copy the certs into a dedicated directory: $ sudo mkdir /etc/redpanda/certs $ sudo cp /etc/letsencrypt/live/ $DOMAIN /fullchain.pem /etc/redpanda/certs/node.crt $ sudo cp /etc/letsencrypt/live/ $DOMAIN /privkey.pem /etc/redpanda/certs/node.key $ sudo cp /etc/letsencrypt/live/ $DOMAIN /chain.pem /etc/re

I love Nuxt and I really like TanStack Start. But which one is better? Or are they about the same? And if they are about the same, does it do anything my Nuxt setup can't, and is that worth leaving Vue for React? So I decided to build the same app in both frameworks and take a look. Read on below to find out! If you'd rather watch a video, check out the video on the same topic! The app In both frameworks I built a small GitHub user lookup app. You type a username, the profile gets fetched on the server, and the username lands in the URL as a ?user= query param so the result is shareable. Type ErikCH , hit enter, and the card renders. Refresh the page and it's still there. It has the same behaviour so the difference lies in the code. Difference one: server functions vs server routes On the Nuxt side we call a server route from useAsyncData . Server are the more idiomatic way to use Nuxt to call things on the server. <!-- app/pages/index.vue --> < script setup lang= "ts" > import { z } from ' zod ' import type { GithubUser } from ' ~~/server/api/github.get ' definePageMeta ({ props : route => z . object ({ user : z . string (). default ( '' ) }). parse ( route . query ), }) const props = defineProps < { user : string } > () const router = useRouter () const input = ref ( props . user ) const { data , error } = await useAsyncData ( ' github-user ' , () => props . user ? $fetch < GithubUser > ( ' /api/github ' , { query : { user : props . user } }) : Promise . resolve ( null ), { watch : [() => props . user ] }, ) function lookup () { router . push ({ query : { user : input . value . trim () } }) } </ script > The props option on definePageMeta maps the query into a typed page prop and re-runs on client navigation. useAsyncData fetches when there's a username and refetches whenever it changes. The conditional that returns Promise.resolve(null) skips the request on an empty query param, (or when you first load). The server route does the outbound call: // server/api/gith

Everyone knows Next.js is the default full-stack JavaScript framework in 2026. The job ads say so,...

Redux setup is a ceremony. You create a store, compose your reducers into a root tree, wrap your app in a Provider, register middleware, and configure enhancers — all before you write a single line of feature logic. SDuX Vault™ replaces that entire ceremony with two function calls and zero root configuration. Redux Store Ceremony A typical Redux application requires several files and configuration steps before state management is operational. Here is what a minimal Redux setup looks like for a single feature: // store.ts import { createStore , combineReducers , applyMiddleware } from ' redux ' ; import thunk from ' redux-thunk ' ; import { userReducer } from ' ./reducers/userReducer ' ; const rootReducer = combineReducers ({ users : userReducer , }); export const store = createStore ( rootReducer , applyMiddleware ( thunk ) ); // App.tsx — Provider wrapper required import { Provider } from ' react-redux ' ; import { store } from ' ./store ' ; function App () { return ( < Provider store = { store } > < UserList /> < /Provider > ); } That is 20+ lines of configuration across multiple files — and it only covers one feature. Add a second feature and you are back in the combineReducers file, composing another slice into the tree. Add middleware and you are threading enhancers through applyMiddleware . Add DevTools and you are composing composeWithDevTools on top. Every new feature touches the root configuration. Redux Requirement What It Does createStore() Creates the single global store instance combineReducers() Composes feature reducers into a root tree applyMiddleware() Registers middleware (thunk, saga, etc.) Provider Makes the store available to all components via context composeWithDevTools() Enables Redux DevTools integration ⚠️ Warning: Every entry in that table is root-level configuration. Adding a new feature means editing the root reducer composition, possibly the middleware stack, and potentially the Provider hierarchy. Root configuration is a shared depende

In 2008, Richard Thaler and Cass Sunstein needed an example simple enough to explain the whole of economic theory from a single application. They used a cafeteria menu. By moving the fruit to eye level and sending the fries to the periphery, they demonstrated that a slightly adjusted environment could convince thousands of students to make healthier choices. No one is stopped from choosing fries and the fries-loving student still chooses fries. But the undecided student chooses the apple, simply because it is now right in front of him. In 2017, Thaler was awarded the Nobel Prize in Economics for his body of work, including the development of “The Nudge Theory” with Sunstein. In the years that followed, product teams building mobile applications have taken to referring to any call-to-action on-screen as a nudge. The design of an effective nudge There are two requirements for a nudge to work reliably. The user should have an apparent desire for the thing they are being nudged toward, and the nudge should appear at the moment when this desire is at its peak. The first requirement ensures the user has a mental model of the target action, meaning they understand roughly what they are supposed to do. The second requirement serves to remove any extraneous context, ensuring the nudge does not fail due to poor timing. A checkout confirmation modal shown straight after launching the application will fail miserably as a nudge. The desire to checkout is non-existent at the launch moment, and the context of the action has little to do with the action itself. A tooltip shown after a specific number of unsuccessful attempts to checkout after viewing the cart, however, is a nudge. It has the desired behavior and the right timing. Why the difference shows up in the numbers In the example with Duolingo, the product team has effectively used the framing of an existing streak as a reference point for the next level of engagement. The players who saw streak-based progress notifications

In bioinformatics we are handling a lot of tabular data. Be it VCF files, tabular Blast output, or just creating a CSV or TSV samplesheet. Actually, one of my favorite tabular formats is by using SeqKit to convert Fasta or FastQ files to tabular format, as this allows to do various filtering operations by row , using standard unix tools if so wished. Scrolling through this type of data in the terminal can be messy to say the least though. Although CSVs can of course be imported into a spreadsheet software for viewing, it would be very powerful to be able to view them comfortably right from the terminal, isn't it? To take one example that fits within the code window of a blog post, let's take a selected set of columns from the CSV output from the Mykrobe tool. And to make it emulate another common problem with many csv formats, let's also use tr to convert the _ :s in the headers into real spaces (Mykrobe does not do this, but many other tools do): $ cat SOME_SAMPLE.csv | cut -d , -f 2,3,10,14,15,17,18 | tr '_' ' ' > selection.csv $ cat selection.csv "drug" , "susceptibility" , "kmer size" , "phylo group per covg" , "species per covg" , "phylo group depth" , "species depth" "Amikacin" , "S" , "21" , "99.672" , "98.428" , "372" , "347" "Capreomycin" , "S" , "21" , "99.672" , "98.428" , "372" , "347" "Ciprofloxacin" , "S" , "21" , "99.672" , "98.428" , "372" , "347" "Delamanid" , "S" , "21" , "99.672" , "98.428" , "372" , "347" "Ethambutol" , "S" , "21" , "99.672" , "98.428" , "372" , "347" "Ethionamide" , "S" , "21" , "99.672" , "98.428" , "372" , "347" "Isoniazid" , "R" , "21" , "99.672" , "98.428" , "372" , "347" "Kanamycin" , "S" , "21" , "99.672" , "98.428" , "372" , "347" "Levofloxacin" , "S" , "21" , "99.672" , "98.428" , "372" , "347" "Linezolid" , "S" , "21" , "99.672" , "98.428" , "372" , "347" "Moxifloxacin" , "S" , "21" , "99.672" , "98.428" , "372" , "347" "Ofloxacin" , "S" , "21" , "99.672" , "98.428" , "372" , "347" "Pyrazinamide" , "S" , "21" , "99.672"

Quick Note In my previous article, I mentioned that Linux Troubleshooting Flow for Beginners would be the final post in this series. While preparing it, I realized there were a few practical Linux skills every beginner should learn first. These topics will make the troubleshooting guide much easier to understand and follow. Before we wrap up the series, we'll cover: Package Management Finding Files & Text Viewing Files Efficiently File Compression Then we'll bring everything together in the final Linux Troubleshooting Flow for Beginners. Introduction Installing software on Linux is very different from Windows. On Windows, you usually download an .exe installer. On Linux, software is typically installed and managed using package managers . This is one of the most practical skills every Linux beginner should learn early. What is a Package? A package is a ready-to-install bundle that contains: The main program Required libraries Configuration files Documentation Examples: nginx , git , docker , curl , vim Think of a package as a ready-to-install software box. What is a Package Manager? A package manager is a tool that installs, updates, removes, and manages software packages. Instead of downloading software manually, you simply run a command. Example: sudo apt install git The package manager automatically: Downloads packages from trusted repositories Install required dependencies automatically Upgrade installed software Removes them cleanly Instead of manual downloading, you just run one command. Why Use a Package Manager? Without package managers, you would have to: Search for software manually Download files from websites Install dependencies yourself Update each application separately Package managers automate all of this. What is a Repository? Package managers download software from repositories. A repository is a trusted online collection of software packages maintained by your Linux distribution. Instead of downloading software from random websites, Linux install

Automation is the part of DevOps that actually earns the title. Day 6 was two of the most everyday automation tasks there are, and both had a trap sitting in plain sight. One Linux task, one AWS task. Schedule a recurring job with cron, and launch an EC2 instance from the AWS CLI. The tasks come from the KodeKloud Engineer platform if you want the same lab to work through. Cron: five fields, one rule that trips everyone Cron is the scheduler that has quietly run Linux automation for decades. You hand it a job and a schedule, and its daemon, crond, wakes up every minute to check whether anything is due. If that daemon is not running, nothing fires, so the first move is making sure it is installed and enabled. # Become root sudo su - # Install the cron daemon if it is missing yum install cronie -y # Enable it at boot, start it now, and confirm it is alive systemctl enable crond.service systemctl start crond.service systemctl status crond.service cronie is the package name on RHEL-family distros. enable makes the service survive a reboot, start brings it up right now, and status is how you confirm it is actually running instead of assuming it is. Now edit the crontab: # Edit the current user's crontab crontab -e # minute hour day-of-month month day-of-week command 0 2 * * * /path/to/script.sh # List what is currently scheduled crontab -l That line runs the script every day at 2am. The five fields, in order, are minute, hour, day of month, month, and day of week: minute: 0 to 59 hour: 0 to 23 day of month: 1 to 31 month: 1 to 12 day of week: 0 to 7, where both 0 and 7 mean Sunday Here is the rule that quietly breaks schedules. When you set both the day-of-month field and the day-of-week field to something other than a star, cron treats them as OR, not AND. So 0 0 13 * 5 does not mean midnight on Friday the 13th. It means midnight on every 13th of the month, and also every Friday, whichever lands first. If you actually want the AND, you restrict one field in cron and che

I built a daily Linux documentation site I created this site because I've noticed that Linux documentation is generally confusing. What is xybss? xybss is a simple site that publishes Linux documentation every day. No ads No tracking No JavaScript Just plain HTML docs I add at least one new command every day. Who is it for? Beginners learning Linux Anyone who needs a quick reference People who want simple, clean docs Current content Right now, the site covers basic commands like ls and rm. More commands are added daily. Check it out 👉 https://xybss.github.io Feedback is welcome

I missed the tiny "x" on a browser tab again today. Meant to close it, switched to it instead. Aiming a one-pixel pointer at an eleven-pixel checkbox is basically microsurgery, and somewhere along the way we all just accepted that. Here's the strange part: HCI research solved this twenty years ago. It just never shipped. The paper In 2005, Grossman and Balakrishnan published The Bubble Cursor at CHI. The whole idea fits in one sentence: Make the cursor's hit area a dynamic circle that always contains exactly one target. That turns out to be the same thing as always selecting the target nearest to the pointer. Picture the screen divided into Voronoi cells, one per clickable thing, and the cursor picking the owner of whatever cell it's currently in. The clever part is what it refuses to do. Naive "gravity" cursors snap to every link on the way to the one you actually want, and they get stuck. The bubble cursor grabs exactly one target by definition. The moment a second target becomes nearer, it switches. So it stays calm on link-dense pages, and the paper showed significant speedups in controlled experiments. Twenty years later our cursors are still naked, so I built it as a Chrome extension. It's called MagPoint . The core is about 30 lines A content script collects clickable elements ( a[href] , button , input , ARIA roles and so on) and, every frame, picks the one with the smallest point-to-rectangle distance: function pointToRect ( x : number , y : number , r : DOMRect ): number { const dx = Math . max ( r . left - x , 0 , x - r . right ); const dy = Math . max ( r . top - y , 0 , y - r . bottom ); return Math . hypot ( dx , dy ); } Clicks that land in the empty space near a captured element get re-routed to it. Past a max radius of 120px the magnet lets go, and empty-space clicks behave like the normal web. It also stands down while you type or select text, because getting yanked toward a link mid-sentence would be infuriating. The rule that kept me sane: the vis