Yeah I’m working on it, Linux is a big pain point especially Wayland
Once things are more or less ironed out on MacOS and Windows a lot of attention will be turned towards Linux
I know a lot of Linux PRs are open it just takes me so long to get around and test them. And often multiple different implementations trying to fix similar issues which is a lot of overhead sometimes
Is there any way people can help? From your last sentence, it sounds like another PR isn't it and the opposite might be needed. But would love to contribute with testing if helpful. I'm regularly jumping between XFCE, KDE, GNOME, Niri, etc..
Testers by far as the most needed thing, I do maintain a list of per platform people who help to test so if you drop a GitHub username (or email me) I will add you to the list and ping for help
Basically the biggest blocker is me being the sole maintainer and reviewer at the moment and it just ends up taking a lot of time for the scale of the project. Which is why it moves slow and features typically are much slower than someone can vibe code. I know each added feature inevitably has bugs so I try to be careful with them.
But also Linux has historically been a minefield, fixing something for someone breaks for someone else so yeah testers really needed. Or anyone with deeper Linux DE knowledge than I have. I’m much more accustomed to server based Linux distros
I have a personal fork of hyprvoice[0] which I use almost everywhere now (w/ the big cohere-transcribe running on a local vLLM instance). It does a similar thing, but that's not why I'm mentioning it; I think it's worth looking at because it's a clean reference for the few elegant ways you can implement text injection in modern Linux (wayland).
It supports ydotool[1], wtype[2] and "clipboard fallback with clipboard restore". The first two you can probably think of as AHK equivalents - they wire in at the input layer and inject keystrokes when injecting text. wtype is wayland-only and a bit less invasive, ydotool supports non-wayland also apparently, but I haven't tried it. Neither approach provides 'instant text' - you have to watch the text get typed out, and you don't touch your keyboard while it's happening; the clipboard implementation is fallback for a reason as it's the least reliable. The first two work 'well enough' though, and are fairly tunable.
The other thing hyprvoice does in probably the most linux-friendly and universal way is the 'hotkey handling'. The server creates a socket in /tmp that the cli can then ping when the user triggers the start/stop/cancel, and they do this by binding whatever their DE's keyboard shortcut mapping mechanism is to trigger `hyprvoice toggle` as a background shell command. This works extremely well and is much cheaper than you'd intuitively think coming from Windows. This way you don't have to interface with DE-specific global keyboard listeners etc, but leave that to the WM (that's not to say that your installer couldn't prompt the user to configure the keyboard shortcut for them with their detected WM, you just wouldn't do it in the software itself).
I haven't actually looked at your project in too much depth yet as I have a solution for this already, so apologies if none of the above is news to you. Hope it helps though - happy to poke around and contribute something if the gap's still there.
we have wtype and ydotool support as well in Handy, but it's not exactly a great out of the box experience always, but some of it is on me for poor linux packaging
I’m working on something similar for Linux. Would love to chat if this is interesting to you.
The idea is to bring the UX of OSX Snow Leopard back, adjusted for today’s possibilities (better developer experience, AI, etc.). I’m developing a DE, SwiftUI/AppKit-equivalent, and a bunch of reference apps I‘m personally missing in terms of quality (e.g. Raycast/Spotlight, Mail).
You would want to adjust it for today's display and input technologies. A high resolution OLED display deserves a different UI design than a 6-bit low-contrast TN LCD display did.
I agree that displays and input changed. But if you think in fundamentals, like clarity, readability, affordances, you tend to arrive at the right answers anyway.
Those principles survived CRTs, TN panels, Retina, touch, trackpads. They’re not tied to a specific technology.
Can you give me an example of a change in todays UI that was motivated by change in display quality?
> Can you give me an example of a change in todays UI that was motivated by change in display quality?
There are a lot of places where I now see a miniature thumbnail preview of a file's contents, where in the 1990s you would only have seen an icon corresponding to the file type. Those previews are enabled partly by faster IO and processors making the preview rendering cheap, but also by higher resolution displays making the previews a lot more useful than they could have been at 32 pixels or smaller.
While it's not exactly a quality change as the driving force, the proliferation of dark mode UIs is a result of OLED displays that draw meaningfully less power with darker content, so pushing users toward darker UIs helps battery life. And it looks much better on a display with decent black levels than it would on a crappy LCD that washes out all the dark colors.
> Can you give me an example of a change in todays UI that was motivated by change in display quality?
The extremely heavy "pinstripe" Aqua UI existed because displays were so low contrast at the time that it didn't look nearly as heavy. A much higher contrast display that actually displays blacks properly means it'd look more like visual noise.
Can you share a bit more on the small LLMs you've trained? I'm interested in the applicability of current consumer hardware for local training and finetuning.
I'm not the AI expert in the company but one of my colleagues creates image segmentation models for our specific use case. I've been able to run the PyTorch training code on my computer without any issues. These are smaller models that are destined to run on Jetson boards so they're limited compared to larger LLMs.
edit: just to be clear, I can't train anything competitive with even the smallest LLMs.
For me personally, blender uses ROCm and ROCm hiprt for Cycles tracing and cycles raytracing acceleration. I am using a Radeon RX 6800 and AMD Ryzen AI 7 350, and it works on Linux. ROCm HIPRT really does speed up cycles rendering (at the cost of more Vram usage). Of course, using the AMD driver on Linux, you get access to the system's RAM with GTT.
I've shared this example in another thread, but it fits here too. Few weeks ago, I talked to a small business owner who found out that Google's AI is telling users his company is a scam, based on totally unrelated information where a different, similarly named brand is mentioned.
We actually win customers who's primarily goal is getting AI to stop badmouthing them.
A desktop environment for Linux, visually inspired by OSX Snow Leopard with a touch of contemporary. Coming with compositor, apps like dock, finder, status bar, and a UI framework like AppKit. Scratching my own itch and would love to see if it can gain traction. Still in the early innings though.
what framework/techstack are you using? i'd love to see something built on top of GNUstep which is close to what OSX is originally based on. (don't know how much of that is still found in Snow Leopard)
The goal is not to use a similar tech stack e.g. GNUstep. Instead I'm focusing more on outcome - a desktop environment with a similar degree of polish and functionality without the need for third party tools.
To stay competitive and iterate fast I'm adding a high-level JS/CSS API on top of Wayland, think AppKit + SwiftUI. If you look over my shoulder it might look like I'm making a webapp, but on a custom browser.
We (Geostar.ai) work with many brands and companies that have experienced near-death situations caused by Google's AI Overviews. The negative impact this feature has had on people's livelihoods is heartbreaking to witness.
Just today, I met with a small business owner who showed me that AIO is warning users that his business is a scam, based on bogus evidence (some unrelated brands). It's a new level of bullshit. There's not much these businesses can do other than playing the new GEO game if they want to get traffic from Google.
Who knows if Google will even present any search results other than AIO a few years from now.
Would be interested to learn more about how and why this was coded in Common Lisp, in particular which value it provides specific to the problem being solved compared to other languages.
Ability to write at a very high level (and macros), incredibly fast when compiled, ability to use the repl on a live server for diagnosis and patching functions, language design choices work extremely well for parallel recursive hierarchical inference.
