
Show HN: Nami – A decentralized binary package manager - txthinking
https://github.com/txthinking/nami
======
Hackbraten
Why do people assume package managers do some form of gatekeeping?

It’s not the package managers who gatekeep, it’s their associated repository.
People are free to create and host their own repositories (or, in Homebrew-
speak, taps). Users are free to add those with no PRs involved whatsoever.

~~~
txthinking
1\. It's for __pre-built binary __, different OS /Arch need different binary
file. So nami needs to know download which file for user's OS.

2\. Yes, people are free to create brew taps. But you know humans are divided
into 'I will do this' and 'I wont do this'

3\. There are there roles: [software developer], [package maintainer], [user].

3\. Most cases, [the software developer] is not the [package maintainer]. The
software developer only push code, test code , build code. Like we know,
__build binary is a step of the software developer __, but they don 't like to
create much more packages with apt-get/brew/pacman/etc, so many packages in
the centralized PM are outdate. Examples are endless.

4\. [User] is people who using software, they like less concepts thing. They
just a user, not developer, not maintainer.

~~~
Hackbraten
> 2\. Yes, people are free to create brew taps. But you know humans are
> divided into 'I will do this' and 'I wont do this'

The point I was trying to make was: as a 3rd-party package maintainer, why
would I look into nami (rather than upload my package to a 3rd-party
repository so users are free to use the package manager they already know?)

------
djhaskin987
So sort of the same idea as docker where the address of a package (docker
image) is built into its name. Interesting but also problematic. If a package
in rhel repo is broken I can mask it with one I've built of the same name in
my company repo. Since the package address isn't tied to its name, this works.

~~~
txthinking
If a package broken, you can built of the same name in your company repo too,
the address is yours, but the package is same package.

------
jyrkesh
Looks really awesome for internal usage, but public binary distribution
without _some_ form of gatekeeping is spooky.

~~~
txthinking
Yes, actually you don't do install package you don't trust. And actually even
the package is code not binary, the users don't see code always. The result is
user install package because they trust the author of package.

~~~
sagichmal
This is not good enough security position for a package manager.

~~~
txthinking
Yes, it is like Android APK vs iOS app store :)

------
pipework
Besides features, how does this compare in daily workflow to [https://asdf-
vm.com/](https://asdf-vm.com/)? Does it provide version management or just
upgrade to latest?

------
jrruethe
Am I missing something? How does this handle different package types for the
same OS/Arch? Like, if I wanted to host a _.deb,_.rpm, *.appimage, etc?

------
txthinking
# Nami

A decentralized binary package manager

### Why

There are already many package managers, like apt-get, brew, but this is all
centralized. Every time the author updates the software, they need to write
complex configuration files and PRs and wait for merge.

Nami is a decentralized binary package manager, she allows software authors to
publish their software anywhere, without having to request a merge from a
software center for each update.

### Install

    
    
        $ curl -L git.io/getnami | bash && exec -l $SHELL
    

### Usage

    
    
        NAME:
           nami - A decentralized binary package manager
    
        USAGE:
           nami [global options] command [command options] [arguments...]
    
        COMMANDS:
           install  Install package. $ nami install github.com/txthinking/nami
           upgrade  Upgrade package. $ nami upgrade github.com/txthinking/nami
           remove   Remove package. $ nami remove github.com/txthinking/nami
           info     Print package information. $ nami info github.com/txthinking/nami
           list     Print installed packages. $ nami list
           help, h  Shows a list of commands or help for one command
    
        GLOBAL OPTIONS:
           --help, -h  show help (default: false)
    

### Example

    
    
        $ nami install github.com/txthinking/nami
    

### What Does Nami Do?

All files are stored in `~/.nami`

## Nami for Software Publisher

\- Package name such as `yourdomain.com/package` \- Nami will send GET request
to
`[https://yourdomain.com/package/nami.json`](https://yourdomain.com/package/nami.json`),
`nami.json`

### Built-in supported domains

* `github.com`: Package name such as `github.com/txthinking/nami`, put binary files in the [github releases]([https://github.com/txthinking/nami/releases](https://github.com/txthinking/nami/releases))

## License

Licensed under The GPLv3 License

------
Hitton

      $ curl -L git.io/getnami | bash && exec -l $SHELL
    

When will this crap end? I can't understand how can people still do that.
Everyone knows it's dangerous to pipe random scripts to bash, especially from
unsecured websites, and people still suggest it as recommended way to install
software...

~~~
masukomi
You're right. It's far safer to just download and run a binary you can't
inspect than to execute a bash script you can inspect. Doubly so if there's a
hash to guarantee the script/binary you downloaded is the one they intended.
That means there aren't any nefarious things in it. ️

Alternately you could homebrew/apt-get
some_package_ive_never_looked_at_the_source_of that'd be wicked safe.

</sarcasm>

~~~
Hitton
Very droll indeed. I don't use homebrew so I don't know how is it managed, but
I have generally believe Debian maintainers to be more credible than random
github user. When I see install instructions like these I always at least skim
the instal script before running it. And of course Debian packages are signed
unlike downloading script from unsecured website like in this case where you
risk MitM attack.

~~~
ManWith2Plans
From the documentation:

> Nami is a decentralized binary package manager, she allows software authors
> to publish their software anywhere, without having to request a merge from a
> software center for each update.

If you're trying to install a decentralized binary package manager which
doesn't require maintainers to merge anything, you're presumably planning on
taking far greater risks than curling this installer.

