FastMail is using JMAP, a protocol designed to support push notifications. MXRoute is stuck with SMTP/IMAP which don't support those. There might be a different reason, but I think this is probably the core issue here
I think saying they are stuck with standard email protocols is a bit of a stretch. JMAP is not widely implemented outside of Fastmail and certainly isn’t used by Apple Mail, which actually uses a proprietary IMAP extension (XAPPLEPUSHSERVICE).
nixpkgs already has 107158 packaged libraries/executables. Nix has infrastructure to support arbitrary build systems and can create docker images. I fail to see any advantages of creating a more narrow version of it that has fewer uses and has to start from scratch
Both nix and guix are exciting projects with a lot of enviable security properties. Many here can attest that using them feels like, and perhaps is, the future. I see OSS Rebuild as serving more immediate needs.
By rebuilding packages from the registries people already use, we can bring some of those security properties to users without them needing to change the way they get their software.
Nixpkgs pulls source code from places like pypi and crates.io, so verifying the integrity of those packages does help the Nix ecosystem along with everyone else.
The Nix community has a poor record on security and supply-chain integrity in particular [1] whereas Google has a great record on security, and this announcement (of OSS Rebuild) was written by a member of the "Google Open Source Security Team".
[1]: "it means effectively a decision was made for NixOS to be a hobby distro not suitable for any targeted applications or individuals. It really sucks, because I love everything else about nix design. Instead I am forced to bootstrap high security applications using arch and debian toolchains which are worse than nix in every way but supply chain integrity given that all authors directly sign package sources with their personal well verified keys."
Since writing the post you link, I finally threw my hands up and made a new distro with some security engineer peers that prioritizes supply chain security and mandates 100% full source bootstrapping and determinism: https://stagex.tools
It does not even try to be a workstation distro so we can get away with a small number of packages, focusing on building software with high accountability.
Thankfully OCI build tooling is mature enough now that we can build using standards and do not need a custom build framework and custom languages like nix/guix does anymore.
They could've contributed SLSA attestations support to nix instead. There's a few people working on bringing SLSA build provenance to nix(pkgs) including me. But limited time and resources unfortunately. Would love to see Google contribute to nix in this space :)
> could've contributed SLSA attestations support to nix
That sounds like a great idea! However one important consideration is that while an artifact on nixpkgs may aim to replicate the function of the upstream package, it must adhere to and interoperate with the rest of the distribution. Ultimately, its 'ecosystem' is nix. Work that goes into writing and maintaining the nix build does not generally filter back upstream to impact the build integrity of, say, its associated PyPI package. So if users continue to consume from PyPI, improving nix won't serve them.
This is not to say that the long-term source of truth for packaging will remain the language registries. Just that today's reality demands we meet users where they are.
> Would love to see Google contribute to nix in this space :)
This is an issue with nixpkgs not nix. Google could've just bootstrapped their own nixpkgs from scratch if they wanted to, see Guix (not a perfect example but still). Creating a whole new tool is still completely unnecessary
One could argue that creating Nix from scratch would be beneficial at some point. There's a lot of legacy hardcoded weirdness, Nix doesn't setup the containers with standard state of the art tools, the language is evaluated in a single thread and using values from derivations means a build blocks evaluation so it doesn't properly parallelise (nixpkgs bans "IFD" but it is useful for meta packaging).
Nixpkgs is more valuable than Nix at this point, but also quite vulnerable. In practice it has worked out reasonably well so far, I don't know of anyone who got "owned" because of Nix.
> using values from derivations means a build blocks evaluation so it doesn't properly parallelise (nixpkgs bans "IFD" but it is useful for meta packaging).
Not anymore with the introduction of dynamic derivations (experimental)
Encouraging the use of Nix in production is wildly irresponsible. I am really surprised to see Google do this given their generally high security bar. Maybe this team operates in a bubble and gets to prioritize developer experience above all else.
Nix in production is more common than you think, even at scale.
It's hard to know what exactly your security concerns are here, but if you look at the current ecosystem of using containers and package registries, Nix is pretty clearly a solid contender, security-wise.
Plenty of wildly unsafe behavior is common in production infrastructure today. This is also why compromised corporate infrastructure is in the news so often. Few orgs hire or even contract security engineers with Linux supply chain and hardening experience, opting to blindly trust the popular options and their maintainers.
NixOS knowingly discards vital supply chain integrity controls to minimize developer friction and maximize package contributions. It is a highly complex Wikipedia style distribution optimizing for maximum package variety which is absolutely fine and great for hobby use cases, but use in security critical applications is absolutely irresponsible.
Guix goes some big steps further in supply chain integrity but still ultimately trusts individual maintainers.
Nix/NixOS files often break due to Nix pkg maintainers not caring about keeping support for existing configuration formats. I experience a breakage roughly every 2 weeks when a variable/package gets renamed or changed.
oss-rebuild is for independent verification, which cache.nixos.org doesn't have yet. I'm still waiting for https://github.com/nix-community/trustix to become a thing.
Until then they are still behind Debian and Arch Linux, which do in fact implement this with rebuilderd and debrebuild/archlinux-repro.
So, according to this definition, neither Mistral nor Facebook provide open-source models? Finally, they would need to stop calling their models open-source?
Yeah, for me too. It looks incredibly broken as of right now and I don't even understand how. I'd say that it's okay if it was an alpha of a completely new editor, but it's a fork of a one that already works well, so idk, I don't expect it to go anywhere
Hey, thanks a lot for the reply. I have just moved from go where there is (still a binary though), but an amazing debugger, offering great experience, with lldb on the other side not able to even expand a enum correctly
