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.
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.
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?)
So like https://packagecloud.io/ ?
It hosts standard package repos which can internally do selection for distro/version/architecture.
It's just too much administrative overhead in the long run. I don't run just one machine. This is not laziness, it's a mode of operation.
Also, it's a red flag. If you can't get into official repos, what else is wrong with you? Perhaps nothing, perhaps those gatekeepers are gatekeeping too hard. Still, I'm not going to invest my resources to figure it out.
There are many good reasons for a piece of software not to be included in a default repository.
First of all, it’s about prioritizing maintainer workload.
It makes sense to draw the line somewhere in order to prevent the backlog from growing. A huge backlog is bad for everyone: it tends to burn out maintainers, causes important (security) updates to slip, and can be frustrating for users.
As a package maintenance team, what options do you have to draw a line? You may decide to narrow the scope somewhat arbitrarily (e. g. FOSS only, stable versions only, latest only), add some notability requirement (e. g. 50 or more GitHub stars), or streamline your process (e. g. exclude packages that would require downstream to write and maintain patches).
Anything of the above can cause a perfectly trustworthy package not to be included into a default/core repository, leaving 3rd-party repositories as a good enough option.
I think it’s super important to be extra vigilant when tapping into a 3rd-party repository. But it would be a little unfair to consider those packages (or their upstream projects) damaged goods.
Not saying you did imply the latter; I just felt like chiming in with my point of view.
A decentralized binary package manager
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.
$ curl -L git.io/getnami | bash && exec -l $SHELL
nami - A decentralized binary package manager
nami [global options] command [command options] [arguments...]
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
--help, -h show help (default: false)
$ nami install github.com/txthinking/nami
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`, `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)
Licensed under The GPLv3 License
$ curl -L git.io/getnami | bash && exec -l $SHELL
Alternately you could homebrew/apt-get some_package_ive_never_looked_at_the_source_of that'd be wicked safe.
> 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.
When you ask curl to download "git.io/getnami", first thing it does is to ask DNS server: "Hey, what IP does git.io refer to?" And DNS server will send you the IP address. MitM attack can happen at this point, and you will get fraudulent IP address. Usually you will get correct one. Then you connect to the IP address. MitM attack can happen here as well, you think you connected to server with the IP, but some node along the way is actually lying to you and you are in fact connecting somewhere else. At this point when using https, webserver to which you connected would prove to you that it is indeed "git.io" and your communication would become encrypted. Only after that would the webserver 301 redirected you somewhere else. But because you chose to not use https, user might have connected somewhere else and could have downloaded completely different, malicious file.
Next time you accuse other people of being ignorant and rude, make sure it's not you who is in the wrong.
See this in particular: https://news.ycombinator.com/showhn.html. It includes:
Be respectful. Anyone sharing work is making a contribution, however modest.
Ask questions out of curiosity. Don't cross-examine.
Instead of "you're doing it wrong", suggest alternatives. When someone is learning, help them learn more.
When something isn't good, you needn't pretend that it is. But don't be gratuitously negative.
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/in...
>/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/in....
Sorry, your first sentence still doesn't make much sense. If you are asking how is that better command than piping download into bash, it's pretty much same thing, but at least this one uses https.
>@Hitton Don't show your ignorance please.
Sorry, your first sentence doesn't make any sense. And why don't you try to explain what exactly I'm ignorant of, you surely don't suffer from such defects yourself, so it should be easy for you.