1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen

Erfahrungen mit Homebrew

Dieses Thema im Forum "Mac OS - Unix & Terminal" wurde erstellt von adore, 08.09.2017.

  1. adore

    adore Thread Starter MacUser Mitglied

    Mitglied seit:
    16.10.2014
    Beiträge:
    27
    Zustimmungen:
    3
    (Home)Brew funktioniert prima. Habe jetzt nur mal mc (Midnight Commander) und VLC installiert - kein Problem!
     
  2. Kaito

    Kaito MacUser Mitglied

    Mitglied seit:
    31.12.2005
    Beiträge:
    5.310
    Zustimmungen:
    615
    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.
     
  3. CyberTom

    CyberTom MacUser Mitglied

    Mitglied seit:
    29.03.2017
    Beiträge:
    623
    Zustimmungen:
    255
    @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.
     
  4. Kaito

    Kaito MacUser Mitglied

    Mitglied seit:
    31.12.2005
    Beiträge:
    5.310
    Zustimmungen:
    615
    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.
     
  5. Loki Mephisto

    Loki Mephisto MacUser Mitglied

    Mitglied seit:
    07.02.2005
    Beiträge:
    2.461
    Zustimmungen:
    338
    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
     
  6. adore

    adore Thread Starter MacUser Mitglied

    Mitglied seit:
    16.10.2014
    Beiträge:
    27
    Zustimmungen:
    3
    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!
     
  7. Schiffversenker

    Schiffversenker MacUser Mitglied

    Mitglied seit:
    25.06.2012
    Beiträge:
    6.431
    Zustimmungen:
    1.007
    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?
     
  8. electricdawn

    electricdawn MacUser Mitglied

    Mitglied seit:
    01.12.2004
    Beiträge:
    3.872
    Zustimmungen:
    1.619
    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.
     
  9. adore

    adore Thread Starter MacUser Mitglied

    Mitglied seit:
    16.10.2014
    Beiträge:
    27
    Zustimmungen:
    3
    Ich bevorzuge nun mal einen Paketmanager!

    Edit: Genau genommen sind Homebrew und Cask zwei Paketmanager
     
  10. electricdawn

    electricdawn MacUser Mitglied

    Mitglied seit:
    01.12.2004
    Beiträge:
    3.872
    Zustimmungen:
    1.619
    Ok... aber warum ist der App Store "nicht optimal"? Wenn's ein Update gibt, zeigt er dir das an, und du installierst. Presto.
     
Die Seite wird geladen...
Ähnliche Themen - Erfahrungen Homebrew
  1. Semmi
    Antworten:
    5
    Aufrufe:
    1.760

Diese Seite empfehlen