Big Sur Probleme

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Big Sur Probleme

    Hallo!

    Ich möchte vorausschicken, dass ich seit Ewigkeiten auf Mac arbeite. Ganz unbedarft bin ich also nicht. Trotzdem hab ich grad ein paar nicht unwesentliche Probleme und bitte um eure Hilfe.

    Seit kurzem habe ich den neuen Mac Mini M1 mit OSX 11. Heute wollte ich auf 11.1 updaten und wollte mich dazu bei meinem Adminaccount anmelden. Geht aber nicht mehr. Passwort wird nicht erkannt. Habs x-mal an verschiedenen Stellen probiert. Geht nicht. Mag sein, dass ich es mir falsch aufgeschrieben habe. Oder auch nicht...
    Hab mich dann als "normaler" Benutzer angemeldet. Und siehe da ich konnte das Update von hier aus mit dem Benutzerpasswort dieses Accounts, also ohne Verwaltungsrechte, durchführen. Ich muss zugeben, dass ich das vorher noch nie ausprobiert habe.
    Ist es richtig so, dass ein Nichtadmin ein Systemupdate machen darf ? Kommt mir fragwürdig vor.
    War das schon immer so ?

    Leider geht das Adminpasswort immer noch nicht. Einzige Besonderheit dieses Passworts ist das ein "ß" vorkommt.
    Kann das ein Problem sein ?

    Also will ich den Rechner jetzt zurücksetzen. Ist schließlich noch in der Testphase und fast jungfräulich.
    Leider geht auch das starten des Recoverymodus nicht. Weder Cmd+R noch Cmd+Alt+R. Auch Cmd+S geht nicht.
    Was jetzt ? Hat jemand eine Idee ?

    Danke und Gruß
    Thomas
  • Hi Thomas,

    ich kann es (noch) nicht selber ausprobieren, aber diesem Artikel zufolge ist ein langes Drücken des Power-Buttons für M1-Macs der Weg zu den Startup-Optionen...
    Recovery Mode, to check startup disk, reinstall macOS, restore from a backup, change security settings

    Press and hold the Power button until the display shows Loading Startup Options, then release it. This takes you to the Startup Optionsscreen. Select the Options icon, then click Continue underneath it.
    Vielleicht hilft's ... und ich würde in Passwörtern keine "national characters" verwenden :)

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • Ich hatte so ein ähnliches Problem, als ich zusätzlich Big Sur auf einer neuen Partition/Container/Disk neben meiner Catalina Installation angelegt habe.

    Ich konnte mich nicht als Nutzer A anmelden. Aber als Nutzer B und Nutzer B hat das selbe Passwort. Als ich dann zu Nutzer A gewechselt habe (schneller Nutzerwechsel - oder wie das heißt), ging das ohne Probleme. Wenn ich mich jetzt als A abgemeldet habe, konnte ich mich sogar wieder als A anmelden. War echt komisch.

    Das Problem konnte ich sogar lösen. Das lag daran, dass mein Nutzer A (selber Name wie in Catalina) ein anderes Passwort hatte. Als die beiden Nutzer A (Big Sur) und Nutzer A (Catalina) das selbe Passwort hatten, dann ging es wieder.
  • Hallo Zusammen,

    anbei mal unsere Erfahrungen mit Big Sur. Wir haben Big Sur auf unterschiedlichen Mac Mini Modellen probehalber installiert. Aufgefallen ist uns, dass zumindest der Bootvorgang und die Zeitspanne beim Aufrufen von Apps geringer ist. Nun ja - dachte ich, der erste Eindruck bzgl. dieser Beobachtung ist doch eher subjektiver Art. Da jedoch auch weitere Kollegen diese Beobachtung ebenfalls bestätigten, tendieren wir mitzuteilen, dass es wohl auch objektiv so zu sein scheint. Diese und die nachfolgenden Aussagen beziehen sich immer auf unsere eingesetzte Hardware.

    Probleme mit Accounts bzw. den Passwörtern hatten wir zu keinem Zeitpunkt. Jedoch können wir mitteilen, dass die An- bzw. Einbindung in eine Domäne nicht auf Anhieb funktioniert hat. War aber auch keine größere Herausforderung. Nach einem Reboot funktionierte dies bei fast allen Clients perfekt.

    Da wir die Clients via OS X Server verwalten, kann ich mitteilen, dass dies nicht mehr reibungslos funktioniert. Mit viel Aufwand konnten wir auch diese Hürde meistern, jedoch muss ich an dieser Stelle mitteilen, dass die eingesetzte Zeit in keinem Verhältnis zum Nutzen steht. Fazit - wir werden sofern wir den Umstieg auf Big Sur auf allen Clients vollziehen, unsere OS X Server (welche wir nur intern nutzen) endgültig abschalten.

    Das Design ist sehr an iOS angelehnt. Ist für Einsteiger bestimmt einfacher sich zurecht zu finden. Man kann darüber natürlich diskutieren, aber vielen von uns hat es gefallen.

    Das man die Recovery-Funktionen nur via Power-Button aktivieren kann, ist sehr gewöhnungsbedürftig. Zumal wir hier Anwender haben, die einfach nicht die sensible Motorik besitzen, diesen mit Gefühl zu betätigen. :D . Hatten schon mehrfach Ausfälle weil sich der Power-Button einfach nicht mehr drücken lies. Aus diesem Grund wäre es mir lieber, wenn die Recovery-Funktionen wieder via Tastatur aufrufbar wären. 8)

    Bzgl. der Kompatibilität kann ich nicht wirklich viel mitteilen. Diese Tests laufen gerade an. Erkenntnisse werde ich mitteilen. Dauert aber, aufgrund der momentan herrschenden Situation unter der wir alle leiden, noch an.


    Bleibt alle Gesund und Grüße


    Nachtrag:
    Wir mussten feststellen, dass Big Sur nicht alle etablierten Netzwerkverbindungen anzeigt. Inwieweit welche Informationen übertragen werden, kann ich i. A. nicht mitteilen, da die Auswertungen der Firewall-Logs noch läuft.

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von OSXDev () aus folgendem Grund: Nachtrag

  • Hallo,

    wir haben uns nun kurzfristig einen Mac Mini M1 angeschafft, um mit diesem parallel Test-Szenarien durchzuführen.

    Ein wichtiger Faktor ist die Verarbeitungsgeschwindigkeit. Zu dieser können wir folgendes mitteilen. Wir haben für den M1 ein kleines Testprogramm geschrieben welches uns die Primzahlen (bis 10000), aufgeteilt auf mehrere Threads, berechnet. Im Vergleich zum Intel i5 (schwächster Mac Mini der bei uns im Einsatz ist) unterliegt der M1. Des Weiteren haben wird eine Fließkomma App (komplexe Kurvenberechnungen) ebenfalls für den M1 erstellt. Hier zeigte sich ebenfalls, dass der M1 unterlegen ist.

    Nun ja - könnte ja auch an unseren TestApps liegen. Also testeten wir Page, Keynote und Number. Aber auch hier wurden die zuvor erzielten Ergebnisse subjektiv bestätigt. Zu guter Letzt hat sich noch ein FinalCut Anwender am M1 probiert. Hmmmmmm - ohne Worte.

    Da Apple den M1 bewirbt als ob dieser nun einen Quantensprung in der Rechnertechnologie sei, haben wir Apple direkt um eine Stellungnahme zu unseren Ergebnissen gebeten.

    Fazit:
    Die heutige Varianten des M1 bzw. dessen Geschwindigkeitsangaben beziehen sich auf ein Vergleichsgerät, welches mit einem Intel i3 Prozessor ausgestattet ist bei gleicher Festplatten- und Hauptspeichergröße. Auf unsere Ergebnisse wollte man keinen Bezug nehmen. Wir kontaktierten daraufhin den Support telefonisch und da erhielten wir die Aussage, dass sich die Verarbeitungsgeschwindigkeit noch im Laufe der nächsten Gerätegenerationen erheblich erhöhen würde. Aus diesem Grund werden auch i. A. keine Geräte der Pro-Serie mit M1-CPUs versorgt.

    Was uns auch aufgefallen ist, dass Big Sur sich auf dem M1 bei weitem nicht so agil bzgl. Ansprechverhalten (starten von Apps, Zeitspanne des Bootvorganges) verhält wie dies auf Intel Macs der Fall ist. Kann natürlich daran liegen, dass wir die Intel (i5, i7) Mac Minis nicht mit dem M1 vergleichen sollten.

    Unser Rat, testet erst Eure SW mit dem M1 bevor Ihr Euch zu einem Kauf entschliesst und dann evtl. enttäuscht seid. Wer natürlich die neuen Libs verwenden möchte/muss, der ist auf den M1 angewiesen. Lt. Support wird es diese nicht für Intel-Systeme geben.
  • Hm, also mit Xcode ist ein Build auf dem Mac Mini M1 doppelt so schnell wie auf einem Mac Book Pro mit i7 Quad Core.

    Kannst Du mal den Source Code von dem Testprogramm zur Verfügung stellen?

    Evtl. wird darin etwas verwendet, was auf einer Intel CPU schneller als mit einem Apple Silicon SOC ausgeführt wird. :/

    Hast Du die Test App als native App für Apple Silicon oder in Rosetta auf dem Mac Mini M1 ausgeführt?
  • MCDan schrieb:

    Hm, also mit Xcode ist ein Build auf dem Mac Mini M1 doppelt so schnell wie auf einem Mac Book Pro mit i7 Quad Core.

    Kannst Du mal den Source Code von dem Testprogramm zur Verfügung stellen?

    Evtl. wird darin etwas verwendet, was auf einer Intel CPU schneller als mit einem Apple Silicon SOC ausgeführt wird. :/

    Hast Du die Test App als native App für Apple Silicon oder in Rosetta auf dem Mac Mini M1 ausgeführt?
    @MCDan:
    Deine erste Aussage irritiert mich, da wie oben mitgeteilt wir dies nicht bestätigen können. Aber nichts ist unmöglich, es kann durchaus an unseren Testprogrammen liegen.

    Wir haben diese nun nicht explizit auf den M1 angepasst (neues Projekt angelegt und die Sourcen kopiert). Es kann aus diesem Grund durchaus sein, dass wir da etwas im Code haben, dass dieses Verhalten auslöst. Wenn da etwas enthalten sein sollte, dass die Geschwindigkeit drosseln sollte, müsste dies doch der Compiler mitteilen, oder liege ich da falsch? ?(

    Die Test Apps selbst, wurden als native für den Silicon ausgeführt - sonst würden wir ja keine vergleichbaren Werte erhalten. 8) Die Sourcen sind nicht von mir, aus diesem Grund kann ich Dir diese hier nicht zur Verfügung stellen. Ich frage mal nach, evtl. kann ich Dir diese per Mail zukommen lassen.
  • @OSXDev

    - Wie lange dauert denn euer Primzahlen-Test? - Frage nur, weil es Unterschiede geben kann, ob etwas 1s oder 4min dauert.
    - Selbstverständlich habt Ihr ein Produktion-Build benützt und nicht ein Debug-Build. Also mit all den Optimierungen und so was dabei angeschaltet ist.
    - Mit einem anderen Benchmark euer Ergebnis verglichen?
    - Das mit den Ansprechverhalten macht mich etwas stutzig. Habe das anders in YouTube-Videos gesehen bzw. in Erinnerung. Aber vllt. hängt das auch vom Programm ab und ob man es das zweite Mal öffnet oder das erste Mal. Vllt. wurde auch Mogelsoftware eingebaut. Wer weiß?
  • manoh schrieb:

    @OSXDev

    - Wie lange dauert denn euer Primzahlen-Test? - Frage nur, weil es Unterschiede geben kann, ob etwas 1s oder 4min dauert.
    - Selbstverständlich habt Ihr ein Produktion-Build benützt und nicht ein Debug-Build. Also mit all den Optimierungen und so was dabei angeschaltet ist.
    - Mit einem anderen Benchmark euer Ergebnis verglichen?
    - Das mit den Ansprechverhalten macht mich etwas stutzig. Habe das anders in YouTube-Videos gesehen bzw. in Erinnerung. Aber vllt. hängt das auch vom Programm ab und ob man es das zweite Mal öffnet oder das erste Mal. Vllt. wurde auch Mogelsoftware eingebaut. Wer weiß?
    @manoh:
    zu 1.) Die Frage ist eindeutig, die Ausführung danach irritiert mich. ?( Die Aussagen bzgl. der Rechendauer entnehmen wir den tatsächlich benötigten Threads-/CPU-Zeiten.
    zu 2.) Davon bin ich bis immer ausgegangen. Aber man lernt ja nie aus. :D
    zu 3.) Was meinst mit anderen Benchmark und unseren Ergebnissen? Wie soll das gehen? Evtl. andere Test Apps, welche die gleiche Berechnungen durchführen und diese Ergebnisse mit unseren vergleichen. Meinst Du dies, dass haben wir nicht. Da wir die Programme auf beiden System kompilieren und die so gewonnen Ergebnisse mit einander verglichen haben.
    zu 4.) Nun ja, da müssen wir nicht spekulieren, dies ist allen Testern bei uns aufgefallen.

    Ergänzung zu 4: Wir haben tatsächlich unterschiedliche OS x, xCode Build Versionen auf den Systemen. Wir werden die Systeme aktualisieren und dann nochmals prüfen ob sich das Ansprechverhalten bzw. die Berechnungsdauern ändern.
  • AppleDeveloper schrieb:

    @OSXDev komisch. Auch ich kann das Ergebnis von MacDan bestätigen. M1 läuft heftig schnell. Auch jegliche Programme.

    Habt ihr da irgendwas konfiguriert, was so viel Leistung braucht? Spotlight? Viren-Scanner?
    @AppleDeveloper: Nein haben wir nicht. Diese System sind identisch konfiguriert. Wir mussten jedoch feststellen, dass wir unterschiedliche Build Versionen auf den Systemen (M1/Intel) nutzen. Wir aktualisieren nun gerade OS X und xCode auf beiden Systemen und führen die Berechnungen dann nochmals durch.
  • OSXDev schrieb:

    zu 3.) Was meinst mit anderen Benchmark und unseren Ergebnissen?
    Es gibt Geekbench, Cinebench usw. Da das schon viele andere gemacht haben, bekommt man ja Vergleichswerte und hat auch gewisse Erwartungen an den eigenen Test.


    OSXDev schrieb:

    zu 1.) Die Frage ist eindeutig, die Ausführung danach irritiert mich. Die Aussagen bzgl. der Rechendauer entnehmen wir den tatsächlich benötigten Threads-/CPU-Zeiten.
    zu 2.) Davon bin ich bis immer ausgegangen. Aber man lernt ja nie aus.
    Ich würde ja gar nicht gleich einen Multithread-Test schreiben. Einfach ein Thread, der Test dauert so lange, dass die CPU ins Schwitzen kommt und runtergedreht wird. Mittels time, time ./my-test, kann man dann den Test starten. Und dann auch hoffen, dass der ein schnellen Kern benützt.

    Multithread-Test ist schwieriger zu programmieren. Vor allem überprüfen, dass ständig alle Kerne ausgelastet sind. Im Allgemeinen würde ich ein Kommandozeilen-Tool in C programmieren und nicht in Swift.

    PS: Es schreibt sich Xcode. Schon immer.
  • Ich habe hier ein 2016er 13" MBP (no Touchbar) und ein M1 MBP mit gleichem RAM, macOS- / Xcode-Versionen und kann morgen einmal den Build eines Projektes stoppen: macOS-App, Spotlight- und Quick-Look-Plugin zzgl. drei Automator-Actions.

    Was interessiert auf dem M1: Nativer Build?

    Mattes

    P.S.: Was ich subjektiv wahrnehme: Native Apps starten schneller, fühlen sich "snappy" an, die Akkulaufzeit ist super und meine Beine werden beim Coden mit vielen Builds nicht mehr so warm :) ... und ja, ein paar neue Bugs (unmotivierer Screensaver, TC zeigt falschen freien Speicher, Menüzeile reagiert nicht, ...).
    Diese Seite bleibt aus technischen Gründen unbedruckt.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von MyMattes ()

  • Mein Problem unter Big Sur ist, dass ich nicht mehr meine SD-Karten formatieren kann. Die Karte aus der Kamera wird ordentlich erkannt, aber dann die SD-Karte aus dem Raspi dafür nicht. Erwarten würde ich, dass das Gerät (Kartenleser) in der Disk Utility App (Festplattendienstprogramm) auftaucht und ich die komplette Karte löschen und umformatieren kann. Geht nimmer, oder ich stelle mich einfach zu blöd an.
  • Updates sind durch. Es zeigt sich nun unter Big Sur, dass die Apps agiler reagieren, also kein so großer Unterschied mehr zwischen M1 und Intel.

    Die Test Apps haben wir nun hinsichtlich der Threads so abgestimmt, dass diese nur vier Kerne nutzen. Der M1 nutzt zu diesem Zweck automatisch die vier „schnelleren“ Kerne. Ist interessant zu sehen wie die CPU diese Umverteilung durchführt, zumal direkt nach dem Start erst einmal die „langsameren“ Kerne genutzt werden. Diesem Umstand geschuldet, haben wir die durchzuführenden Berechnungen erweitert. Auf dem Intel Mini werden diese auf die ungerade Kernzahlen - also 1,3,5,7 - verteilt. Ergo die Werte sind ähnlich, aber die Intelvariante des Mac Mini liefert mit einem i7 die besseren Werte.

    @MyMattes: Auf dem M1 spielt es eine Rolle, ob ich auf diesem selbst mit Xcode den Code kompiliere oder die App eines Intel Mac laufen lasse. Letztere laufen auf einer Zwischenschicht Rosetta2, welche erst einmal den Intel-Code übersetzt bevor dieser zur Ausführung kommt.

    @manoh: Schau mal ob Du Dir erst einmal die vollständigen Schreibrechte erteilen musst. Im Bereich Sicherheit kann dies erteilt werden. Wir hatten diese Probleme mit einer SD-Karte unserer Nikon Kamera.
  • @OSXDev
    Wie bereits geschrieben, dass manche Karten gar nicht auftauchen. Das bedeutet, das kein Device, z.B. (r)disk2, unter /dev angelegt worden ist. Die Kernelmeldung bei erfolgreichen Anlegen eines Devices bzw. Fehlermeldung, habe ich noch nicht gefunden (Da noch nicht wirklich nachgeguckt).

    So ist das mit den Tests/Benchmarks. Die sagen nur aus, wie gut man in diesen Test/Benchmark ist. Wie man das deuten soll, das ist eine andere Frage.
  • OSXDev schrieb:

    @MyMattes: Auf dem M1 spielt es eine Rolle, ob ich auf diesem selbst mit Xcode den Code kompiliere oder die App eines Intel Mac laufen lasse. Letztere laufen auf einer Zwischenschicht Rosetta2, welche erst einmal den Intel-Code übersetzt bevor dieser zur Ausführung kommt.
    Das war mir schon klar :)

    Meine Frage bezog sich mehr auf einen (für mich) praxisnahen Vergleich: Irgendwelche Testprogramme interessieren mich eigentlich weniger als Aufgaben meines Alltags. Ich habe daher einmal eines meiner Projekte auf beiden Systemen kompiliert / gelinkt und die Zeiten - allerdings nur dilettantisch - gestoppt (Stoppuhr von <Cmd> + "b" bis zur Meldung "Build succeeded"). Es wurde das gleiche Projekt nach einem "Clean Build Folder" übersetzt und gelinkt: Eine macOS-App, je ein Spotlight- und Quick-Look-Plugin, drei Automator-Actions.

    Beide Systeme sind MacBook Pros mit 16 GB RAM, macOS 11.1 "Big Sur" mit Xcode v12.3 (12C33).
    • MacBook Pro 13" (2016), no Touchbar, Prozessor Intel i5 (2 GHz Dual Core): 38,8 Sekunden
    • MacBook Pro 13" (2020), Prozessor M1
      • ARM-Build: 10,9 Sekunden
      • Intel-Build: 10,3 Sekunden
    Ja, das ist nicht wirklich wissenschaftlich und das Intel-MBP schon etwas angestaubt, aber für mich im Alltag relevant und in Verbindung mit der o. g. Batterielaufzeit und geringeren Erwärmung ein klares Plus für den M1-Prozessor ... auch in der ersten Prozessorfamilie. Schade nur, dass ich zum Testen mit alten macOS-Versionen weiterhin das Intel-MBP als VMware-Host benötige...

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von MyMattes ()