I consider that your (excellent) fuse fs approach with a remote store should graduate into standard nix tooling, so that it can be used whenever a server agrees to provide enough bandwidth to serve the users’ filesystem on demand (like in controlled environments).
This might yield the broader nix a real competitive edge as a thought model on binary distribution strategies (in combination with upcoming trustix).
Note that the k8s explores a similar approach for image path loading.
I hope you won’t be tempted to declare it competitive USP for flox for too long. It might be too groundbreaking to promote the greater good out-of-tree on the long term.
At least, there might arise a risk of a technical split brain when the ecosystem eventually tries to reimplement this. I wish you all the best luck to lead the (community’s) way in that regard!
Glad you like the FUSE approach! It works really well for us because it gives us access to the entirety of Nix store anywhere (including edge devices) and simultaneously on thousands of machines without trying to predict what each machine might need or actively manage local caches.
We’d love to work with the Nix community to graduate some of our work to standard tooling or otherwise API-ify and document it in a way that makes it more accessible without plugging into the entire flox ecosystem (that can be a lot to ask). A lot of users are requesting we open source various components of the stack (and we could use some help!), so this is top of mind for us right now.
I just wanted to say thank you briefly to the community for the warm welcome we’ve received so far and share a few things we’re working on to make flox better for you!
We’ve had more than 160 people sign up for the beta, 80 join our Discourse, and a dozen join our Slack. You guys have also shared a lot of ideas for making flox better that we’re working on now:
The ability to download the full contents of a profile, so you can take it on the go (This is out now under floxpm download)
A watcher to see the progress of your lazy downloads, so you know why your commands are hanging
Support for installing flox on NixOS configured with flakes
A more intuitive dialogue for initializing Nix expressions (flox init)
A MacOS client
Loads of minor bug fixes
A few people had problems logging in (because github is case insensitive but we/Nix aren’t!) that we’ve sorted out now. And @grahamc has been hard at work making Hydra more efficient for us and the Nix community.
We’ve also had many people request we open source parts (or all) of flox, and we’re trying to figure out the best way to do this. It’s slow going (thanks to lawyers), so thanks for your patience.
Just got around to watch the Nix Friday episode on Flox, and I liked the remark on how Flox compares to Nix community innovations (flakes, in this case), and putting it into the context of intra- (Flox) vs inter-organizational (flakes) collaboration.
The future of Flox is uncertain (business model, open sourcing, etc.) but it is easy to see how it would help organizations to set up a uniform developer experience and environment; yes, one could set up a Hydra build-farm, create internal workflow instructions on how to use Nix, but that’s an overhead that is discouraging and can also be a huge barriers to adopting Nix. For instance, I work for a small non-profit whose leaders boldly decided to develop some software projects in-house, and everyone can tell that the actual dev work in such a setting is only a small percentage compared to operations, compliance, security, etc. matters. Flox would only alleviate a moderate part of the situation, but it would still be a big win, both in the short and in the long term.
I would realy love to see an update on things “all Flox”.
Could there perhaps be a follow up online meeting to discuss more about the Flox inners and the way it has been working for others? Or explaining more how using Flox will/would benefit companies willing to dive into using Nix?
Hi @JosW !
Quick intro as this is one of my first messages here! I just joined Flox as CEO after leading developer products at Facebook.
In brief, we are diving deep into how Flox can both contribute to the Nix ecosystem and drive more enterprises, teams and engineers to Nix. It’s a tough nut to crack and we strongly believe that doing so would put Nix at the top tier of the development vocabulary. I would love to hear your thoughts and set up some time to talk about the topics you raised here. We can even turn this into a small roundtable with anyone else that might be interested if you are up to it.
Frankly, this concerns me. “Drive more people to Nix” sounds great on the surface of it, but will they actually be driven to Nix, or specifically to flox as an indispensable usability layer over it?
With there being no clear commitment to open-source and community engagement that I can see (in this thread anyway, please correct me if I’m wrong!), I’m concerned that this would siphon momentum from the Nix project itself (and more importantly, the drive to improve it), in favour of what is essentially a proprietary, commercial product.
Shouldn’t improved usability ultimately be something that’s a part of Nix itself, instead?
Thanks for your comment @joepie91 ! There’s been a lot of changes on our side, (including making Flox its own company), so we may have lost some stuff in translation. I’m also still learning because I just started a couple weeks ago.Let me be very clear about a few things:
Flox is committed to open source. Everyone at our company is a developer. We understand the importance of free software. We will open source or commit code upstream whenever it makes sense. If anything remains closed source at all, it will only be functionality that specifically matters to teams and enterprises (think analytics, security enhancements, compliance, logins. etc…) or services that run on our machines. I promise more of the code in the beta will be open sourced when we can get around to it, and I’ll set a proper policy in the future.
Flox is committed to making technical contributions to the Nix ecosystem. We have already made many direct contributions to Nix, Hydra, and Nixpkgs. We have many more on our roadmap. We’re also drafting our first official RFC now! If we just wanted to be a usability layer, we would keep that stuff to ourselves.
Flox is committed to supporting the Nix community.@tomberek spends some of his time at work serving as a NixOS release manager, holding Nix office hours for the community, and helping the marketing committee figure out how to drive more folks to Nix directly . This kind of work is literally in the job description because we believe Flox wins when Nix wins.
If we pull it off, there will be more jobs for Nix users, more donations in support of Nix projects, and more contributors in the ecosystem.I’m excited to dig in on the details of all of this in the coming months, and I’d welcome a round table. Please reach out to me at ron@floxdev.com if you want to chat.
Update: launching the all-new flox beta!
For those that have been involved - thank you so much for your help. We have reinvented the system from the ground up based on your feedback. To those who have been on the waiting list, expect to soon receive an email with directions as access is extended on how to download and use the beta. And for those who just want to see what it’s all about, we are still accepting sign-ups at: https://floxdev.com
We remain focused on providing a simple, intuitive way to use Nix while giving you the tools to help you bring Nix to Work. The updated beta adds support for individual use while still offering powerful features for collaboration and control in corporate environments. Whether you use it for work, in a team or as an individual, we’d love for you to try it out and hear what you think!
That is indeed the older documentation, much has been upgraded/added/changed/completely redone in this latest release!
The latest docs are currently available for the beta groups and we plan to release them openly very soon.
Feel free to ping me directly if you want early access!
The landing page is looking really nice, just a small feedback: the carousel in the second section is moving too fast, it moves from ‘Seamless’ to ‘Intuitive’ before the GIF is finished making it impossible to see the results of the command
Regarding the website landing page, positioning the mouse cursor within the terminal window should stop the carousel from switching, and the terminal display is not a gif but rather an asciinema player which has the advantage that you can pause, drag the slider to the desired point in the playback, and copy text from within the terminal window. If any of that doesn’t work for you I’d love to hear back with details of what browser you’re using so we can investigate what’s going wrong there. Many thanks!
I’m probably a weird use case, but I’m using qutebrowser to navigate with keyboard element hints. I don’t even have a mouse plugged on my PC , but thanks for considering my comment.
So if you install flox inside a ci/cd VM, there’s no step 2, everything is “already there”? Very cool!
Also, since you own the storage layer via FUSE, you can deduplicate blocks. Since many binaries only differ by included store paths, you could first split binaries into zeroed-store-path blobs + a list of locations of store paths. If you then use a rolling checksum deduplication, you can probably get a high reuse factor. On the client side, you should combine the binaries again with the store path list. This can be done on the fly inside the FUSE handler.
So that way, you’ll decrease storage and traffic on both sides, at a mild complexity cost.
Since many binaries only differ by included store paths, you could first split binaries into zeroed-store-path blobs + a list of locations of store paths.
It might be too groundbreaking to promote the greater good out-of-tree on the long term.
, but thanks for considering my comment.