Homebrew vs Fink vs Macports? [Zamknięte]


37

Używam Fink do instalowania aplikacji Unix na moim komputerze Mac, właśnie natknąłem się na Homebrew i zobaczyłem kilka dobrych opinii na temat Homebrew.

Moje pytanie brzmi:

  1. Jakiego menedżera pakietów używasz dla komputerów Mac?
  2. Obecnie używam Fink, więc czy naprawdę warto przejść z Fink na Homebrew?
  3. Jeśli 2. jest prawdą, to dlaczego?

Przeniosłem się z Fink do Homebrew, najlepszą rzeczą w homebrew jest to, że możesz go zainstalować w dowolnym miejscu, więc sudo nie jest wymagane. Które osobiście nie wolę. Wszelkie sugestie dotyczące Macports?
zengr

Po użyciu naparu wydaje mi się, że jest kilka opakowań, których nie ma. jak „meld” jest na Macports, ale nie na naparze.
zengr

meld jest teraz oferowany w naparze
Antony

Odpowiedzi:


7

Używam zarówno Fink, jak i Macports. Oba działają jak urok.

Ale mogę polecić Homebrew niezbyt zaawansowanemu użytkownikowi, który właśnie migruje z systemu Windows, ze względu na jego pozorną prostotę.


3
Kolejny głos na Homebrew. Wreszcie menedżer pakietów, który nie chce instalować całkowicie nowego systemu operacyjnego.
Paul Robinson

1
Jak prostota może być sprzeczna z Homebrew dla zaawansowanych użytkowników? Nigdy nie korzystałem z Fink, ale Macports nie jest kłopotliwy, nawet dla początkujących
Antony

jest rok 2016 i mniej więcej w 2010 roku przestałem używać fink, ponieważ po prostu przestał działać dla mnie. Zacząłem używać Macports i nadal działa świetnie. Nigdy nie próbowałem homebrew, ze względu na jego tendencję do robienia dziwnych, nie uniksowych rzeczy (filozoficznie) wrt sudo i / usr / local (krótko mówiąc: instalowanie pakietów powinno wymagać sudo i nie powinno używać / usr / local), a macports może działa lepiej dla moich starszych komputerów Mac. Jak dotąd mój Mac działa tak samo jak moja powłoka linux, dzięki Macports, który jest celem.
Michael

18

IMHO, problem z Homebrew polega na tym, że próbuje używać / usr / local w sposób, w jaki nigdy nie miał być używany: własnością innego użytkownika niż root. Rozumiem, że programiści homebrew starają się nie robić z niczym innym w / usr / local, nic innego, co instaluje się w / usr / local, nie robi tego samego dla Homebrew. Może to powodować problemy i ma dla mnie ... zwykle problemy z uprawnieniami wynikające z instalacji innego oprogramowania, które ustawia uprawnienia na / usr / local / w oparciu o „jak powinny być”. Nigdy nie zobaczysz innego pakietu oprogramowania oczekującego, że / usr / local / będzie własnością jednego użytkownika innego niż root, więc dlaczego Homebrew? Dlaczego nie po prostu użyć ~/bin?

Również mało znany fakt, dlaczego Fink i MacPorts kompilują własne biblioteki :

Istnieje kilka powodów, dla których MacPorts korzysta z własnych bibliotek. Sprawia, że ​​porty są bardziej spójne w różnych wersjach Mac OS X. Na przykład, jeśli możemy polegać na openssl 1.0.0 z MacPorts, nie musimy testować każdego portu, który potrzebuje ssl dla każdej dostępnej instalacji openssl. Oprogramowanie Apple od czasu do czasu pęka (np. Openssl odmawia tworzenia ze starym Zlibem, ale przez jakiś czas Apple wysyłało stare nagłówki podatnej na ataki wersji Zlib). Nawet jeśli wersje Apple'a nie są zepsute, rzadko są aktualne. Apple ma zwyczaj nie aktualizować bibliotek w Mac OS X, dopóki nie będzie to absolutnie konieczne z powodu usterki bezpieczeństwa.

Wady tej zasady są minimalne: marnowanie kilku megabajtów np. Na instalację Pythona jest prawie niczym, jeśli masz dysk twardy o pojemności wielu gigabajtów, a czas potrzebny na zbudowanie dodatkowych portów zmniejsza się w miarę przyspieszania komputerów.

Tak więc, chociaż Homebrew jest szybszy w instalacji, co chcesz, może mieć inne złe skutki uboczne przy użyciu wstępnie zbudowanych bibliotek systemowych Apple.

Znowu nienawidzę kopać przeciwko Homebrew. Lubię to oprogramowanie i myślę, że świetnie nadaje się do niektórych rzeczy, ale ma obecnie wadę.


Po prostu uruchom go jako root, jeśli uprawnienia się zmieniły? Stało się to dla mnie, pojawia się komunikat o błędzie i wydałem sudo. Jaki jest problem?
Daniel Beck

Problem jest według nich, nie tak należy to robić. Ich „zalecany sposób” jest niewłaściwy.
churnd

Robią jednak przekonujące argumenty przeciwko nadmiernemu sudoużyciu. Po prostu kończy się niepowodzeniem, gdy zaczniesz instalować własne programy w tym samym prefiksie. Większość oprogramowania poradzi sobie z instalacją gdzie indziej, więc może popełniłeś błąd? Fink i Macports właśnie stworzyli własną hierarchię katalogów, aby ominąć ten problem ...
Daniel Beck

8
Nie, nie zrobiłem tego źle. Praktyka posiadania / usr / local własnością zwykłego użytkownika jest nieprawidłowa. Nie zobaczysz tego nigdy w żadnym innym oprogramowaniu opartym na * nix. Każdy inny pakiet oprogramowania, który widziałem, dotyczy własności root: wheel / / usr / local. Po co w ogóle przejmować / usr / local? Dlaczego nie użyć / opt / homebrew i połączyć rzeczy z / usr / local / bin lub / usr / local / lib, jeśli musisz (choć z sudo)? Daj użytkownikowi wybór, ale nie psuj rzeczy, jeśli chcą je rozdzielić. Skonfiguruj odpowiednio środowisko w oparciu o ich wybór. Wszystko współistnieje pokojowo. Win-win.
churnd

Jestem tego świadomy, dziękuję. Po prostu użyj innego prefiksu. Kiedy ostatnio sprawdzałem, prefiks można było dostosować. Domyślne wartości dotyczą tego, co uważają za przeciętnego użytkownika. Dla ponad 90% użytkowników jest to wystarczająco dobre, ponieważ po prostu nie kompilują i nie instalują własnego oprogramowania /usr/local. Nie mają nawet wielu kont użytkowników, więc własność nie jest problemem i faktycznie poprawia całą obsługę.
Daniel Beck

15

Wolę homebrew ze względu na jego prostotę / szybkość - moje narzędzia wydają się być w tej chwili szybko aktualizowane.

Jest to najbardziej bezbolesne narzędzie do zarządzania pakietami, którego używałem, a programowanie wydaje się dość aktywne. Czego chcieć więcej?

(Tak, wszystkie brakujące aplikacje)


1
Ponadto edytowanie i naprawianie formuł jest naprawdę łatwe z Homebrew.
bastibe
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.