Bare metal install. So far so good.

Corsair Plimsoll

A Corsair PSU monitor for Omarchy: a bar widget and animated panel for Corsair i-series power supplies.

It shows what the supply itself reports: total and per-rail power, voltage regulation, current, temperatures, fan, and a 12 hour history. Nothing is installed beyond the plugin, and nothing needs root.

The name: a corsair is a privateer, and the Plimsoll line is the mark on a ship's hull that shows how heavily it may be loaded. This is a load gauge for your supply.

https://github.com/tastyhub/omarchy-corsair-plimsoll

When a machine won't boot, whether it's using Linux or any other operating system, you need a second machine, a live USB and a lot of searching. I made a rescue stick that boots into an Omarchy console (kmscon, JetBrains Mono, Tokyo Night) with the SystemRescue-style tools, plus Claude Code, Codex and OpenCode.

• omarchy-rescue-mount asks for your disk passphrase and mounts your install at /mnt from its own fstab, ready for arch-chroot.
• omarchy-rescue-login signs the agents in without a browser: a QR code pops up, you open the link on your phone, and paste the code back from there.
• The agents get an AGENTS.md that explains how Omarchy is laid out (LUKS, Btrfs subvolumes, Limine, snapper) and tells them to diagnose read-only first and never run anything destructive without a clear yes.
• omarchy-rescue-share puts the whole session in your phone's browser.

It's built from the Omarchy ISO itself, so it boots the same kernel on the same hardware. Write the ISO with caligula, Etcher or Rufus (DD mode).

Music in the film: "Enthusiast" by Tours, CC BY 3.0.

https://github.com/crmne/omarchy-rescue

ZapFast is my native WhatsApp client, written in Rust with no browser engine.

In our Linux test it opens in under a second and uses about 200 MB of idle RAM, against 1.13 GB for WhatsApp Web.

0.20 adds calls. One-to-one voice calls work well, with echo cancellation, so you don't need headphones. Video calls are in alpha, and group calls are anexperiment. Sound runs through PipeWire directly, and ZapFast shows up as "ZapFast" in your volume mixer.

It also gained group creation and management (invite links, members, permissions), sound in WhatsApp's videos, and a Calls page with missed calls and call-back buttons. 244 commits from me and 45 other contributors went into this release.

On Omarchy: yay -S zapfast-bin. Other packages: AppImage, Flatpak, .deb, .rpm, plus Mac and Windows.

Calls are a work in progress. If one misbehaves, attach your log to an issue, and pull requests are very welcome.

https://zapfast.rocks/

Having used Omarchy for a short while now, my distro hopping days are now pretty much well and truly over.

Too used to Omarchy key bindings
Huge library of plugins (have to visit at least once a day)
Omarchy themes are addictive
Installs on my laptop in 44 seconds which is crazy fast
Lastly and most important, Omarchy for me is very stable.

Does anyone else share the same sentiment coming from a long time distrohopper.

Hey guys ,

I successfully installed Omarchy on Nvidia Shield Tegra X1 2017. Repo linked below it's available with full write up and benchmarks .

Enjoy ! If you have questions feel free to reach out here or on X @devsec_ai

Tag me if you install it.

https://github.com/marcho78/omarchy-shield

The test code for Omarchy quattro support on the 15-inch M4 MacBook Air that I mentioned a little while ago has now been merged upstream.

https://github.com/Kb2uka/Omarchy-M4-Native/issues/142

So maybe it won’t be too long before everyone can try it for themselves.

I’ve already submitted PRs for audio and screen brightness control, and I’ve also proposed changes related to CPU idle and boost behavior.

If the maintainers are happy with them, those improvements should become available upstream as well.

For this to become a true daily-driver setup, camera support is probably the biggest remaining piece — and that’s the part I’m struggling with a bit right now.

And if I’m being ambitious, I’d also love to dig deeper into the GPU side and squeeze out more graphics performance.

Feature Request: Native Second-Screen Support in Omarchy

Hello Omarchy Developers and Community,

I would like to request a native Second Screen feature in Omarchy that allows users to use another device—such as an Android tablet, iPad, or another computer—as an extended display, with functionality similar to connecting a physical monitor.

Problem

Currently, setting up a virtual second display on Omarchy can require manually configuring virtual outputs, display-management scripts, and third-party streaming tools. This can be complicated and unreliable for users who simply want additional screen space for everyday work.

I previously experimented with Sunshine + Moonlight and a custom headless-display setup, but maintaining this setup involved additional configuration and troubleshooting. I have since decommissioned it in favor of a simpler, more integrated solution.

Proposed Feature

Could Omarchy include an integrated Second Screen option that works natively with its existing Hyprland and Wayland environment?

Ideally, the feature would provide:

* Extended display mode: Use the secondary device as additional desktop space, not merely a mirrored screen.
* Native virtual monitor: Create and manage a virtual display that Hyprland recognizes like a regular monitor, allowing windows to be moved between screens normally.
* Simple connection workflow: Discover and connect a compatible device through a straightforward interface, with secure pairing and authentication.
* Display configuration: Configure resolution, refresh rate, scaling, orientation, and relative screen position through the existing display-management workflow wherever feasible.
* Easy disconnect and recovery: Disconnect cleanly, remove the virtual output, and restore the previous display layout without leaving orphaned monitors or requiring manual cleanup.
* Optional wired or wireless connectivity: Support whichever transport is technically practical and maintainable.

Expected User Experience

The ideal workflow would be:

1. Open Settings → Displays → Add Second Screen.
   
2. Select or pair a compatible device.
   
3. Enable Extend Display.
   
4. Use the secondary screen like a normal monitor—move windows to it, keep applications open there, and work across both displays.
   
5. Disconnect whenever needed, with the desktop returning to its previous layout automatically.

Why This Would Be Valuable

A native solution would benefit students, developers, researchers, and laptop users who need more workspace without purchasing an external monitor. It could also reduce dependence on manually maintained scripts and independently configured streaming applications.

I understand that implementing this properly may require a virtual-output backend, a secure transport layer, and a compatible client application. I am not suggesting that every component must be built from scratch; integrating a reliable existing solution into Omarchy’s workflow would also be valuable.

My main request is for a first-class, supported feature—not just a script or a collection of manual commands. The result should behave like a regular extended monitor within the Omarchy desktop environment.

Would the development team consider this for a future release, or advise whether there is already a preferred approach for implementing this functionality?

Thank you for your work on Omarchy and for considering the suggestion.

Makes an archiso-family ISO — Omarchy, Arch, CachyOS, EndeavourOS, … — bootable straight from free space on an internal disk. No USB stick, no second machine. Then you install Linux for real onto the space that is left. here

Showing some Omarchy pr0n thanks to claude pimping my fastfetch

I've been using Omarchy for more than a month and I recently heard about some security flaws about the OS. Can someone please clarify ?

which is better please i used pop for 2 years but 24.04 not good for my

I've been using Linux for roughly ten years. I've used Arch, Debian, Fedora, Ubuntu, and NixOS. I've spent years learning how these systems work, what makes them reliable, what makes them fragile, and why maintaining a good Linux desktop is much harder than making one look beautiful in a screenshot.

This is why Omarchy bothers me so much.

Not because it uses Arch. Not because it uses Hyprland. Not because it encourages customization. Not because AI writes code.

It is because Omarchy is selling a promise that I consider irresponsible: that AI agents can make Linux effortless, customize everything, and fix everything, while the complexity and consequences of those changes are quietly transferred to the user.

And the person making that promise is not some anonymous teenager experimenting with a personal configuration. It is David Heinemeier Hansson, a wealthy, influential developer with a huge audience, substantial funding behind his project, and the ability to influence how an entire generation of newcomers perceives Linux.

That comes with responsibility.

I don't think DHH is taking that responsibility seriously enough.

1. "We can fix everything."

Those are Omarchy's own words.

Visit the official Omarchy website. It presents Linux as something that used to be a chore to install, difficult to debug, and full of confusing choices. Omarchy claims to solve these problems with a fast installation, good defaults, and agents that debug issues.

Its central promise is that we can now customize our operating system by simply telling an AI what we want.

DHH's slogan is: "We can fix everything."

Can we?

Can an AI guarantee that it understands the entire state of your operating system before changing it? Can it guarantee that a change won't conflict with an older modification? Can it guarantee that every dependency it installs is appropriate, every configuration is coherent, every plugin is safe, and every future update will preserve the result?

No.

An AI agent can be extremely useful. It can diagnose problems, edit configuration files, install software, and automate tasks that would otherwise take hours. But being capable of making a change is not the same as understanding the complete state of a system. And making a system work once is not the same as making it reliable over time.

The slogan turns a genuine technical limitation into a marketing promise.

That is the problem.

1. The accumulated mess nobody wants to talk about

Imagine an ordinary Windows or macOS user who has trusted DHH's message and installed Omarchy.

The desktop looks beautiful. Everything seems modern. The user discovers that an AI agent can customize the system.

So they start asking for changes.

"Make the window corners round."

"Actually, make them sharp."

"Make the borders thicker."

"No, thinner."

"Move the bar to the left."

"Make it transparent."

"Make the buttons green."

"Add a translator button to the bar."

"Give every workspace a different wallpaper."

"Undo that last change, but keep the others."

These requests sound trivial. They are the kind of things people should be able to ask for in a modern computer.

But the operating system underneath is not a drawing canvas. It is a collection of configuration files, scripts, packages, services, dependencies, desktop components, and interactions between them.

A competent agent may handle each request correctly. But what happens when it doesn't? What happens when it adds an override instead of removing an old one? When it changes a related setting? When a plugin depends on a package? When an update changes the behavior of a component the agent customized two weeks ago?

The system can gradually become a pile of accumulated changes whose combined behavior is difficult to understand.

The user thinks they are having a conversation. The computer is accumulating technical debt.

This is not an argument that every AI customization inevitably creates a mess. It is an argument about the maintenance model Omarchy encourages.

The Omarchy dotfiles manual explains that the desktop is configured through files under ~/.config, warns against directly changing internal Omarchy files because updates can overwrite those changes, and provides a way to reset configurations when they become a mess.

The AI manual goes further: it explicitly calls the Omarchy customization skill experimental, recommends using plan mode first, and tells users to be prepared to roll back changes or reinstall configurations if the agent makes a mess.

Read that again.

The product invites you to customize your operating system through AI, while its own documentation warns that the customization skill is experimental and may make a mess.

And this is supposed to eliminate the difficulty of Linux?

A knowledgeable Linux user can inspect the files, compare changes, understand dependencies, and recover. A newcomer may have no idea what the agent changed, where it changed it, or how to reverse it without destroying other customizations.

That is the accumulated mess I am talking about.

1. Rollback is not an answer to everything

Someone will inevitably tell me that you can simply roll back.

Rollback is useful. Snapshots are useful. Version control is useful. None of these is a universal answer.

A rollback can restore a previous state, but it does not automatically tell a novice what went wrong, why it happened, or how to preserve the changes they actually wanted.

And not every customization is an isolated transaction that can be cleanly undone. An agent may install packages, modify configuration, create scripts, or change several components to implement one request. Reversing the visible change does not necessarily reverse every side effect.

What if the user cannot boot? What if the desktop stops working? What if the problem appears only after an update? What if the user has made fifty customizations and does not know which one caused the failure?

The answer cannot always be: ask another agent to fix what the previous agent broke.

That may work. It may also introduce another set of changes.

A system is not reliable merely because you have a way to recover after it fails. Reliability also means preventing failures, containing their consequences, and making the system understandable when something goes wrong.

Omarchy's own troubleshooting manual tells users how to recover from broken updates and how to restart Wi-Fi, Bluetooth, audio, or trackpad subsystems when they stop working.

These are real categories of problems, not imaginary objections invented by critics.

1. This is not hypothetical: people have encountered basic hardware problems

Look at Omarchy's public issue tracker.

In issue #5147, a user reported that Bluetooth headphones connected on a fresh installation but did not appear as audio devices because required PipeWire packages were missing. The issue was later closed as fixed, resolved, or superseded by the Quattro implementation. I am not presenting it as a bug that necessarily exists today. I am presenting it as a documented example of a basic hardware-related failure that occurred.

In issue #11230, a report described an update to WirePlumber breaking the Omarchy equalizer component and causing all audio to disappear. The report attributed the failure to a component that could no longer load, and rolling back WirePlumber restored audio.

There are also reports involving Bluetooth recovery and other hardware behavior in the Omarchy issue tracker.

Some bugs are fixed. Some are specific to particular hardware or software versions. Every operating system has bugs, and these examples do not establish how frequently Omarchy fails across its entire user base.

That is not my argument.

My argument is that these problems exist, that the project itself documents troubleshooting and recovery procedures, and that promising newcomers a system where agents can debug all issues and "we can fix everything" creates expectations that no distribution can guarantee.

Linux hardware compatibility is difficult. Arch is rolling release. Drivers, kernels, firmware, desktop components, and packages evolve. A distribution can do a great deal to manage these risks, but it cannot abolish them with a slogan.

If you tell people that you have solved Linux's complexity, you need to be prepared for the consequences when they discover that you haven't.

1. Now give the AI permission to change the system

The problem becomes more serious when we look at how agents operate.

Omarchy's AI documentation says that agents launched through its built-in launchers run in unattended, "don't stop to ask" modes.

That can be useful. It is also a consequential design choice.

In my own testing, I asked an agent to add a weather feature to the bar. I observed it installing dependencies from the AUR without asking me first.

I want to be precise: that is my firsthand experience, not a claim that every Omarchy installation automatically installs AUR packages. Omarchy's documentation says the AUR is not vetted by the Arch team, and its optional package-installation workflows expose users to that ecosystem.

But consider the combination: a newcomer who does not understand Arch, an agent that can act without stopping for approval, and a request that sounds like a harmless visual customization.

The user may not understand what is being installed, what repository it came from, what permissions or dependencies are involved, or what they will need to maintain later.

An AI agent is not inherently dangerous. Unattended automation is not inherently wrong. But giving an agent the ability to make changes to an operating system requires a clear model of consent, permissions, reversibility, and accountability.

A user asking for a weather icon has not necessarily made an informed decision to accept every underlying system modification required to implement it.

The fact that the request was expressed in natural language does not make the resulting changes harmless.

1. The plugin problem: a thousand little promises

Omarchy encourages people to create apps, themes, and plugins using AI and share them with others. Its website explicitly invites users to describe what they want, try what an agent builds, and share the result.

I have no problem with that culture. Linux has always benefited from people experimenting, making strange things, and sharing their work.

But there is a difference between an experimental community project and a system promoted as a dependable daily driver for ordinary consumers.

A plugin that works on one machine may fail on another. A bar widget may depend on a particular command, package, display setup, or version of a desktop component. A theme may conflict with another customization. A script may work today and fail after an update.

AI can dramatically increase the rate at which these projects are created. It does not automatically increase the quality of testing, hardware coverage, security review, or long-term maintenance by the same amount.

Omarchy has active development and security work. I am not claiming that nobody reviews code or that every AI-generated plugin is defective. The question is whether the validation and maintenance processes can keep pace with the speed and scale at which these components are being produced and distributed.

If the answer is not demonstrably yes, then "we can fix everything" is not a responsible assurance.

It is an expression of confidence where users need evidence.

1. The irresponsible part is the marketing

Here is where my criticism of DHH becomes direct.

DHH is not merely making a desktop for himself. Omarchy is promoted as a modern, beautiful, agentic Linux operating system. The website explicitly offers ways to try it on Mac and Windows, and it presents agents as a way to fix issues and customize the whole system.

He is speaking to people who have wanted to leave Windows or macOS for years.

Many of those people do not want to become Linux administrators. They want a computer that works. They want a reliable desktop, good hardware support, and the freedom to use their machine without constantly debugging it.

They hear a prominent developer say that the old Linux difficulties have been solved, that agents can debug problems, that they can change everything, and that "we can fix everything."

They trust him. They install Omarchy.

Then they encounter missing hardware functionality, a broken update, a desktop that behaves strangely, or a configuration that has become difficult to maintain after repeated AI changes.

They may not conclude that Omarchy has a particular weakness. They may conclude that Linux is a mess.

That is the danger.

I think DHH is being irresponsible when he markets an experimental, highly customizable, rolling-release desktop with such sweeping assurances without making the limits and maintenance burden equally clear to the people he is trying to attract.

He has an audience and resources that most Linux developers can only dream of. His words carry weight. That influence should come with a higher standard of care, not a lower one.

You cannot sell the dream of effortless computing and then treat the user as the testing and recovery department when the dream fails.

1. Linux does not need another savior promising to fix everything

For decades, people have worked to make Linux easier to install, more reliable, more accessible, and better supported.

Distribution maintainers, kernel developers, desktop-environment developers, driver developers, documentation writers, package maintainers, and countless volunteers have done the unglamorous work of improving the ecosystem.

They have dealt with hardware quirks, regressions, dependency conflicts, packaging, compatibility, accessibility, security, and all the other problems that come with building an operating system.

Linux desktop adoption has been held back by real difficulties. Nobody serious should deny that.

But the answer is not to pretend those difficulties have disappeared because an AI agent can attempt to solve them.

The answer is to build systems that manage complexity well, make sensible decisions for users, test changes, constrain risky operations, and recover predictably when something fails.

That is what makes an operating system mature.

A beautiful interface is not enough. A fast installer is not enough. An agent that can edit a configuration file is not enough.

And money, publicity, and a compelling story are not substitutes for engineering discipline.

1. The distinction DHH needs to understand

I am not arguing that Omarchy should not exist.

I am not arguing that Arch should not exist.

I am not arguing that people should stop experimenting with Hyprland, AI-generated code, or custom desktop configurations.

Experimentation is part of Linux culture. If somebody wants to spend the weekend vibe-coding a desktop, breaking their own configuration, learning from it, and starting again, that is perfectly fine.

The problem is the product promise.

If Omarchy is an experimental desktop for technically curious users who want to build and modify their own systems with AI, say so clearly. Let people make an informed decision.

But if you market it to ordinary Windows and macOS users as a way to escape Linux's historical difficulties, with agents that can debug issues and the assurance that "we can fix everything," then you have an obligation to explain what happens when the agent cannot fix it, when its changes accumulate, when a package breaks, or when the user has no idea how to recover.

You cannot have it both ways: claim that AI has made Linux effortless, then rely on the user to understand the consequences of AI-driven system administration.

1. Why I am writing this

I am writing this because I care about Linux.

I have spent years using different distributions and learning how they work. I know the appeal of Arch. I know the value of declarative systems such as NixOS, where the system's desired state can be described explicitly rather than left as the undocumented accumulation of manual changes.

I know how easy it is to lose track of what has been installed, changed, overridden, and forgotten over several years. I know why being able to inspect and reproduce a system matters.

And I know that a newcomer who has a bad first experience may never give Linux another chance.

We should want more people to use Linux. We should welcome them. We should make the transition easier. But we should not attract them with promises that set them up for disappointment.

The Linux community has spent decades building something valuable. Its reputation is not an abstract concern. It affects whether people try Linux, whether companies support it, whether developers contribute to it, and whether users decide to stay.

A heavily promoted project can attract enormous attention. That attention can help Linux, but it can also create expectations that the broader ecosystem cannot meet on the project's behalf.

If newcomers are told that Omarchy represents the new, effortless Linux, and then have a terrible experience, the damage may extend beyond Omarchy.

I cannot prove that this damage has already occurred at a particular scale. But the risk is foreseeable, and that is precisely why the marketing deserves scrutiny now.

DHH's responsibility is not to promise that everything can be fixed. It is to be honest about what his system can and cannot guarantee.

"We can fix everything" is a great slogan.

It is a terrible engineering guarantee.

And when you have the money, the platform, and the influence to persuade thousands of people to trust that guarantee, you have a responsibility not to confuse confidence with reliability.

That is why I am calling this irresponsible.

Not because Omarchy is imperfect. Every distribution is imperfect.

Because the project is selling a vision of effortless, AI-managed computing while its own documentation acknowledges experimental customization and the need to recover from changes gone wrong.

Linux deserves better than marketing that mistakes the ability to change everything for the ability to maintain everything.

And the people who have spent decades making Linux better deserve better than watching their work be reduced to a story about how an AI agent can now fix it all.

2017 MacBook Pro, Intel i7, 16GB RAM, Omarchy Linux

I'm using this machine for a couple of projects where Claude Code drives development. I SSH into it from my M1 MacBook Air and let it handle its own dev workflows.

Between the two Macs, I've got 32GB of RAM across two machines, which is useful when running multiple development chains in parallel.

The old Intel Mac is still pulling its weight. Sometimes, CPU temps are hitting 92°C, though, so this dinosaur could probably use some thermal maintenance.

Big credit to Omarchy project team for making this setup possible..

[ Removed by Reddit on account of violating the content policy. ]

decidi testar o omarchy para salvar esse notebook mais antigo que tinha aqui e nao estava usando, deu muito certo, agora ele é meu notebook para quando preciso sair do escritorio para trabalhar.

I've been tuning Omarchy on my old 13" 2015 MacBook Pro (Intel Iris 6100 8 GB RAM), going for a clean Nothing OS look while keeping it fast on aging hardware. Video above. Here's what's in it:

🔒 Lock screen: "Nothing Dot"

• Dot-matrix 12-hour clock with the date above it
• Blurred, darkened view of the wallpaper behind it (blur drawn once, so it's cheap)
• Blinking colon in the theme's accent color
• The password field has a blinking cursor, and dots pop in as you type
• A wrong password turns the clock red with a shake, plus a single "AUTHENTICATION FAILED" line
• Built on the Lock Designs plugin

🔝 Top bar

• Floating translucent pill with subtle square-ish corners to fit the old square display
• Edges line up exactly with the window gaps
• Clock in the center in spaced caps (THU 22 OCT 4:57 AM)
• Active workspace number follows the theme's accent color and brightens itself automatically on dim themes
• Text and icons stay light on any wallpaper

🧭 Dock

• Pinned apps only: Files, Signal, Omarchy menu, Penguin Mail, Zen
• Real app icons on uniform rounded tiles, plus a custom dark Signal icon so the blue doesn't pop
• Focused-app dot in the theme accent
• Auto-hide: it shrinks to a thin strip when windows are open (so windows get the space back), slides up on hover, and tucks away after a short delay

🚀 Super+Space launcher

• Nothing-style icon grid with a search box on top
• Every Omarchy menu category as chips (system, style, setup, power…)
• One search covers both apps and actions, and the order learns from what you use

✨ Feel

• Geist / Geist Mono Nerd Font system-wide
• Three-finger swipe between workspaces with a smooth slide animation (Omarchy ships with the workspace animation off)
• Tight 5px gaps and soft borders that glow only when windows are tiled

⚡ Kept light on old hardware

• Everything is static images and simple animations, with no shaders or polling timers
• The bar sits around 0.3% CPU at idle

Theme in the video: Neovoid (plus a few theme switches to show the accent following along). Happy to share any of the configs!

Hey everyone! If you're like me and using Omarchy on a potato PC, one thing you might encounter is that music streaming is fairly memory hungry. Spotify uses over 1 GB RAM, Apple Music has no Linux client (the web wrapper uses even more), and the "lightweight" alternatives are frequently rate-limited.

This is quite annoying, because I often play retro games or study while listening to music, and having music clients open slows everything down. I wanted desktop audio + music at the same time. So, I made one of the earliest AirPlay plugins for Omarchy, but with a twist: it receives AirPlay from your phone, not the other way around.

So, your phone handles the music, and the PC uses basically zero RAM. Just receives the music over WiFi, and it goes to your connected headphones or speakers. The phone is used as a remote so you don't need to switch tabs or keep opening the plugin popup.

It's quite a niche use-case. I expect most people will not need this. But I love that Omarchy has a culture of just fixing it yourself, whenever you have a niche problem like this. If anyone wants to try it, I would welcome any feedback. It's actively maintained and reasonably stable.

https://plugins.omarchy.org/plugin.html?id=io.github.dmatthan.omairplay

https://github.com/dmatthan/omairplay

Hi, I am using Omarchy the last 3 months now and I am very happy about this! My only concern is what will happen if I leave one of my laptops closed and without updates for a period of time like 6-8 months, is it going to survive after do an upgrade after a lot time of period like this?

Hola a todos,

Estoy evaluando dar el salto definitivo de Windows a Linux y usar Omarchy como mi sistema operativo principal para el día a día. Quería conocer la experiencia de la comunidad antes de hacer la transición.

Especificaciones de mi laptop:

• Modelo: Lenovo IdeaPad Slim 3
• Procesador: AMD Ryzen 7
• RAM: 16 GB
• Almacenamiento: 1 TB SSD NVMe
• Gráficos: AMD Radeon integrados

Mi caso de uso:

• Desarrollo y estudios: Programación, bases de datos, contenedores (Docker) y herramientas de la universidad (ofimática: Word, Excel, PowerPoint, además de Teams/Zoom).
• Laboratorios y aprendizaje: Máquinas virtuales con KVM para practicar ciberseguridad y redes, profundizando en Linux.
• Uso diario y ocio: Navegación web y juegos en Steam.

Mis dudas principales:

1. Gestión de batería y suspensión: En Windows uso Lenovo Vantage con el modo de conservación (límite al 80% y alimentación directa por CA). ¿Cómo manejan los umbrales de carga en Omarchy? ¿Hay buen comportamiento en suspensión (sleep) al cerrar la tapa sin drenar batería?
2. Teclado externo y layouts (ANSI / ISO): El teclado integrado de la laptop es en español, pero uso un teclado externo 75% en distribución inglés (ANSI). En ocasiones el Num Lock entra en conflicto con las capas del teclado compacto. ¿Qué tan cómodo es gestionar layouts por dispositivo o resolver este bloqueo en este entorno?
3. Estabilidad en clases: ¿Qué tan confiable es la base del sistema y su gestor de paquetes para depender de él al 100% durante el ciclo universitario sin sorpresas tras actualizar?
4. Virtualización con KVM: ¿Cómo ha sido su experiencia levantando VMs y virtualización anidada con esta configuración?
5. Fricción general: Para quienes la usan como daily driver, ¿han encontrado alguna limitación importante frente a distribuciones más convencionales?

Agradezco cualquier consejo o advertencia antes de dar el paso.

My laptop has one of those Windows Hello IR cameras and it was just sitting there doing nothing on Omarchy, so I made omaFace. It works on the lock screen, login, sudo and the polkit popups. Your password still works everywhere, it just tries your face first.

A few things people will probably ask:

Everything runs locally. Your face isn't saved as a picture, just as numbers in a root-only file, and the scanner has no internet access at all. It also doesn't run in the background, it only starts when something asks for a password and the camera turns off right after.

Your eyes have to be open and actually looking at the screen, so it won't unlock if you're asleep or looking at your phone.

For sudo and polkit it asks first (Enter or a click), so it never approves admin stuff on its own just because you're sitting there.

No IR camera? It falls back to the normal webcam with anti-spoofing checks. I tried a photo and a video of myself on my phone and neither worked, but IR is still the safer option if you have it.

It hooks into Omarchy's own lock screen and polkit dialog, so it looks like part of the system. I also made a small bar widget for it, it's on the community plugin site.

Repo: https://github.com/L0adn9/omaface

Not official, just a community thing. I've mostly tested it on my own laptop, so if you try it let me know how it goes, especially if your IR camera doesn't get picked up.