_sinelaw_

6 ms·

1.
by _sinelaw_ 1mo ago
You still need the distro maintainers to cooperate. And the packaging itself can be highly involved (as in the case of rust dependencies on Debian)
2.
by _sinelaw_ 1mo ago
Exactly. It's ironic that the end result is "windows is easier". Ugh.
3.
by _sinelaw_ 1mo ago
Still need to handle automatic upgrades. That's my plan. I was wondering if there's a better way...
4.
by _sinelaw_ 1mo ago
Flathub (not sure if these are the same people behind Flatpak) makes it clear they don't welcome these types of submissions: https://docs.flathub.org/docs/for-app-authors/requirements
5.
by _sinelaw_ 1mo ago
If I don't make my program easy to install, many people won't even try it. Being responsive to maintainers doesn't help if maintainers never reach out or even actively refuse to package your software.
6.
by _sinelaw_ 1mo ago
It's a problem for my potential users. I don't get this "it's not your job to distribute your own software".
7.
by _sinelaw_ 1mo ago
Sure, I already do offer deb/rpm via GitHub release page. My problem is ensuring users have an easy way to update
8.
by _sinelaw_ 1mo ago
I do publish deb files in the GitHub release page. Will take a look at aptly / reprepo
9.
by _sinelaw_ 1mo ago
"Someone else's job" doesn't help getting the software into my user's hands. I need a solution that works for my users regardless.
10.
by _sinelaw_ 1mo ago
cargo install (the equivalent command here) is available. Downsides: - very slow - need to install prerequisites - not possible on many machines (to weak, not enough disk for running builds) Many users don't want to deal with this
11.
by _sinelaw_ 1mo ago
Hi, I'm the author of this post (and of Fresh). I've spent a lot of time getting it distributed cleanly to Linux users of all distros, and it's an uphill battle. I'm curious how other solo maintainers are dealing with th
12.
I hate packaging my software for Linux(getfresh.dev)
101 points by _sinelaw_ 1mo ago|150 comments
13.
by _sinelaw_ 4mo ago
(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_diagnost
14.
by _sinelaw_ 7mo ago
The harder problem is conflicting design choices, or duplicating similar infra. It means I need to be much more involved in steering individual agents and planning up front (waterfall style), which limits the parallelism further
15.
by _sinelaw_ 7mo ago
I did when just starting on a new project, it was working well when I had many new components to implement. But as the project matured and stabilized every new feature is cross-cutting and it's impossible to parallelize the work withou
16.
by _sinelaw_ 8mo ago
It even runs Fresh so you can have a mini VSCode-like experience on your phone (pkg update && pkg install fresh-editor)
17.
by _sinelaw_ 8mo ago
Let me know if you still have issues, I'll look into it
18.
by _sinelaw_ 8mo ago
Is this 'task' feature really useful? I'd say applications like IDEs and text editors should not have automatic arbitrary execution of code in the first place. 'eval' should be blocked and extensions/plugins sh
19.
by _sinelaw_ 8mo ago
For Claude, it's enough to prompt "use tmux to test", that usually does the work out of the box. If colors are important I also add "use -e option with capture-pane to see colors". It just works. I used it regularly
20.
by _sinelaw_ 8mo ago
I'm also a long time emacs user (>15 years) but got tired of the endless config fiddling, with some packages breaking over emacs versions, other packages which were cool at the time slowly getting stale and need to switch to yet ano
21.
by _sinelaw_ 8mo ago
What specifically are you missing from Zed? (not a Zed user but curious to know)
22.
by _sinelaw_ 8mo ago
I also got tired of the bloat and also prefer working from the terminal. I'm building Fresh [0] [1] as an alternative to VSCode that runs in your terminal, with the main goal being ease-of-use out of the box (not a vi-clone modal edito
23.
by _sinelaw_ 9mo ago
For a long time I watched TypeScript take over the JavaScript ecosystem as a reasonable way to add structure and safety. But even before TypeScript existed I was thinking about how to approach this differently, ripping out the "bad par
24.
Show HN: minfern – Type inference for JavaScript without transpilation(github.com)
2 points by _sinelaw_ 9mo ago|1 comments
25.
by _sinelaw_ 9mo ago
Added GPM support, try latest master or release >= 0.1.25 (rolling out now)
26.
by _sinelaw_ 9mo ago
Did you try "use option as meta key"? https://superuser.com/questions/1038947/using-the-option-key...
27.
by _sinelaw_ 9mo ago
Done, you can pass now file, or file:line, or file:line:column in the cli
28.
by _sinelaw_ 9mo ago
zed: ~20 seconds to open the file, 4.7gb RAM no ansi color rendering
29.
by _sinelaw_ 10mo ago
I took the feedback and now you can install binaries in any of these methods: - Homebrew (MacOS) - Arch Linux AUR - Debian/Ubuntu .deb - Fedora/RHEL .rpm as well as cargo install (which builds from source), npm, npx or building fr
30.
by _sinelaw_ 10mo ago
It does and it boils down to deno (typescript plugin support) I hate it, and I'll keep working on reducing it

More ›