$100 to a Debian Developer who can get Fresh Editor into Trixie | Hacker News Reader

$100 to a Debian Developer who can get Fresh Editor into Trixie

29 pointsjph14 comments

I use Debian 13 in a regulated industry and I'm teaching people how to code in the context of large projects and TUI.

I want to use Fresh Editor (https://getfresh.dev/). This is because Fresh is easier to learn quickly than vim & emacs, and more of an IDE than micro & nano, and more favorable for compliance auditing because of its core-and-plugins architecture and open source code using Rust.

I would like to donate toward this goal. I can afford to offer $100 to any Debian Developer who has the suitable skill and trust to accomplish this. The software author must say yes too, of course.

Success looks like this: create a new Debian 13 server, type "apt install fresh-editor", and it works. No third-party apt sources needed, because I have compliance reasons. Fortunately Fresh already has a *.deb file and explains it on the Fresh installation page.

Here's the GitHub issue: https://github.com/sinelaw/fresh/issues/2169

I'm not affiliated with Fresh in any way, just a early adopter user. If you view the GitHub issues, I'm also offering $100 each for helping with Fresh display issues on MacBooks, and for adding Fresh ePub capabilities.

I'm doing this because I believe in funding open source as much as possible.

Hello! I am a Debian Developer, though not likely to work on this as I haven't done a ton of rust binary packaging.

I did want to clear up one misconception that you might be having, though. The .deb versions shipped by upstream are great, but they're not really ever going to be useful for Debian. One of the side-effects of Debian's requirements around software freedom is an important principle: you should be able to build any package in Debian with only the things that are in Debian.

The problem with fresh isn't fresh itself -- packaging that isn't particularly difficult, though it does need some amount of care and attention. The problem is that fresh pulls in 732 different crates which all need to be packaged in Debian before fresh can be. Some of them are already in Debian, of course, but... you can imagine that the effort here is very much not insignificant.

Upstream doesn't have to deal with this problem, as they can simply statically build them into the executables. That's a violation of Debian policy, though, and isn't allowed for anything in the archive.

Hope that helps you understand why you may not get many bites at this offer, generous as it is!

Excellent info thank you. Your explanation makes perfect sense, and leads to the security compliance info that I'm reading.

I'm seeking to stop supply chain attacks as described at https://wiki.debian.org/Rust

Could there potentially be a way for a program to include all the source code of all its dependencies, at least for any that aren't on Debian?

The problem that Debian has with rust packages is that they try to apply handling a C-style dependency chain (usually only a few C libraries with large scope) for the rust crate ecosystem (a lot of dependencies with small scope). Having to maintain 732 just for one release of a new package is not sustainable.

I don't understand why the policy is not: pulling all crate sources and prepackaging into a tar with associated licenses. The source tree then is part of the package which can still be built from source and gets linked statically.

Security is part of it -- dpkg and apt were not built to deal with the problem of tracking each individual executables' complied library versions. When the next Heartbleed happens, how will you know which things need to be recompiled? (Some of this data exists in adjacent Debian systems for DD's internal use, but it's not integrated into dpkg in any way.)

https://wiki.debian.org/StaticLinking#downsides has some of the background there.

I think this is a fine description, and respect your reasoning! I think there is in this case, no conflict: Keep the OS-managed packages strict about dependency security, and let the user run the .deb or compiled program Fresh (or whatever software) has provided. So, I think your (Debian perspective), and Fresh (Providing binaries for download, including as a multi-linux script) is on the simpler/easier/just-works end of installing software. No conflicts. Single-CLI line install either way.

(Fresh maintainer here)

Fresh itself has a few dozen direct dependencies. About 33 of those already exist on Debian. It boils down to these missing dependencies:

- The entire oxc toolchain — oxc_allocator, oxc_ast, oxc_codegen, oxc_diagnostics, oxc_isolated_declarations, oxc_parser, oxc_semantic, oxc_span, oxc_transformer

- rquickjs, rquickjs-serde (the QuickJS plugin engine)

- ts-rs

- jsonc-parser

- rust-i18n (this one has an open ITP)

If we build Fresh without plugins enabled, it's just the last three.

This isn't going to happen.

Debian Trixie has already been released. The packages going into Trixie were frozen on April 25, 2025. If you want a new package in the official Debian repos, it needs to be packaged for Unstable, then promoted to Testing, then eventually Testing will be cut as a Stable release. The next Testing freeze will probably be sometime next year.

Good info, thank you. I'll aim for the next version with $100 to get it into Debian 14. <3

Out of the loop: Why not run this, from the top of the home page: curl https://raw.githubusercontent.com/sinelaw/fresh/refs/heads/m... | sh

IMO this isn't part of your OS; it's cross-platform PC software. Install it using the bin its creators have provided. They have even built and are hosting a Deb for your linux distro (From inspection of the script)

I see in your posts that you do a lot with Rust and biology. Broadly, the same way you can use the tool "cargo install" to fetch a bunch of dependency crates from one source and be sure their versions can all run well together and update together, I can use the tool "apt install" to do the same for applications.

The concept is called a "package manager" and it greatly helps me achieve a concept called "reproducible builds", as I gradually migrate the work toward a package manager for reproducible builds called "Nix".

https://en.wikipedia.org/wiki/Package_manager

https://en.wikipedia.org/wiki/Reproducible_builds

https://en.wikipedia.org/wiki/Nix_(package_manager)

That is some attention to detail in your research! I appreciate the explanation and examples. I think perhaps I am deliberately dodging the OP's question, treating it as an X/Y problem. He or she mentioned compliance as a valid reason, but it still feels like a smell: I think the original software could be installed using the provided deb, or building from source by cloning the repo and running `cargo run` on a Debian or Ubuntu system older than or the same version as the one he intends to use. (A Rule of Thumb I've found works well for Debian!)

I recognize that a lot of Linux users like the package system. I think it's a great tool for software that's intended to be integrated with the OS, but is a bit of a mismatch for third-party software. The creators here have even build a .deb, which is above and beyond. (Compared to, for exmple, compiling a +x linux executable that has been tested on Debian)

So, from a writer and user of software, I think I would rather publish the executables or a script to install them on my website (as they have done) for all the major OS branches, and as a user, I think c+ping and launching the CLI command they provided front and center is fantastic. It's an above-avg experience; a trivial install process, which isn't a given for OSS.

This feels like a good example of open source economics.A relatively small amount of money can create value for everyone who used Debian in the future.

thank you for creating gitalias, very useful!

You're welcome, thanks for the shout out. Glad it's helping you. <3

Reply on news.ycombinator.com