Homebrew vs Fink vs Macports? [đóng cửa]


37

Tôi đang sử dụng Fink để cài đặt các ứng dụng Unix trên máy mac của mình, tôi vừa xem qua Homebrew và thấy một số đánh giá tốt về Homebrew.

Vì vậy, câu hỏi của tôi là:

  1. Các bạn sử dụng trình quản lý gói nào cho Mac?
  2. Tôi hiện đang sử dụng Fink, vậy việc chuyển từ Fink sang Homebrew có thực sự xứng đáng không?
  3. Nếu 2. đúng thì tại sao?

Tôi đã chuyển từ Fink sang Homebrew, điều tốt nhất về homebrew là bạn có thể cài đặt nó ở bất cứ đâu, vì vậy không cần sudo. Mà cá nhân tôi không thích. Bất kỳ đề xuất về macports?
zengr

Sau khi sử dụng brew, tôi cảm thấy có vài gói không có ở đó. như "meld" là trên macports nhưng không phải trên brew.
zengr

meld hiện được cung cấp trong bia
Antony

Câu trả lời:


7

Tôi sử dụng cả Fink và Macports. Cả hai làm việc như một lá bùa.

Nhưng tôi có thể khuyên Homebrew không nên sử dụng chuyên gia, những người chỉ di chuyển từ windows, vì sự đơn giản rõ ràng của nó.


3
Một phiếu bầu khác cho Homebrew. Cuối cùng, một trình quản lý gói không cảm thấy như cài đặt một hệ điều hành hoàn toàn mới.
Paul Robinson

1
Làm thế nào đơn giản có thể đi ngược lại Homebrew cho người dùng chuyên gia? Tôi chưa bao giờ sử dụng Fink, nhưng Macports không có trí tuệ, ngay cả đối với người mới
Antony

đó là năm 2016 và khoảng năm 2010 trở lại đây, tôi đã ngừng sử dụng fink, vì nó đã ngừng hoạt động đối với tôi. Tôi bắt đầu sử dụng macports, và nó vẫn hoạt động rất tốt. Không bao giờ thử homebrew, vì xu hướng làm những thứ không kỳ lạ (về mặt triết học) wrt sudo và / usr / local (nói ngắn gọn: cài đặt các gói nên yêu cầu sudo và không nên sử dụng / usr / local) và macports có thể làm việc tốt hơn cho máy Mac cũ của tôi. Cho đến nay, mac của tôi hoạt động giống như shell linux của tôi, nhờ macports, đó là mục tiêu.
michael

18

IMHO, vấn đề với Homebrew là nó cố gắng sử dụng / usr / local theo cách mà nó không bao giờ được sử dụng: thuộc sở hữu của người dùng không phải là root. Mặc dù tôi hiểu rằng các nhà phát triển homebrew chú ý không di chuyển với bất kỳ thứ gì khác trong / usr / local, nhưng không có gì khác cài đặt vào / usr / local sẽ làm tương tự cho Homebrew. Điều này có thể gây ra sự cố và đối với tôi ... thường là các sự cố về quyền do cài đặt phần mềm khác đặt quyền trên / usr / local / dựa trên "chúng nên như thế nào". Bạn sẽ không bao giờ thấy gói phần mềm khác mong muốn / usr / local / được sở hữu bởi một người dùng khác ngoài root, vậy tại sao Homebrew? Tại sao không chỉ sử dụng ~/bin?

Ngoài ra, một thực tế ít được biết về lý do tại sao Fink & MacPorts biên dịch thư viện của riêng họ :

Có một số lý do tại sao MacPorts sử dụng các thư viện riêng của mình. Nó làm cho các cổng phù hợp hơn trên các phiên bản khác nhau của Mac OS X. Ví dụ: nếu chúng tôi có thể dựa vào openssl 1.0.0 từ MacPorts, chúng tôi không phải kiểm tra mọi cổng cần ssl cho mỗi lần cài đặt openssl có sẵn. Phần mềm của Apple có xu hướng phá vỡ theo thời gian (ví dụ: openssl từ chối xây dựng với một zlib cũ, nhưng trong một thời gian, Apple đã chuyển các tiêu đề cũ của phiên bản zlib dễ bị tổn thương). Ngay cả khi các phiên bản của Apple không bị hỏng, chúng vẫn hiếm khi được cập nhật. Apple có thói quen không cập nhật các thư viện trong Mac OS X cho đến khi hoàn toàn cần thiết bởi một lỗ hổng bảo mật.

Hạn chế của chính sách này là tối thiểu: Lãng phí một vài megabyte, ví dụ như cài đặt Python không có gì nếu bạn có ổ cứng nhiều gigabyte và thời gian cần thiết để xây dựng các cổng bổ sung giảm khi máy tính nhanh hơn.

Vì vậy, trong khi Homebrew nhanh hơn để cài đặt những gì bạn muốn, nó có thể có các tác dụng phụ xấu khác từ việc sử dụng các thư viện hệ thống được xây dựng sẵn của Apple.

Một lần nữa, tôi ghét phải đào chống lại Homebrew. Tôi thích phần mềm này và tôi nghĩ rằng nó rất tốt cho một số thứ, nhưng hiện tại nó có nhược điểm.


Chỉ cần chạy nó như root nếu quyền đã thay đổi? Nó đã xảy ra với tôi, có một thông báo lỗi và tôi đã sửa sudo. Có vấn đề gì vậy?
Daniel Beck

Vấn đề là theo họ, đó không phải là cách nó được thực hiện. "Cách đề nghị" của họ là không đúng.
churnd

Họ làm một trường hợp thuyết phục chống lại việc sudosử dụng quá mức mặc dù. Nó chỉ thất bại khi bạn bắt đầu cài đặt các chương trình của riêng mình vào cùng một tiền tố. Hầu hết các phần mềm có thể xử lý được cài đặt ở một nơi khác, vì vậy có lẽ bạn đã làm sai? Fink và Macports vừa tạo hệ thống phân cấp thư mục của riêng họ để vượt qua vấn đề này ...
Daniel Beck

8
Không, tôi đã không làm sai. Việc sử dụng / usr / local do một người dùng thông thường sở hữu là sai. Bạn sẽ không thấy điều đó với bất kỳ phần mềm dựa trên * nix nào khác. Mọi gói phần mềm khác tôi từng thấy đều tôn trọng root: quyền sở hữu bánh xe của / usr / local. Tại sao thậm chí tiếp quản / usr / local? Tại sao không sử dụng / opt / homebrew & liên kết mọi thứ với / usr / local / bin hoặc / usr / local / lib nếu bạn phải (mặc dù với sudo)? Cung cấp cho người dùng sự lựa chọn, nhưng đừng phá vỡ mọi thứ nếu họ muốn giữ mọi thứ riêng biệt. Thiết lập môi trường của họ phù hợp dựa trên sự lựa chọn của họ. Mọi thứ cùng tồn tại một cách hòa bình. Thắng-thắng.
churnd

Tôi nhận thức được điều đó, cảm ơn bạn. Chỉ cần sử dụng một tiền tố khác nhau sau đó. Lần trước tôi đã kiểm tra, tiền tố đã được tùy chỉnh. Mặc định là cho những gì họ coi là người dùng trung bình của họ. Đối với 90 +% người dùng, điều đó là đủ tốt, vì họ chỉ không biên dịch và cài đặt phần mềm của riêng họ /usr/local. Họ thậm chí không có nhiều tài khoản người dùng, vì vậy quyền sở hữu không phải là vấn đề ở đó và thực sự cải thiện toàn bộ trải nghiệm.
Daniel Beck

15

Tôi thích homebrew do tính đơn giản / tốc độ của nó - các công cụ của tôi dường như đang được cập nhật nhanh chóng vào lúc này.

Đây là công cụ quản lý gói dựa trên nguồn không đau nhất mà tôi đã sử dụng và phát triển có vẻ khá tích cực. Bạn có cần gì nữa không?

(Có, tất cả các ứng dụng còn thiếu)


1
Ngoài ra, chỉnh sửa và sửa chữa các công thức thực sự dễ dàng với homebrew.
bastibe
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.