argos-translate VS infrastructure

Interestingly, I think this is actually related to the offline translation features built into Firefox. Both are products of "Project Bergamot", but the Mozilla-maintained version was later merged into the Firefox application:

https://browser.mt/

https://blog.mozilla.org/en/mozilla/local-translation-add-on...

https://hacks.mozilla.org/2022/06/training-efficient-neural-...

https://github.com/mozilla/firefox-translations

https://firefox-source-docs.mozilla.org/toolkit/components/t...

Extra webpage with screenshot and links, impossible to search for normally:

https://translatelocally.com/downloads/

Does one thing and does it well.

Oh— For downloading models, it's much easier to pipe/`xargs` `translateLocally --available-models` into `translateLocally -d` than go through the GUI.

---

Other self-hostable translation tools:

https://www.apertium.org/index.eng.html

- Traditional rule-based translation. Seems to work pretty well, but no good desktop frontend.

https://www.argosopentech.com/

- Works, but crashy desktop app.

https://libretranslate.com/

- API wrapping Argos Translate.

https://lingva.thedaviddelta.com/

- Google Translate scraper/privacy frontend.

https://euroglot.com/

- Proprietary, subscription trialware.

Consider a free software alternative to this translation service, such as Argos Translate or its web based frontend LibreTranslate.

LibreTranslate (which uses Argos Translate) from my understanding, but I don't think it can be used to translate entire websites

This looks pretty legit but I haven't tried it: https://github.com/argosopentech/argos-translate

Google translate is both censored and intentionally flawed. Here is a better option: https://github.com/argosopentech/argos-translate

Argos Translate can do everything that LibreTranslate can do on your desktop without uploading translated text to the Internet.

Argos Translate has open source neural machine translation https://github.com/argosopentech/argos-translate

I'm trying to upload a Mac app to the App Store and need to take screenshots at 1280x800, 1440x900, 2560x1600, or 2880x1800 resolutions. I'm developing on a Mac Mini connected to a HDMI display and I'm unable to run at any of the required resolutions. I'm currently trying to take the screenshots through VNC using the Mac Mini in headless mode. I have the VNC server running (System Preferences > Sharing > Remote Management) haven't been able to set the resolution. How do you set the resolution when running a Mac in headless mode over VNC?

Nix doesn’t guarantee binary reproducibility. It does help with reproducing build inputs and the build process, as do the tools used to create Flatpak applications and runtimes—flatpak-builder and BuildStream. Nix can build packages in a sandbox, but the same is true of flatpak-builder and BuildStream.

The Freedesktop SDK has a CI pipeline (run on schedule, not on every change, because it is expensive) that tests reproducibility, similar to r13y.com. Currently everything is reproducible except a few components.

There are also many respects in which Flatpak is objectively better than Nix (other than sandboxing, which is an important one). For example, Flatpak guarantees atomic updates with restarting merely the updated application. NixOS only guarantees atomic updates with a reboot (`nixos-rebuild boot`); `nixos-rebuild switch` can still break your running system, though the Nix store is safe and problems will not persist after a reboot, which is still a huge improvement over traditional package management. Still, using containers allows giving stronger guarantees.

Another example is that flatpak-builder and BuildStream are substantially faster than Nix. Evaluating Nix expressions is quite inefficient, even if they are convenient to write. Worse is the cascading rebuilds that come with the Nix approach when dependencies like compilers and glibc are patched or updated. Rebuilding after significant updates to gcc and glibc has advantages, such as benefitting from newer compiler features, but it is very desirable to have the option not to do that.

Also, Nix’s languages lacks domain abstractions for building packages, which makes tools to generate and update derivations have to rely on assumptions about their format or be unnecessarily complex. In comparison, flatpak-builder and BuildStream use JSON and YAML. The result is less expressive but more convenient, consistent, efficient, and simple to manipulate.

Similar to nixpkgs-update, Freedesktop SDK uses a simple auto-updater[1] for BuildStream and Flathub apps can use the Flatpak External Data Checker[2] for a bot to open merge requests or pull requests to update dependencies in the runtime and in application manifests.

OSTree uses a content-addressable store for all files, giving Flatpak deduplication for free. Nix gets deduplication only with an expensive process (`nix store optimise`) that involves scanning the Nix store and replacing duplicated files by hard links.

Yet another advantage of Flatpak is that due to dependencies being “flat”—that is, apps can depend on runtimes and have extensions, but there are no complex dependency trees—there is no need for dependency resolution. This also reduces the amount of metadata that needs to be downloaded. This makes installing and updating software with Flatpak very fast, which is unfortunately not at all true with Nix.

So, there are tradeoffs, and overall Flatpak has the better of them. Employing Nix to manage dependencies or to build apps would cause Flatpak to lose many of its advantages.

[1]: https://gitlab.com/BuildStream/infrastructure/gitlab-merge-r...

[2]: https://github.com/flathub/flatpak-external-data-checker