Main
rust-opendingux-test
Our great sponsors
Main | rust-opendingux-test | |
---|---|---|
10 | 1 | |
1,516 | 6 | |
16.4% | - | |
10.0 | 1.5 | |
1 day ago | 11 months ago | |
PowerShell | Rust | |
The Unlicense | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Main
- SumatraPDF Reader
-
My CNCF LFX Mentorship Spring 2023 Project at Kubescape
(merged) ScoopInstaller/Main #4757 kubescape: Update url and binary naming
- I built a cross-platform GUI management tool for LiteDB using AvaloniaUI
- Stupid Fast Scoop Search v1.0
- The scoop on Windows running Perl
-
In support of single binary executable packages
As I see it, part of the drive behind tools like Scoop is to overcome the limitations of the binary-shipping strategy common to Windows developers. They are successful at this, I agree, but only partially successful. They come from the tradition of programs like Ninite, which were explicitly built as ways to make the binary approach suck less than it did before.
I see the success of these programs as essentially stemming from the insertion of user interests in the form of a maintainer-like process. Sure, they're still working with the binaries, but the actual process of installing and managing these binaries is controlled by users, for users: https://github.com/ScoopInstaller/Main/tree/master/bucket
This means that you get moderation and in many cases modification to the behavior of the program. In a freeware environment like Windows that's full of shitware, at the very least you can in many cases strip out the ads. That's absolutely not nothing, but at the end of the day it comes from a group of user-maintainers stepping up and saying to developers that no, you cannot simply do whatever you want on my system with your software. That's ... sort of the whole point of a software distribution, in the Linux world!
When I want the latest version of a CLI tool on Linux, I simply `pacman -S package`. That's it; one command. I don't see how it could be any simpler or better than that, and on top of that I'm getting the benefits of moderation and integration with the rest of my system. Perhaps you are emphasizing latest version here, and hinting that you don't get that on Linux distros? That depends entirely on the distro; a software distribution is (roughly) a collection of user interests. An Arch user wants (and gets) the latest versions of all upstream software. A Debian user does not want this or see constant updating to the latest version as an advantage, so that's not what they get.
-
AVR GCC Toolchain - Setup for Windows
Here is the definition: https://github.com/ScoopInstaller/Main/blob/master/bucket/avr-gcc.json
-
WinGet is terrible. I want AppGet back
Those are all automated by the auto-update script.
Check Merged PRs https://github.com/ScoopInstaller/Main/pulls?q=is%3Apr+sort%... and you will see that the last non-bot one was merged 17 days ago.
rust-opendingux-test
-
In support of single binary executable packages
> By cross-compiling one usually understands compiling for the same OS but different architecture.
I don't even consider that to rise to the level of "cross compiling".
Getting started with emscripten to target WASM for C and C++ is rather a chore of dependency wrangling IME. Targeting WASM from Rust, OTOH, is trivial. Targeting windows from linux with Rust is also quite straightforward, as has been experimenting with targeting consoles or Android from Windows.
Targeting a MIPS32 OpenDingux target from Windows was much more of a chore. The toolchain with libs, headers, etc. that I used is just a *.tar.bz2 that expects to be extracted to /opt/gcw0-toolchain of a linux distro specifically, and embedded absolute paths all over the place make changing that difficult. I do resort to WSL on Windows, basically only because of those embedded paths: https://github.com/MaulingMonkey/rust-opendingux-test
Acquiring the appropriate libs and headers to link/compile against for cross compiling is always an adventure, but Rust isn't making things any worse IME.
What are some alternatives?
DalamudPlugins - This repository hosts plugins for XIVLauncher/Dalamud
z-run - z-run -- scripting library lightweight Go-based tool
Shovel-Ash258 - Personal Shovel bucket with a wide variety of applications of all kinds.
pkg - Package your Node.js project into an executable
wix3 - WiX Toolset v3.x
Scoop - A command-line installer for Windows.
Scoop-Core - Shovel. Alternative, more advanced, and user-friendly implementation of windows command-line installer scoop.
winget-cli - WinGet is the Windows Package Manager. This project includes a CLI (Command Line Interface), PowerShell modules, and a COM (Component Object Model) API (Application Programming Interface).
warp - Create self-contained single binary applications
oneget - PackageManagement (aka OneGet) is a package manager for Windows
Versions - 📦 A Scoop bucket for alternative versions of apps.
sdk - Core functionality needed to create .NET Core projects, that is shared between Visual Studio and CLI