Homebrew vs Fink vs Macports? [fechadas]


37

Estou usando o Fink para instalar aplicativos Unix no meu mac, encontrei o Homebrew e vi algumas boas críticas sobre o Homebrew.

Então, minha pergunta é:

  1. Que gerenciador de pacotes vocês usam para Mac?
  2. Eu uso o Fink atualmente, então a mudança de Fink para Homebrew realmente valerá a pena?
  3. Se 2. for verdadeiro, por que?

Eu mudei do Fink para o Homebrew, a melhor coisa sobre o homebrew é que você pode instalá-lo em qualquer lugar, portanto não é necessário nenhum sudo. O que eu pessoalmente não prefiro. Alguma sugestão sobre macports?
Zengr 02/07/10

Depois de usar o brew, sinto que existem poucos pacotes que não estão lá. como "meld" é no macports, mas não no brew.
Zengr

meld agora é oferecido em fermentação
Antony

Respostas:


7

Eu uso o Fink e o Macports. Ambos funcionam como um encanto.

Mas eu recomendo o Homebrew a usuários não tão experientes que estão apenas migrando do Windows, devido à sua aparente simplicidade.


3
Outro voto para Homebrew. Finalmente, um gerenciador de pacotes que não deseja instalar um sistema operacional totalmente novo.
Paul Robinson

11
Como a simplicidade pode ir contra o Homebrew para usuários experientes? Eu nunca usei Fink, mas Macports é acéfalo, mesmo para iniciantes
Antony

é 2016 e, por volta de 2010, parei de usar o fink, porque parou de funcionar para mim. Comecei a usar macports, e ainda funciona muito bem. Nunca tentei homebrew, por causa de sua tendência a fazer coisas estranhas e não unix (filosoficamente) wrt sudo e / usr / local (em resumo: a instalação de pacotes deve exigir o sudo e não deve usar / usr / local), e o macports pode funciona melhor para meus macs mais antigos. Até agora, o meu mac funciona exatamente como o meu shell linux, graças ao macports, que é o objetivo.
6136 Michael

18

IMHO, o problema com o Homebrew é que ele tenta usar / usr / local de uma maneira que nunca deveria ser usada: de propriedade de um usuário que não seja root. Embora eu entenda que os desenvolvedores do homebrew cuidam de não mexer com mais nada em / usr / local, nada mais que seja instalado em / usr / local fará o mesmo com o Homebrew. Isso pode causar problemas e tem para mim ... geralmente problemas de permissões resultantes da instalação de outro software que define permissões em / usr / local / com base em "como devem ser". Você nunca verá outro pacote de software esperando / usr / local / pertencer a um único usuário que não seja root, então por que Homebrew? Por que não usar apenas ~/bin?

Além disso, um fato pouco conhecido sobre por que o Fink & MacPorts compila suas próprias bibliotecas :

Existem várias razões pelas quais o MacPorts usa suas próprias bibliotecas. Torna as portas mais consistentes nas diferentes versões do Mac OS X. Por exemplo, se podemos confiar no openssl 1.0.0 do MacPorts, não precisamos testar todas as portas que precisam de SSL para todas as instalações de openssl disponíveis. O software da Apple tende a quebrar de tempos em tempos (por exemplo, o openssl se recusa a criar com um zlib antigo, mas por um tempo a Apple envia os cabeçalhos antigos da versão vulnerável do zlib). Mesmo que as versões da Apple não sejam quebradas, elas raramente estão atualizadas. A Apple tem o hábito de não atualizar as bibliotecas no Mac OS X até que seja absolutamente necessário por uma vulnerabilidade de segurança.

As desvantagens dessa política são mínimas: desperdiçar alguns megabytes para, por exemplo, uma instalação em Python é quase nada se você tiver um disco rígido com vários gigabytes, e o tempo necessário para construir as portas adicionais diminui à medida que os computadores ficam mais rápidos.

Portanto, embora o Homebrew seja mais rápido para instalar o que você deseja, ele pode ter outros efeitos colaterais ruins ao usar bibliotecas de sistemas Apple pré-criadas.

Novamente, eu odeio cavar contra Homebrew. Eu gosto do software e acho ótimo para algumas coisas, mas tem suas quedas como atualmente.


Basta executá-lo como root se as permissões foram alteradas? Isso aconteceu para mim, há uma mensagem de erro e eu sudoed. Qual é o problema?
Daniel Beck

O problema está de acordo com eles, não é assim que deve ser feito. O "caminho recomendado" não está certo.
churnd

Eles fazem um argumento convincente contra o sudouso excessivo . Apenas falha quando você começa a instalar seus próprios programas no mesmo prefixo. A maioria dos softwares pode suportar a instalação em outro lugar, talvez você tenha feito errado? Fink e Macports acabou de criar sua própria hierarquia de diretório para contornar este problema ...
Daniel Beck

8
Não, eu não fiz errado. A prática de ter / usr / local de propriedade de um usuário comum está errada. Você nunca verá isso com nenhum outro software baseado em * nix. Todos os outros pacotes de software que eu vi respeitam a propriedade root: wheel de / usr / local. Por que assumir / usr / local? Por que não usar / opt / homebrew e vincular as coisas a / usr / local / bin ou / usr / local / lib se você precisar (embora com o sudo)? Dê ao usuário a opção, mas não quebre as coisas se quiser manter as coisas separadas. Configure seu ambiente de acordo com sua escolha. Tudo coexiste pacificamente. Vantajoso para as duas partes.
churnd 27/12/11

Estou ciente disso, obrigado. Apenas use um prefixo diferente. A última vez que verifiquei, o prefixo era personalizável. Os padrões são para o que eles consideram um usuário médio. Para mais de 90% dos usuários, é bom o suficiente, pois eles não compilam e instalam seu próprio software /usr/local. Eles também não têm várias contas de usuário; portanto, a propriedade não é um problema lá e, na verdade, melhora toda a experiência.
Daniel Beck

15

Prefiro o homebrew devido à sua simplicidade / velocidade - minhas ferramentas parecem estar sendo atualizadas rapidamente no momento.

É a ferramenta de gerenciamento de pacotes baseada em fontes mais indolor que já usei e o desenvolvimento parece bastante ativo. O que mais você poderia querer?

(Sim, todos os aplicativos ausentes)


11
Além disso, editar e corrigir fórmulas é realmente fácil com o homebrew.
bastibe
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.