omacom

github.com/omacom/omarchy/blob/quattro/manual/44-… but here they say > Please note that installing on an M-series Mac is not directly supported at this time.

Linux now beats macOS on Apple silicon GPU memory bandwidth. M1 Max, Omarchy: macOS: 361 GB/s Linux before: 241 GB/s Linux now: 368 GB/s The kernel never told the power controller the GPU was busy. One bit fixed it. linux-aurora#334

Omarchy RS 4.5 RC3 is Ready For Testing + Apple Silicon (M1, M2, M3, Neo) > ⚠️ This is a release candidate, not a final release. Expect bugs, rough edges, and the occasional thing that breaks outright. Run it on a test machine, or make sure you have a working backup (or a snapshot you know how to roll back to) before you upgrade a machine you depend on. Omarchy 4.5 is the first feature release since Quattro. It speaks 50 languages, gives every monitor its own workspaces, adds floating workspaces with a dock, rebuilds notifications, gathers how the desktop looks into a new Appearance menu, plays theme intros, and ships four new default apps: Hype, Monologue, Signed, and Disktree. Underneath, it installs in about half the time, it's faster from boot to theme switching, and it runs on NVIDIA N1x and Snapdragon X laptops. Try it on an existing machine with Update > Channel > RC, then Update > Omarchy. Please report anything that breaks on GitHub. Install on new machines with the ISO: x86_64: Download: iso.omarchy.org SHA256: 715d7c72d51c29a1e2db7b8f8562d54f0f5710b9c1c5a4243800be48fba24269 aarch64: Download: iso.omarchy.org SHA256: d5f38ba3bdd15175db0146826ca1a42c1722f717cbbc76de302f24aa80a23f9b Apple Silicon (M1, M2, M3, Neo): Download: mac.omarchy.org SHA256: 71f0a5ef4e7aa9b1da7ea88ed7641dfd087344d3fbb29fa2bb58192999b12910 Full Changelog: github.com/omacom/omarchy/releases/tag/v4.5.0-rc3

Made Hex available as a dictation option on Omarchy Dev. omarchy#17186

10 NEW Github Repos Every Claude User Must Use 🟢 Free PDF guide for this video: toolswithterry.com Ten GitHub repos that people who use Claude Code and other coding agents are talking about, and the one question that matters before you install any of them: which one is worth installing first? I read all ten READMEs and pulled the star counts, licenses and last commit dates from GitHub on October 29 and 30, 2026. Every claim in the video comes from the repo's own README or its GitHub page. In this list: Claude of Tanks (a browser tank game built with Three.js and Vite), Anydoc from Firecrawl (office files and PDFs to Markdown), Omarchy (a Linux distribution by DHH), Archify (interactive diagrams from an idea or a codebase), OpenMontage (an open source agentic video production system), Herdr (a runtime for your coding agents in the terminal), Claudex Loop by Chase AI (Claude plans, Codex challenges the plan), Orca (run Claude Code, Codex and more side by side in git worktrees), OmniRoute (a free AI gateway) and DeepSeek Harness (DeepSeek's open source agent harness). The free guide has the install line from each README, the license, the last commit date and a five minute checklist you can run on any repo before you trust it. CHAPTERS 0:00 Ten repos, one question 0:57 Claude of Tanks 1:47 Anydoc 2:49 Omarchy 3:38 Archify 4:40 OpenMontage 5:47 Herdr 7:43 Claudex Loop 8:55 Orca 10:18 OmniRoute 11:34 DeepSeek Harness 12:49 Which one to install first THE REPOS Claude of Tanks: Kevin-Liu-01/Claude-of-Tanks Anydoc: firecrawl/anydoc Omarchy: omacom/omarchy Archify: tt-a1i/archify OpenMontage: calesthio/OpenMontage Herdr: herdrdev/herdr Claudex Loop: chaseai-yt/claudex-loop Orca: stablyai/orca OmniRoute: diegosouzapw/OmniRoute DeepSeek Harness: deepseek-ai/deepseek-harness Star counts and commit dates change every day. Check the repo before you install anything, and read what a tool needs and what it can touch first. Which of the ten would you install first, and which repo do you use every day that should have been on this list? Tell me in the comments. #Claude #ClaudeCode #GitHub #AITools #CodingAgents

Omarchy RS 4.5 RC-2 Testing Begins! Omarchy v4.5.0-rc2 > ⚠️ This is a release candidate, not a final release. Expect bugs, rough edges, and the occasional thing that breaks outright. Run it on a test machine, or make sure you have a working backup (or a snapshot you know how to roll back to) before you upgrade a machine you depend on. Omarchy 4.5 is the first feature release since Quattro. It speaks 50 languages, gives every monitor its own workspaces, adds floating workspaces with a dock, rebuilds notifications, gathers how the desktop looks into a new Appearance menu, plays theme intros, and ships four new default apps: Hype, Monologue, Signed, and Disktree. Underneath, it installs in about half the time, it's faster from boot to theme switching, and it runs on NVIDIA N1x and Snapdragon X laptops. Try it on an existing machine with Update > Channel > RC, then Update > Omarchy. Please report anything that breaks on GitHub. Install on new machines with the ISO: x86_64: Download: iso.omarchy.org SHA256: bc32dad4991a50e8d372f76490eb78b2034ffeca46aace423d95871049978a8f aarch64: Download: iso.omarchy.org SHA256: ee885285d6cba0dfc9a9ead22cf5bcc203b9f460970721b3c0b8a1dca4c867a8 Full changelog: github.com/omacom/omarchy/releases/tag/v4.5.0-rc2

Omarchy 4.5 RC2 is now out and it includes our new F1 install technique that can almost get a full installation down to the time of a pitstop on the fastest machines (current record is 6 seconds!!). github.com/omacom/omarchy/releases/tag/v4.5.0-rc2 t.co

Omostrich 0.3.3: tighter signing grants and safer profile pictures Omostrich keeps your Nostr key on your own computer and signs for your apps from the Omarchy bar. Two releases landed this morning. Version 0.3.2 finishes the profile picture hardening that 0.3.1 started, and version 0.3.3 makes your signing permissions narrower and your approval prompts clearer, especially around direct messages. What changed in 0.3.3 "Always allow" now covers one kind of event, not everything. Before, remembering a signing request for an app meant that app could sign any kind of Nostr event without asking again. Now the button names the kind it covers, for example "Always allow sign kind 4 (DM)", and Authorized apps lists each app's grants kind by kind. Encrypt and decrypt prompts show who's on the other end. Each request shows the other person as a shortened npub (marked "(you)" when it's yourself) and whether you're encrypting to them or decrypting from them. Encrypt requests also show a short preview of the plain text. A kind 4 signing request shows its recipient, and DM ciphertext is no longer previewed. None of this goes into the log. The signer keeps running when notifications can't. If notify-send is missing or fails, Omostrich logs it once, with an error code only, and carries on instead of crashing. Smaller fixes: - Signing requests for kind 14 and kind 1059 (private messages and gift wraps) show a warning and can only be approved once, never remembered. - Your public key is handed out without a prompt only to an app that connected this session or that you've remembered. Anyone else gets asked. - Gift-wrap notifications look back two days, and unlocking no longer sets off a burst of old ones. What changed in 0.3.2 0.3.1 put limits on how big your cached profile picture could be, but the file could still carry compressed metadata that expands while the image is being read. A small, hostile picture could push the panel to several gigabytes of memory. Now the daemon rewrites the downloaded picture down to just the parts needed to draw it, with no re-encoding and no new dependency: - PNG keeps only the image data and the colour chunks it needs. An unknown critical chunk is refused. - JPEG drops comments, EXIF, ICC, XMP and Photoshop data. - GIF keeps the first frame only. - WebP keeps the image data and drops everything else. Animated WebP is refused, so the placeholder shows. Anything after the end of the image is dropped too, and a picture cached by 0.3.1 is fetched again on startup, so the cache only ever holds the stripped copy. This came out of the Omarchy plugin marketplace review (#12494). Why it matters Your signer should do exactly what you agreed to and nothing more. A blanket "always allow" was easy to click and hard to reason about later, and a DM prompt that doesn't say who it's for asks you to approve blind. Per-kind grants and clearer prompts mean you can see what each app is allowed to do and who your messages are going to. Upgrading Old blanket signing grants meant "sign any kind", and there's no way to tell which kind you had in mind, so they're removed the first time 0.3.3 starts. The app and its other grants stay, daemon.log names each affected app, and the app asks once more for each kind it needs. To update an existing install: cd ~/Projects/omostrich git pull npm ci ./install-daemon.sh ./install-plugin.sh systemctl --user restart omostrich The restart matters, because the running signer keeps the old code until it's restarted. The full notes are on the 0.3.2 and 0.3.3 release pages, the code is on GitHub, and more about Omostrich is at omostrich.com. Originally posted on blog.ninepointlabs.com.

Fixing the VFS5011 fingerprint reader on Omarchy My laptop has a Validity VFS5011 fingerprint reader and I wanted fingerprint auth on Omarchy. Enrolling worked fine. The verify right after it didn't, and the Omarchy setup script took that as a hard fail and never wrote the PAM config, even though my print was already enrolled. Turns out the reader just wedges after enrollment. A USB reset fixes it. The symptom Enrollment goes through, and the verification fails with this: failed to claim device: GDBus.Error:net.reactivated.Fprint.Error.Internal: Open failed with error: transfer failed omarchy-setup-security-fingerprint reads that as a failed setup and bails before touching PAM. So you end up with an enrolled print that is not used. Problem is im the chipset: Validity Sensors VFS 5011, USB id 138a:0017. It's tracked in omarchy#10091. Why it happens The VFS5011 gets stuck after enrollment. Reset the USB device and verify results. Reset the reader sudo systemctl stop fprintd sudo usbreset 138a:0017 sleep 2 sudo systemctl start fprintd Verification Your print is already there, so test before you redo anything: fprintd-verify You want to see verify-match. Enroll again only if verify still fails after a reset. Step 3: Finish the PAM config Same config omarchy-setup-security-fingerprint would have written. For sudo and polkit, add these to /etc/pam.d/sudo and /etc/pam.d/polkit-1. The first line skips fingerprint when the lid is closed, the second enables it: auth [success=1 default=ignore] pam_exec.so quiet /usr/bin/omarchy-hw-laptop-closed auth sufficient pam_fprintd.so For the lock screen, create /etc/pam.d/omarchy-lock-fingerprint: #%PAM-1.0 auth required pam_fprintd.so account include system-local-login Or, if your Omarchy is new enough to retry verify on its own, just rerun the setup after the reset: omarchy-setup-security-fingerprint Step 4: Confirm it works sudo -k sudo -v That should ask for your finger. Same for polkit prompts and the lock screen (Super + Ctrl + L). Notes - Enrollment is fine. Only the claim right after it fails. - If you have this same reader, the reset trick should apply to you too, not just on Omarchy. - Fix was ofc done with agents, as Omarchy is agent native

Asahi Linux 支持硬件解码了 我期待这个功能很久了，现在终于能用了，忍不住发帖分享一下。 硬件解码默认还没启用，需要自己稍微折腾一下： 1 ，需要设置 LIBVA_DRIVER_NAME=v4l2_request 环境变量，不设置的话就不能自动探测到合适的 VA-API driver 。 2 ，mpv 播放器需要加上 gpu-api=opengl 这个配置，不指定这个的话颜色是绿的，而且屏幕还会闪烁。 3 ，m2 设备上的 hevc 硬件解码我实测还不可用，需要自己编译 libva-v4l2_request 的源码，禁用 hevc ，不禁用的话用 mpv 硬解播放 hevc 视频会报错。 4 ，chrome 浏览器也需要自己编译 libva-v4l2_request ，用 omacom/libva-v4l2_request avd-fixes 分支最新的代码，否则画面也是一片绿。 另外我自行编译了 moonlight-qt ，用 v6.2.0 的代码，实测 h264 硬解效果非常好。 libva-v4l2_request 禁用 hevc 的方法如下： ⬢ d@macmini-m2_fedora-toolbox-44:~/src/libva-v4l2_request$ git diff diff --git a/src/codec_hevc.c b/src/codec_hevc.c index dd9b15a..8e27807 100644 --- a/src/codec_hevc.c +++ b/src/codec_hevc.c @@ -1393,7 +1393,7 @@ const struct v4l2r_codec v4l2r_codec_hevc = { .name = "hevc", .pixelformat = V4L2_PIX_FMT_HEVC_SLICE, .profiles = hevc_profiles, - .nb_profiles = 2, + .nb_profiles = 0, .priv_size = sizeof(struct hevc_context), .init = hevc_init, .uninit = hevc_uninit, ⬢ d@macmini-m2_fedora-toolbox-44:~/src/libva-v4l2_request$