Erfahrungen mit Homebrew

(Home)Brew funktioniert prima. Habe jetzt nur mal mc (Midnight Commander) und VLC installiert - kein Problem!
 
gcc hat stark aufgeholt seit es llvm (clang) gibt. Die beiden nehmen sich nicht viel. Was gcc für sich hat ist, dass so manches an Software noch immer nicht mit llvm übersetzt werden kann (prominentestes Beispiel sei der Linux Kernel und hier besteht auch kein Interesse das je zu ändern).
gdb auf OSX ist eine heikle Sache, da es u.A. nicht funktioniert (das heißt meist reduzierte Funktionalität hat). In aller Regel funktionieren bestimmte gdb Versionen nur auf bestimmten OSX Versionen (wenn überhaupt). Immerhin ist das (debugging) eine Sache, die sehr tief mit dem OS verwurzelt ist. Mit dem Nutzen von lldb bist du hier auf der sicheren Seite.
Allerdings hat gdb deutlich mehr Features, z.B. reverse debugging. Noch offene Dinge in lldb: https://lldb.llvm.org/projects.html
Als llvm frisch rauskam hat es ggc relativ vernichtet, dieser Zustand schwebt gerne noch in den Köpfen. Aber hier hat sich viel getan.

Bezüglich homebrew ist nur zu sagen, dass wenn du einen Paketmanager benötigst, es dieser ist, den du nutzen solltest.
Durch seine Architektur sind viele Dinge wie Kompilierprobleme doch enorm rar und seit den Bottles ist es noch einfacher. Selbst eine konfuse Umgebung auf dem Rechner kann Homebrew nicht mehr viel anhaben (etwas woran macports traditionell zu beißen hatte).
Homebrew ist aber auch noch lange kein fertiger Paketmanager mit den gleichen Features eines entsprechenden aus der Linuxwelt. Da frage ich mich manchmal, ob die Ressourcen bzgl. Entwicklung nicht etwas doof priorisiert sind.
Was mich dabei am meisten stört ist das mangelhafte (bzw. non-existente) dependency tracking. Beispiel: ich installiere ffmpeg und das holt sich als dependency libpng 1.0 mit rein. Dann update ich ein anderes Programm später welches als dependency libpng zu 2.0 updated. Nun müsste ffmpeg eigentlich neu kompiliert werden, aber brew bekommt diese Problemstellung nicht mit und macht entsprechend nichts. Das installierte ffmpeg ist nun nicht mehr nutzbar und crashed bei Verwendung, aber das bemerkt man natürlich nur, wenn man es benutzen will.
Die ganze Sache ist etwas komplizierter als das und hat noch mehr Variablen, aber gerade das genannte Beispiel tritt bei mir sehr häufig auf. ffmpeg hat halt einfach mal eben 10-50 dependencies, da passiert sowas auch schnell.
Historisch versucht(e?) brew das mit versionierten Formeln anzugehen (also libpng@1, libpng@2), was aber nicht des Rätsels Lösung ist, aus diversen offensichtlichen Gründen.
Brew kann auch keine Formeln löschen und dabei alle dependencies gleich mitentsorgen, die diese Formel als einzig Wurzel hatten. Da existiert glücklicherweise eine Art "Plugin" für, ist aber unmaintained und hat ein paar Probleme.
Das klingt jetzt alles relativ negativ und entsprechende Punkte werden Menschen, die mächtigere Paketmanager gewohnt sind, aufstoßen. Dennoch ist brew das imo beste, das ihr hier auf OSX bekommen könnt.
 
  • Gefällt mir
Reaktionen: nkonde und CyberTom
@Kaito

Absolut korrekt was du geschrieben hast. Deswegen würde ich in der Regel erst versuchen ob es nicht doch Builds für die entsprechenden Programme gibt und erst dann die brew-Version des Builds nehmen. Würde z.B. vermuten dass vlc nur installiert aber nicht compiliert wird, von mc gibt es auch einen nicht-offiziellen Build und von ffmpeg gibt es auch sehr schnell Builds. smartmontools, rsync, ... kann man mit wenigen Befehlen selber compilieren.
 
Naja, ich benutze einen Paketmanager ja nicht, weil mir das selbstständige Kompilieren zu kompliziert ist, sondern aus Organisationsgründen. Ich habe aktuell knapp 200 Formulas installiert. Das ist eine kleine Menge, ich versuche sie bewusst klein zu halten und dünne oft aus. Aber schon 200 Formulas in einem nicht näher ersichtlichen Netz aus Dependencies kannst du nicht per Hand managen. Updates für alle, entsprechende Dependency-Behandlung etc., das ist per Hand nicht drin und daher benutzt man/ich einen Paketmanager.

Allgemein nutze ich brew nur für Kommandozeilenprogramme, GUI Sachen wie VLC hole ich auf konventionellem Wege u.A. auch weil die ja eigene Updatemöglichkeiten haben. Wobei man das mit brew theoretisch auch machen kann (brew cask), aber ich will keine wilde Mischung in meinem Programme-Ordner haben.

Vorkompilierte Builds für Kommandozeilentools (non-GUI Zeug) von einer Website laden ist mMn aber die schlechteste aller existierender Möglichkeiten.
Kein Management, keine Updates (außer du prüfst die Website und lädst per Hand erneut runter), eingeschränkte Möglichkeiten der Entwicklung (idR keine Header enthalten, mal eben mit Debug Symbolen rekompilieren ist nicht), geringere Sicherheit (kompromittierte DL Server - auch bei OSX Programmen schon passiert, siehe Transmission das sich auf Malware geupdated hat) und keine Wahl der Features*. Ich sehe es definitiv ein GUI Programme so zu handhaben, auch weil man davon idR deutlich weniger hat, aber mit Kommandozeilentools macht man das nicht - nutzt ja nicht ohne Grund jede Distribution Paketmanager. ;)
Builds sind idR auch mit Kompatibilität erstellt und nicht auf spezifische neue Instruktionssets moderner CPUs angepasst, was sie entsprechend langsamer macht. Wozu hab ich eine neue Intel CPU, wenn ich sie nicht ausnutze? ;) Nicht viele Programme können sowas dynamisch zur Laufzeit entscheiden (ffmpeg kann).

* ffmpeg z.B. darf wegen der GPL gar nicht als Build mit allen Features angeboten werden, das betrifft auch viele andere Programme. Wenn du also alle Features willst, dann musst du selbst bauen. Wenn du an Tools wie ffmpeg näheres Interesse hast, dann willst du die auch regelmäßig updaten. Ich mach das ein mal pro Woche. Das wäre mir per Hand schon zu doof und das nur für ein Tool.
 
  • Gefällt mir
Reaktionen: Loki M
Mach ich ganz ähnlich.

Zum Thema Clang und Linux Kernel: daß dieser nicht mit Clang compiliert ist nicht einem Fehler oder Unzulänglichkeit geschuldet, sondern eher deswegen weil Clang strikter ist als gcc. Und das ist im Prinzip eigentlich eine gute Sache.

Clang/llvm wurde von Apple auch deswegen ins Leben gerufen/forciert, um
* einen effizienteren Compiler zu schaffen (gcc schneidet im Performancevergleich mit Intel oder Microsoft Compilern nicht sehr gut ab)
* einen universelleren Compiler zu schaffen (Code-Generierung für diverse CPUs) und mit der Intermediate Representation für viele Sprachen geeignet
* nicht zuletzt einen strikteren Compiler, der zudem Entwicklern aussagekräftigere Error/Warnmeldungen ausgibt, entsprechend der LLDB beim Debuggen unterstützt.
* einen Static Analyzer zu implementieren (ARC!)

Finde das Clang/llvm schon ein deutlicher Fortschritt gegenüber gcc ist
 
Seit ein paar Tagen nun bin ich Eigentümer eines MBP, 13'', i5, 8GB, SSD.
Selbst kompilieren möchte ich vermeiden. Wenn ich beispielsweise LibreOffice kompilieren wollte, würde das Gerät vermutlich mehrere Stunden unter Volllast laufen. Aufgrund der Bauweise des MBP habe ich da in Punkto Wärmeableitung so meine Bedenken.

Nun gibt es in Bezug auf LibreOffice mindestens vier weitere Möglichkeiten es zu installieren:
- zwei über den App Store - kann nicht optimal sein, denke ich mal.
- das aktuelle Diskimage runterladen und installieren.
- über Homebrew-Cask installieren.

Ich bin geneigt über Homebrew-Cask zu installieren. In der Hoffnung, dass die Version unter Sierra als 'stable' bezeichnet werden kann?
Eure geschätzte Meinung dazu wäre hilfreich!
 
Wozu über Homebrew, wenn man einfach das fertige OS-X-Binary starten kann?
Und warum glaubst du, der Weg über den AppStore könne "nicht optimal" sein?
 
  • Gefällt mir
Reaktionen: electricdawn
Da muss ich Schiffversenker mal recht geben. Was ist am App Store "nicht optimal"? Ausser man macht das ueber Homebrew nur um seine Neugierde zu befriedigen.
 
Ich bevorzuge nun mal einen Paketmanager!

Edit: Genau genommen sind Homebrew und Cask zwei Paketmanager
 
Ok... aber warum ist der App Store "nicht optimal"? Wenn's ein Update gibt, zeigt er dir das an, und du installierst. Presto.
 
Wozu einen Paketmanager, wenn man ein geschlossenes Programmbundle benutzen will? Manager sind praktisch für Programme, die auf gemeinsame Libraries usw. zugreifen, aber ich bezweifle, daß man damit bei LibreOffice oder OpenOffice irgendetwas an Platz einspart oder besser im Griff hat oder über die Möglichkeiten der normalen OS-X-Version hinaus anpassen kann. Einzig denkbarer Vorteil in meinen Augen: daß man bei einer Aktualisierung vielleicht ein paar MB an Downloads spart.
Bekommt man mit diesem Weg überhaupt die "normale" OS-X-Oberfläche oder wie ganz früher X11?
 
  • Gefällt mir
Reaktionen: electricdawn
LibreOffice ist eines der wenigen Pakete, die man sowohl im AppStore findet als auch bei Homebrew. Aber eigentlich ist der AppStore darauf ausgelegt, Geld in die Kassen von Apple zu spülen (Software zu verkaufen) und Homebrew ist darauf ausgelegt, ein Paketmanager für kostenlose (freie) Software zu sein.

Der Riesenvorteil von Homebrew: ich kann mit einem Aufruf in der Kommandozeile auf einem neuen Mac alle 77 Pakete installieren, die ich auf meinem alten habe. Wie lange müsste ich im AppStore herumklicken dafür? 1 Stunde? Dafür ist der AppStore hübscher und einfacher zu bedienen für normale Anwender.
 
Manchmal bedient sich Apple mit seinem App Store auch einfach nur bei Homebrew - ich unterstelle mal, ohne das Projekt finanziell zu unterstützen.
Hier am Beispiel des Dateimanagers mc (midnight commander):
http://macappstore.org/midnight-commander/
 
Denkst du ernsthaft diese Seite ist von Apple...?
Hab mich schon immer gewundert wer diese Menschen sind, die auf Phishing reinfallen. ;)

Tatsächlich halte ich mich von dem (echten) App Store auch so fern wie möglich. Das liegt u.A. an gewissen Restriktionen (manche Programme haben Funktionen die man im App Store nicht haben kann/darf, dann landet eine Version mit geringerer Funktionalität im Store) und weil ich es nicht so geil finde, Programme zu haben, die bei jedem Start erstmal gegen meine Apple ID geprüft werden müssen, um zu bestimmen, ob ich sie starten darf (also DRM).
 
  • Gefällt mir
Reaktionen: agrajag und thorstenhirsch
Ich würde SW nur aus dem Appstore installieren, wenn es nicht anders geht. Mal abgesehen davon, daß ich die Appstore-Anwendung furchtbar und umständlich finde, findet man dort schon viele der guten Anwendungen nicht mehr, da die sich aufgrund der Restriktionen wieder entfernt haben, bzw. nie dort erschienen sind. Ich hab diverse Programme, die ich über den Appstore gekauft habe, später aber in eine Non-Appstore-Version umlizensiert habe (zum Glück bieten einige Entwickler dies an). Ich finde zudem sehr problematisch, wie es mit den Updates läuft. Beta- und Alpha-Programme gibt es nicht und kann es auch, aufgrund der Restriktionen, nicht geben.

Homebrew nutze ich nur für Shell-Programme.
 
Frage an alle Homebrew Nutzer. Ich habe seit zwei Tagen das Problem, dass bei einigen Apps die ich via Homebrew installiert habe bei jedem nachgefragt wird, ob ich die App wirklich starten möchte (Gatekeeper). LibreOffice, Firefox, Whatsapp Desktop Client wären solche Kanditen. Andere Apps wie VLC oder Wire Messenger starten ohne Probleme.
 
Hilft nicht, aber mich würde interessieren, warum du LibreOffice, Firefox und VLC via Homebrew installiert hast und nicht die bequemen nativen Varianten benutzt. Irgendwelche Anpassungen, die nur via Homebrew möglich sind? Neuere Varianten?
 
ich bin parallel zum mac in der linux welt groß geworden und mag einfach einen guten paketmanager den ich bequem per kommandozeile bedienen kann. setze ich meinen mac frisch auf reicht ein langer befehl und alle apps die ich brauche sind in einem rutsch installiert oder später auf den neuesten stand gebracht. ich finde die bedienung des app store grauenvoll, schade das es hier keine möglichkeit über die kommandozeile gibt.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten