Lux now prevents privilege escalation and malicious Lua scripts from doing any damage to your host system. After thousands of changes and hours of debugging, say hello to sandboxing! 🚀🔥
opencollective.com/lumen-labs/u...
I've finally done it. The sandboxing refactor for Lux is done,
after a lot of long winded planning and rewiring the codebase.
Now for the tedious cleanup phase 🔥
The sandboxing refactor for Lux is much larger than I had anticipated! The PR will be large but the upside is that packaging the project will become much easier as we will be able to ditch mlua as a dependency 🔥🔥
Additionally, Luanox support in Lux will further enhance security by using a service with stronger API keys and no manifest files.
Ideally, we will one day incrementally upgrade to TOML rockspecs instead of dynamic Lua files (which bring nothing useful other than security issues).
If all goes well, Lux will be hardened against an attack like this by limiting execution time and restricting access to I/O and the capacity to load dynamic libraries at runtime.
I am currently making a serious attempt at implementing sandboxing in Lux.
Due to the way the ecosystem is structured, rockspecs (instructions on how to build a Lua project) are themselves Lua files. This means that they can run unbounded and arbitrary code.
Amazing work :)
Video about Lazy Loading should be ready by the end of today 🔥🔥
oh this looks nice 👀
There may or may not be a new YouTube video coming out very soon 👀
github.com/neovim/neovi...
Dont mind me eagerly checking this PR daily hoping for some progress. The Neovim terminal could really do with some QoL for end users :)
Merry Christmas to all the real ones 🙏🔥
based chromium hater
Elixir's tooling is severely underrated for just how good it is 🙏
Thanks to generous donations from our OpenCollective supporters we've now moved Luanox to a dedicated domain (beta.luanox.org)!
For reasons to support us be sure to check out
beta.luanox.org/donate :D
We received reports of a phishing campaign targeting crates.io users. Do not click on links asking to authenticate to protect your account. More information: blog.rust-lang.org/2025/09/12/c...
Designing for mobile-first in frontend development is fun... Until you come across mobile devices that for some reason have a viewport width less than 365 pixels. In some cases, they completely break CSS and you have to deal with edge cases. Why don't companies make phones with a viewport standard?
With the growth of luarocks maybe we should start advocating for internationalization in larger Neovim plugins? I think it'd be quite amazing.
You could throw a lua lib like github.com/kikito/i18n.... in your project and make a more accessible plugin than ever before 🎉
if you're already on emacs then I personally wouldn't bother :)
I'll never stop yapping out the jujutsu VCS. It's such a good tool and has entirely replaced Git for me, tbh. Even for the most simple of operations I find jj to be much more ergonomic. You also get the op log for free! :D
I'd like to take a moment to appreciate FOSS. For all the craziness that goes on in communities every day the fact that we can all reap the benefits of freedom in both senses of the word is really remarkable. After using FOSS for several years I've really forgotten this simple fact.
I'm complaining that people should wait it out and let other developers write wrappers around vim.pack before starting to use it full-time. Let people integrate lazy-loading, auto-configuration and more. If they're going this far they might as well just use git clone/git pull while they're at it :p
Oh no, don't get me wrong, I don't think vim.pack should change. It's got a good minimal feature set as it is. But people have a tendency to flock to the latest thing and then complain that something's missing features, despite it being the core design of vim.pack
I get that wanting to make a minimal config is a tempting idea, I love myself some minimalism, but in the case of a git-based plugin manager you're only losing quality of life features without much in return. Hoping to see some cool wrapper plugins around vim.pack soon.
I personally find the #neovim 0.12 plugin manager to be severely overhyped. It's great to have a standard interface for more sophisticated wrappers to step in, but it's still very basic. Users will end up on a wrapper plugin anyway. The best thing vim.pack is good for is bootstrapping other code.
Github OAuth is amazing. In the oauth data, username is called "nickname", and the nickname is called "name". definitely did not cause any headaches :p
ask the neovim developers for keybind namespaces first :p
Starting work on native support in Lux for Luanox's API. It's so much more efficient than luarocks.org's, allowing you to do package search server-side, pull metadata about individual packages (instead of pulling a massive manifest file) and no weird stuttering or delays on the server. Excited!
