der unterschied zu Debian Testing ist eben, dass es sich bei archlinux nicht um Testing handelt. ;) Und das andere ist eben, das wichtige Bestandteile wie Kernel & Co. keine oder weniger Patches enthalten. Mit weniger Patches meine ich, nur wenn tatsächlich etwas benötigt wird damit das System läuft, werden Patches eingebaut.... Oder man benötigt selbst irgendwelche Features die ansonsten nicht dabei sind.... Ansonsten ist das meiste quasi "vanilla". Archlinux ist etwas wie: leicht wie Debian, doch schnell und stabil wie Gentoo ...
Ich würde dennoch (für Anfänger) Debian oder Ubuntu empfehlen. Wenn man Linux mehr kennenlernt und gefallen darin findet, wird man mit der zeit so einiges ausprobieren und landet dann bei archlinux... ;) Ich hatte vor ein paar Wochen mit Blender 2.8 unter Archlinux gearbeitet und war überrascht wie schnell EEVEE war (warum auch immer).
"Deine Zeit ist begrenzt. Verschwende sie nicht damit, das Leben eines Anderen zu leben"
(Steve Jobs)
wenn du wirklich performance suchst, wirst du gegenwärtig kaum um clear linux herumkommen.
das ist gegenwärtig in fast allen benchmarks den anderen systemen deutlich überlegen.
aber natürlich ist geschwindigkeit alleine noch nicht alles! man will ja z.b. unterstützung für alle benötigte od. auch nur denkbare software direkt in der distribution vorfinden etc. und da schaut es natürlich mit dieser lösung nicht mehr ganz so rosig aus, weil ja z.b. der doch nicht ganz unwesentliche nvidia-support erst sehr spät dazugekommen ist etc.
im übrigen dürften all diese wunderbaren system-optimierungen bei closed source software wie resolve kaum den gewünschten erfolg zeigen, weil dort ja fast die ganze runtime umgebung durch beigepackte schrecklich veraltete und eben nicht-optimierte libraries ersetzt bzw. ausgebremst wird. in dem sinn ist es dann auch leider ziemlich gleichgültig, auf welcher distribution man das zeug verwendet.
"Arch Linux with the performance governor, optimized CFLAGS/CXXFLAGS in this test was much faster than Ubuntu and Antergos, but again Clear Linux came out ahead."
"Deine Zeit ist begrenzt. Verschwende sie nicht damit, das Leben eines Anderen zu leben"
(Steve Jobs)
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
ja das ganze ist eine ziemlich verrückte geschichte! :)
bei gentoo und arch war das ja noch getragen von verständlichem sportlichem ehrgeiz im rahmen der amateur-liga, aber bei clear linux hat das mittlerweile wirklich völlig abgehobene akademisch anmutende ausmaße angenommen, wo sich offenbar nur mehr die allerbesten compiler- und prozessorentwickler darin zu übertreffen versuchen, noch ein klein wenig mehr rauszuquetschen...
wirklich spannend sind dabei u.a. die verwendeten telemetrie- und selbstoptimierungstechniken.
Wobei diese Optimierungen im Zweifelsfall wieder Probleme nach sich ziehen und z.B. Clear Linux so auf Intel-CPUs optimiert ist, dass man es nicht auf AMD-Systemen einsetzen sollte, was den Einsatzzweck sehr einschränkt...
Ich kann nur davor warnen, dieses Bastler-, Nerd- und Freak-Diskussionen, die sich um Freak-Distributionen wie Gentoo, Clear etc. drehen, hier in Mainstreamforen von Mediengestaltern zu tragen, weil sie für die Zielgruppe absolut irrelevant sind und der Akzeptanz von Linux einen Bärendienst erweisen. (Das wäre genauso, als wenn auf ein Computertechnik-Forum die Diskussion über eine geeignete Videokamera in Esoterik-Debatten über die Vorteile von MagicLantern-raw mit gehackten Canon-Kameras ggü. einem Camcorder breittreten würde.)
Ich spreche da aus Erfahrung, weil wir in unserem Mediengestaltungs-Studiengang in der Vergangenheit einen Gentoo-Apostel als technischen Dozenten hatten, der erreichte, dass beinahe alle Studenten bei MacOS blieben. Seitdem er weg ist, verwenden 90% der Studenten Linux, und zwar i.d.R. Ubuntu.
@mash Könntest Du bitte noch erklären, was Du mit dem Verbiegen von Systempfaden/-variablen bei dem Debian-Paketskript für Resolve meinst? Das Programm wird in den Ordner /opt/resolve installiert und lässt sich mit der Standard-Paketverwaltung, wenn nötig, sauber und rückstandslos entfernen. Der /opt-Pfad mag zwar nicht Debian-richtlinienkonform sein, aber das ist für Anwender irrelevant. (Du musst Dir klar sein, dass Deine Postings hier von vielen gelesen werden und im Zweifelsfall missverstanden werden und für Gerüchte sorgen wie "ich habe gelesen, dass Resolve unter Ubuntu das System zerschiesst".)
"Wieso eigentlich überhaupt was drehen? Warum nicht jahrelang nur darüber philosophieren?" -stip
cantsin hat geschrieben: ↑Sa 11 Jan, 2020 21:10
Wobei diese Optimierungen im Zweifelsfall wieder Probleme nach sich ziehen und z.B. Clear Linux so auf Intel-CPUs optimiert ist, dass man es nicht auf AMD-Systemen einsetzen sollte, was den Einsatzzweck sehr einschränkt...
seltsamerweise zeigen die benchmarks ziemlich deutlich, dass auch AMD prozessoren von den verbesserungen profitieren.
es hat wohl mehr damit zu tun, dass es hier wirklich um tricks der optimierung geht, die den meisten programmieren gar nicht bewusst sind bzw. einfach nie in die zugrundeliegende software -- also bspw. ffmpeg -- eingeflossen sind. das gilt auch auch für die SVT-en/decoder, die auch auf AMD prozessoren ganz gut funktionieren, obwohl sie ja eigentlich sehr stark auf intel hardware zugeschnitten sind.
aber es gibt natürlich schon sachen, wo intel die konkurenz ganz bewusst in recht unschöner art und weise ausbremst, weil sie einfach manche optimierungen bzw. vektoroperationen in ihren mathematik- und medienverarbeitungslibraries nicht aktivieren, wenn der prozessor nicht aus dem eigenen hause kommt...
cantsin hat geschrieben: ↑Sa 11 Jan, 2020 21:10
Ich kann nur davor warnen, dieses Bastler-, Nerd- und Freak-Diskussionen, die sich um Freak-Distributionen wie Gentoo, Clear etc. drehen, hier in Mainstreamforen von Mediengestaltern zu tragen, weil sie für die Zielgruppe absolut irrelevant sind und der Akzeptanz von Linux einen Bärendienst erweisen.
bis zu einem gewissen grad verstehe ich die damit verbundene kritk schon.
ich würde ja auch niemandem raten, produktionsserver mit gentoo zu betreiben, weil es leider wirklich oft ein glücksspiel ist, ob das nach dem nächsten update wieder läuft. da bringt einem dann natürlich das ganze spiel mit optimierter kompilierung überhaupt nichts, wenn man sich einfach nicht darauf verlassen kann...
aber mit clear linux ist das ein bisserl anders. das ist eher eine distributionen, die tatsächlich auch für anspruchsvolle praktische aufgaben im cloud hosting umfeld eine absolut ernstzunehmende lösung darstellt.
und ehrlich gestanden verstehe ich nicht, warum BMD nicht vielmehr clear linux statt CentOS als basis pushed, wo doch gerade die dortige performance bei multimedia und transcoding tasks in den benchmarks immer ganz besonders heraussticht. ich bin mir ziemlich sicher, dass ein resolve auf dieser basis in vielen zeitaufwendigen cpu bound operationen fast doppelt so schnell wäre!
aber auf so etwas legt man bei BMD keinen großen wert. dort versteht man sich als hardware-hersteller und propagiert lieber die anschaffung neuer hardware, auch wenn sie von anderen produziert wird, statt tatsächlich auch softwarequalität und -optimierung ausreichend ernst zu nehmen.
cantsin hat geschrieben: ↑Sa 11 Jan, 2020 21:10
Ich spreche da aus Erfahrung, weil wir in unserem Mediengestaltungs-Studiengang in der Vergangenheit einen Gentoo-Apostel als technischen Dozenten hatten, der erreichte, dass beinahe alle Studenten bei MacOS blieben. Seitdem er weg ist, verwenden 90% der Studenten Linux, und zwar i.d.R. Ubuntu.
ja -- mit gentoo muss man einfach so seine erfahrungen gemacht haben, um etwas für's leben zu lernen. ;)
aber, um das ein bisserl zu relativieren, könnte ich dir auch von ganz vielen kollegen aus dem umfeld der elektronischen musik berichten, die ständig mit irgendwelchen linux-realtime-erweiterungen, L4-basierenden microkernels u.ä. herumexperimentieren, um die latenzen bzw. buffergrößen noch weiter nach unten zu schrauben. da schau ich dann auch immer ganz ungläubig und verständnislos zu und kann kaum verstehen, warum das den kollegen derartige mühen wert ist...
cantsin hat geschrieben: ↑Sa 11 Jan, 2020 21:10
@mash Könntest Du bitte noch erklären, was Du mit dem Verbiegen von Systempfaden/-variablen bei dem Debian-Paketskript für Resolve meinst? Das Programm wird in den Ordner /opt/resolve installiert und lässt sich mit der Standard-Paketverwaltung, wenn nötig, sauber und rückstandslos entfernen.
leider stimmt das nur beinahe -- der panel-treiber bzw. die beigepackte libusb-version wird offenbar vom installer noch immer im systempfad in nicht multiarch kompatibler weise abgelegt, und auch mit dem cuda support gibt es leider ständig probleme, wenn man die pfade bzw. tatsächliche platzierung zu korrigieren versucht.
"..., Then we know that this effectively sets stop for this hack on Debian and probably soon also on Ubuntu and others."
cantsin hat geschrieben: ↑Sa 11 Jan, 2020 21:10
Der /opt-Pfad mag zwar nicht Debian-richtlinienkonform sein, aber das ist für Anwender irrelevant. (Du musst Dir klar sein, dass Deine Postings hier von vielen gelesen werden und im Zweifelsfall missverstanden werden und für Gerüchte sorgen wie "ich habe gelesen, dass Resolve unter Ubuntu das System zerschiesst".)
der /opt-pfad ist schon o.k. und durchaus debian bzw. linux Filesystem Hierarchy Standard (FHS) konform. daran könnte man höchstens kritisieren, dass user-stettings nicht dort abgespeichert werden sollten, aber da kann ich gerne ein auge zudrücken. nur diese idotischen inkompatibilitäten mit den multiarch-konventionen bzw. hardcodierten pfaden in den binaries kann ich wirklich nicht akzeptieren. das ist weder saubere programmierung, noch zwingend notwendig, um das zeug zum laufen zu bringen -- weder auf CentOS, noch sonst irgendwo.
ich hab mich ja wirklich sehr lange an den entsprechenden diskussionen um verbesserungen im resolve forum bemüht, aber irgendwann hat man dann einfach genug davon, wenn sich gar nichts zum besseren hin ändert...
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
