vicinae

ired real thought was permissions. macOS gates a lot behind TCC, and the trickiest one is Full Disk Access: without it, file search (through Spotlight) will silently omit a lot of user protected files. FDA remains fully optional though, users that don't want to use Vicinae for file search don't need to grant it (although extensions may need it as well, such as for accessing Apple Notes) Qt/QML worked pretty much as expected on macOS, with no notable issues. Even my custom shaders get compiled to Metal automatically, without configuring anything. And the bundle, once trimmed, ended up very small: 24MB compressed in a .dmg, with all the Qt libraries included! On the performance side I'm also extremely satisfied, it feels very snappy. It's also very lightweight when it comes to RAM usage. Around ~100MB if we exclude the node process required to run third party extensions (technically optional, as none of the core features rely on it). Definitely a breath of fresh air when we see what happened to Raycast V2 :-) Had a lot of fun porting this, and it reinforced my love for Qt even more. Vicinae is fully open source (GPLv3). Happy to answer questions about the port!

each platform or something multi-platform [1] like Tauri or Kotlin Multiplatform? or are you going to copy the Raycast extension model - just run Node, expose some platform integration, and parse React render trees through "Glaze Runtime"? I've been working on a bug in Vicinae [2][3], and I've seen this model in action. it's very hard to make it perform well, but all it takes to achieve native look and feel is to just map React render trees to whatever system component OS offers. (in Vicinae's case, it's Qt. bet that it's done with SwiftUI on macOS and WinUI 3 on Windows.) [1]: there is a difference between "cross-platform" and "multi-platform". "cross-platform" means "I behave equally across platforms and have no awareness of native look and feel" (e.g. Electron, Unity, Flutter), while "multi-platform" means "I can adapt across platforms to the degree you need" (e.g. C/C++, Rust, KMP) [2]: https://github.com/vicinaehq/vicinae [3]: https://github.com/vicinaehq/vicinae/pull/1158

sk Encryption via LUKS. Which is also the direction Purism sounds like they’re going as they have no mention of fscrypt or something like systemd-homed and you only enter a decryption PIN on boot (like is currently done with their laptops). So with LUKS it only encrypts at the block level so the drive is fully unencrypted when it’s mounted and unlocked. A display manager’s lock screen only “locks” the device visually, it doesn’t / can’t re-lock the volume since it operates above LUKS. So if someone were to take your device while it was powered on in theory they could just extract everything without issue (although I’m not sure of what USB protections Purism has — there are things like USBGuard for linux, but that could be easily defeatable, I don’t know). It’s why I mentioned something like systemd-homed because it provides a way for user directories to be re-encrypted on logout/lock and prevent this. fscrypt also can do this and is part of why LEO can fail to extract user data in AFU on android devices. Sorry I kind of just dumped this all out I can elaborate more if needed. > Indeed, GNU/Linux phones can and probably will improve their security with time taking some things from Android. Ultimately this is my main problem with Linux phones. Eventually you come back to just re-inventing Android, maybe worse because you didn’t have the resources to speed run all of it’s security improvements, so who knows how long it’ll take Linux to catch up. I don’t know if I’m missing something but why not just fork AOSP, migrate it to a newer Linux kernel (since iirc AOSP is based on like a 4.xx linux kernel), and go from there? You’d have all the power management, security features etc and be detached from Google. > You can't just say this without any evidence. Maybe I overspoke here. More specifically a GNOME extension can definitely read from the clipboard/selections without a user knowing, like this one for example, which I used on my system running secureblue (which disabled xwayland by default): https://github.com/dagimg-dot/vicinae-gnome-extension https://github.com/vicinaehq/vicinae But there are others like this one: https://extensions.gnome.org/extension/4839/clipboard-histor... Now these probably aren’t malicious, but I would now wonder if a “good” extension can turn coat and start doing that. Of course GNOME extensions really aren’t ideal and if you’re on KDE or something else it probably doesn’t affect you. > Unless you switch off JavaScript, which is what I do. There are still significantly more security benefits than just disabling JavaScript though (which imo is not realistic for most users just due to how the web is today, really we should just be able to disable V8 and use Drumbrake instead). For example, Firefox on Android still lacks site isolated processes[1]. It also has no JIT sandbox or content sandbox and no type-based CFI. And unlike Chromium it seems like the Mozilla team doesn’t really have an interest in keeping up with ARMs latest security features and using them, such as Branch Target Identification and Pointer Authentication which Chromium takes advantage of[2]. Firefox has no progress on either of these[3][4]. Firefox also lacks a security-focused memory allocator, and cannot handle one (try using GrapheneOS’ hardened memory allocator (hardened_malloc) with any Mozilla apps on Linux or GOS). — [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1565196 [2] https://developer.arm.com/community/arm-community-blogs/b/op... [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1671152 [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1626955

irectly inside the launcher (though not all features are implemented yet). There’s also a native API package (@vicinae/api) for writing Vicinae-specific extensions with additional capabilities. This required writing a custom React reconciler — surprisingly straightforward, though still unpolished. Like Raycast, Vicinae ships with powerful built-in modules, but the goal isn’t to make a clone. I want it to grow into its own project that fits the FOSS model better, while staying compatible with the Raycast ecosystem. I also plan to bring it to other OSes eventually. I’d love feedback on the technical approach, and suggestions for what would make this useful to you. Contributions are very welcome — I’ve already been pleasantly surprised by how quickly people started helping. Docs: https://docs.vicinae.com Repo: https://github.com/vicinaehq/vicinae