macOS: träge Softwarepflege?

[scenarnick]

eine günstige Alternative gibt für einen Office/Studi-Laptop

So ist der auch positioniert, denke ich. Trotzdem werden viele eben versuchen, auch andere Software darauf laufen zu lassen. Würde ich ja auch tun Ich schreibe das hier halt nur aus Sicht eines Software-Herstellers, der jetzt erstmal so eine Kiste bestellen muss, um eine Aussage zu Kompatibilität treffen zu können.

 

[adrachin]

Mit Software Kompatibilität sollte es eigentlich nur marginale Probleme geben. Wenn überhaupt. Das ist ein ARM64 Prozessor. Wie die M Professoren auch. Alles was für macOS Tahoe freigegeben ist sollte da laufen.

Aber wer will denn sowas ernsthaft verwenden für Audio? 1 x USB 3, 1 x USB 2. Ende Gelände. Und über einen muss dann auch noch geladen werden. Aber gut, wer bisher mit einem iPad unterwegs war, Probeaufnahmen und Co und das dann auf den Hauptrechner geschoben hat, den könnte sowas ansprechen. Die gewohnte Software und den gewohnten Workflow nutzen wie am Hauptrechner. Projekt da hin kopieren und gut ist.

 

[scenarnick]

Aber wer will denn sowas ernsthaft verwenden für Audio? 1 x USB 3, 1 x USB 2. Ende Gelände. Und über einen muss dann auch noch geladen werden.

Sehe ich jetzt nicht als kritisch an, wenn man keine Tasten hat. 1x USB zum Interface, 1x zum Laden. Interface nimmt alle akustischen Instrumente auf (Gitarre, Bass, Vocals, Sax, Drums). Würde für mich an Konnektivität völlig ausreichen. Und ja, es sind bei mir überwiegend Probenmitschnitte oder kleinere Sachen, die nicht offiziell released werden, vielleicht nur auf SoundCloud oder HearThis privat geteilt.

Mit Software Kompatibilität sollte es eigentlich nur marginale Probleme geben. Wenn überhaupt. Das ist ein ARM64 Prozessor. Wie die M Professoren auch. Alles was für macOS Tahoe freigegeben ist sollte da laufen.

Richtig - damit rechnen wir auch. Aber "sollte" reicht eben nicht, dass sich ein Hersteller das auf die Homepage unter "System Requirements" schreiben kann. Das wird einfach dauern, bis da ne offizielle Freigabe kommt.

 

[HD600]

Sehe ich jetzt nicht als kritisch an

Oha.. sehe ich jetzt erst. Ich habe mir geschworen nie wieder USB-C an einem Mac-Laptop zum laden, nur Magsafe. Mein MacBook Air M1 läuft eigentlich komplett rund und hat auch nur zwei USB-C-Anschlüsse die auch reichen könnten. Bin allerdings da öfter mal am Kabel hängen geblieben, seitdem muss ich öfters reinstecken damit er den Stecker erkennt. Deswegen nutze ich ihn auch nur stationär an einem externen Monitor. Der zweite USB-C-Anschluss geht auch nur sporadisch, zum laden garnicht aber Interface kein Problem. Seit gestern Abend hat der Mac innerhalb einer Stunde 10 Mal die Verbindung zum Monitor verloren, der Ton lief weiter aber der Bildschirm schaltete sich aus weil kein USB-C Signal. Habe dann vor lauter Frust einen Mac mini M4 mit 1TB und 24 GB bestellt, wollte ich eigentlich später erst holen..

Die Probleme die ich mit USB-C hatte, habe ich noch nie mit einem alten USB-Anschluss gehabt!

 

[scenarnick]

Vielleicht sollten wir das Thema zu den Neos auslagern (lassen).

Ich nutze mein MacBook Pro (M1Pro) nur stationär und hab nur USB-C im Einsatz. MagSafe ist vorhanden, wird aber nie benutzt. Ist aber ein anderes Thema als die SW-Freigabe durch Hersteller.

 

[mix4munich]

Ich finde, das ist keine gute Entschuldigung für die Hersteller. Und, wie geschrieben, was sollen denn die Käufer von neuen Macs tun, wenn nun mal das aktuelle Betriebssystem vorinstalliert ist?
...
Wenn du das kannst, dann sollten das die Hersteller doch mindestens ebenso gut können.

Die Hersteller können erst zu testen anfangen, wenn sie von Apple die neue Software bekommen. Soweit ich weiß (ich bin kein Programmierer und arbeite zwar mit einem Mac, aber nicht daran oder dafür), muss man dafür als Entwickler bei Apple registriert sein. Und dann ist es halt fraglich, ob Du für Apple wichtig genug bist, dass Du auch was bekommst. Sonst musst Du Dir halt einen neuen Mac kaufen oder die neue Software runterladen und kannst dann erst zu testen beginnen.

 

[adrachin]

Aber "sollte" reicht eben nicht, dass sich ein Hersteller das auf die Homepage unter "System Requirements" schreiben kann. Das wird einfach dauern, bis da ne offizielle Freigabe kommt.

So solle es ja auch sein. Hersteller haben eben andere Prioritäten als ein Privatier. der bekommt keine Service Anfragen wenn was nicht geht. Aber kann sich auch nicht beschweren wenn er was verwendet was vom Hersteller nicht als kompatibel ausgewiesen ist. Können schon. dann bekommt er aber eine Standard Mail vom Hersteller zurück..... (;

Noch erwähnenswert, der hat nur 8GB RAM. Mehr gibt es nicht. Vermutlich steckt alles in einem Chip. Wie beim Smartphone eben.

Die Hersteller können erst zu testen anfangen, wenn sie von Apple die neue Software bekommen.

Software gibt es schon einige Zeit. macOS Tahoe. Wie auf allen anderen neuen Mac auch.

 

[mix4munich]

... das neue MacBook Neo gesehen habe. Das kleine Gerät nutzt einen A18 Chip, keinen Apple M...

A18 Pro Chip, der von der Leistung einem M1 ähnelt, also genug für die meisten Sachen. Leider ist der Rechner unveränderlich auf 8 GB RAM beschränkt, was ihn für die meisten Audioarbeiten untauglich macht. Lieferbar mit 256 oder (für 100 EUR Aufpreis) 512 GB RAM. 13" Bildschirm mit 50 Nits Helligkeit, leider keine Tastaturbeleuchtung. Zwei USB-C Ausgänge und ein Kopfhörerausgang. Feddich.

 

[Mfk0815]

Das war irgendwie gefühlt schon immer so.

Es gab mal in der Software-Entwicklung die Regelung, dass mit einem großen Versionssprung die alte Programmierschnittstelle der vorigen Version weiter verfügbar ist, aber als "obsolet" gekennzeichnet wird, und somit die Programme nicht gleich auf die neue Programmierschnittstelle umgebaut werden müssen. So kann man als Hersteller von Software mit genügend Pufferzeit seine Software umstellen. Erst mit den nächsten großen Versionssprung (oder zumindest nach gut 12 Monaten nach dem Markieren als "obsolet") kann dann die alte Programmierschnittstelle entfernt werden. So war es mal üblich und ich als Entwickler von Basis Software (sog. Frameworks) mache das auch heute noch so. Meine Kunden würden mir den Kopf abreißen, wenn dem nicht so wäre.

Aber anscheinend hat sich das nicht in der ganzen Branche so erhalten. Da gibt es Firmen, die wohl (frei nach Orwell) "gleicher als gleich" sind und sich zu nobel sind, das zu machen. Da kann dann ja jeder entscheiden, wie er mit diesen Firmen weiter verfährt.
Am Ende laden die Hersteller das dem Enduser auf, denn der muss nach jedem Update mühsam prüfen, was geht noch und was nimmer. Hmm

 

[murmichel]

Gibt es denn konkrete Vorwürfe, dass Apple so etwas macht? Also APIs einfach kurzfristig entfernt, ohne dne Entwicklern eine ausreichend lange Vorlaufzeit für Anpassungen zu geben?

 

[scenarnick]

Gibt es denn konkrete Vorwürfe, dass Apple so etwas macht?

Apple gibt genug Vorwarnung, wann Altes entfernt wird. Bei denen ist es "planned obsolescence", man kann sich gut darauf einstellen, wann eine API oder auch ein Gerät nicht mehr unterstützt wird. Nur die Neuerungen werden eher "zeitnah" angekündigt.

 

[Mfk0815]

Ich weiß nur, dass Programme nach einem Update nicht mehr rund laufen. Das kann nur dadurch passieren, dass die Programme entweder Bug-Using betreiben (dann machen die Programm-Hersteller was falsch) oder dass sich die API (die Programmierschnittstelle) geändert hat, sei es durch wegfallen oder Verhaltensänderung. Beides ist nicht gut.

Apple gibt genug Vorwarnung, wann Altes entfernt wird.

Die Frage ist nur wann das genau dann wegfällt, es müsste zumindest eine Zeit geben in der die alte und neue Programmierschnittstelle gleichzeitig existieren. Nur so haben Hersteller von Anwendungen genügend Zeit die neue Schnittstelle zu verwenden bevor deren aktuellen Versionen nicht mehr mit einem neuen OS funktionieren. Basis Software, also auch und vor allem, das Betriebssystem ist für die IT so wichtig, da darf man sich als Hersteller dieser Komponenten meiner Meinung nicht erlauben, den darauf aufbauenden Anwendungen Prügel vor die Füße zu werfen.
Wobei aktuell sowieso ein Trend besteht, dass sich das Update-Rad immer schneller dreht und die Support-Zeiträume immer kürzer werden. Wenn das gepaart ist mit zu schnellen Abkündigungen von Programmierschnittstellen, kommt irgendwann keiner mehr hinterher bzw die Programme werden qualitativ immer schlechter werden, weil einfach keine Zeit mehr zum Testen ist, zumal Anwendungen dazu tendieren, mit dem Alter mehr Funktionen zu bekommen, was sie noch komplexer und schwerer zu testen macht.

 

[scenarnick]

Wobei aktuell sowieso ein Trend besteht, dass sich das Update-Rad immer schneller dreht und die Support-Zeiträume immer kürzer werden.

Richtig. Die ganzen SaaS sind da Vorreiter und Release schneller als man hinterherkommt. Dabei werden auch gerne APIs "angepasst". Das führt bei uns in der Firma dazu, dass wir zum Teil 3-4 Jahre alte Branches weiter am Leben halten müssen, weil unsere Kunden "langlebige" Produkte anbieten. Bei unserem Haupt-Produkt pflegen wir gerade aktiv 6 Branches mit 5-6 verschiedenen Targets (Mac, Linux, Windows, auf ARM und x86 jeweils)... Macht keinen Spaß

 

[Mfk0815]

Macht keinen Spaß

Nein, absolut nicht. Deshalb überlege ich auch ob ich noch lange in der Branche weiter arbeite, obwohl Software Entwicklung bei mir mal als Hobby begann.

 

[scenarnick]

Deshalb überlege ich auch ob ich noch lange in der Branche weiter arbeite,

Ich hab noch 11 Jahre vor mir Eine Rückkehr zu HW scheint in unserer Industrie (Broadcast) ausgeschlossen. Also muss ich da durch

 

[murmichel]

Die Frage ist nur wann das genau dann wegfällt, es müsste zumindest eine Zeit geben in der die alte und neue Programmierschnittstelle gleichzeitig existieren. Nur so haben Hersteller von Anwendungen genügend Zeit die neue Schnittstelle zu verwenden bevor deren aktuellen Versionen nicht mehr mit einem neuen OS funktionieren. Basis Software, also auch und vor allem, das Betriebssystem ist für die IT so wichtig, da darf man sich als Hersteller dieser Komponenten meiner Meinung nicht erlauben, den darauf aufbauenden Anwendungen Prügel vor die Füße zu werfen.

Das sind alles sehr vage Vorwürfe. Auf irgendeinen Hersteller, sei es von Betriebssystemen oder Frameworks, trifft es bestimmt zu. Die Frage ist aber, ob das auch für Apple gilt und damit eine geeignete Entschuldigung für die Hersteller von Musiksoftware ist.

Ich habe mir in den letzten Monaten eine Reihe an Synthesizer-Plugins von verschiedenen Herstellern angeschaut. Allein deren Installer und Verwaltungsprogramme sind abenteuerlich. Alles cross-platform-Geraffel – klar, Programmierer sind teuer. Human Interface Guidelines – nie gehört, betrifft uns nicht. Ordentliche Übersetzungen – lange nicht mehr gelacht. Datenablage – ach, wir müllen einfach den Dokumente-Ordner voll (und nennen ihn unübersetzt "Documents").

Das ist alles so lieblos und nachlässig gemacht, da würde es mich nicht im Geringsten wundern, wenn irgendwo in den Tiefen der verwendeten Frameworks längst abgekündigte APIs verwendet oder undokumentierte Sonderfälle ausgenutzt werden.

 

[Mfk0815]

Das sind alles sehr vage Vorwürfe.

Gerade den von dir zitierte Absatz sehe ich gar nicht mal als Vorwurf, sondern als Best Practice um Software-Entwicklung auf verschiedenen Ebenen zu ermöglichen. Das kann nur jemand dann auch als Vorwurf betrachten, wenn diese Praxis von demjenigen nicht eingehalten wird.

Und wie so üblich, sind es auch Menschen, die Software entwickeln. Damit ist es auch keine Besonderheit, dass manche es gut und manche es nicht soo gut bis ganz schlecht machen. Was da auch sicher eine Rolle spielt, ist die Tatsache, dass manch eine Entwicklung eine sehr arbeitsintensive ist, um das ganze dann gut zu machen. Nicht jede Garagenbude, in der ein einziger Entwickler sich von 18:00 bis 24:00 Uhr mit der Software auseinandersetzt (ist eine unbestätigte Vermutung und dient nur zur Veranschaulichung), kann die höchsten Qualitätsstandards erfüllen. Ich schreib auch hin und wieder Tools, die so quick&dirty runter entwickelt und nicht für jedermann gedacht sind. Das kann schon sein. Allerdings lege ich etwas höhere Ansprüche an ein weltweit renommiertes Unternehmen, deren Entwicklungskapazitäten locker im guten 5-6 stelligen Personal-Bereich liegen könnten (denke ich mal). Da ist sicher nicht der eine Hinz oder Kunz, dem man sagt, ach mach doch mal und entwickle alleine ein OS für die ganze Welt.

Und ja, Bug Using ist sicher auch ein Problem wenn von einem Tag zum nächsten eine Software nicht mehr funktioniert, einfach weil der Hersteller der API den Bug irgendwann vielleicht doch ausgebessert hat. Undokumentierte Sonderfälle sollte es in einer offiziellen API eines Großunternehmens aber nicht geben. Das ist schlampig und unprofessionell. Wenn dann sollte der Sonderfall auch dokumentiert sein und als "Internal Used only" markiert werden. Dann mache ich als verantwortungsvoller Benutzer der API halt einen großen Bogen um diese Funktionen.

 

[murmichel]

Mir geht es nicht um Garagenbuden. Mir geht es um Unternehmen, die innerhalb der Musikbranche eine ansehnliche Größe haben. Schau nochmal auf die Sweetwater-Kompatibilitätsseite und suche dort nach "No macOS Tahoe 26 information yet." Die Seitenleiste bekommt dann ein ansehnliches Muster durch die vielen Treffer. Ich finde, da sind noch immer viele Unternehmen bei, von denen man als Kunde mehr erwarten kann.