Es wirkt nicht so, als würden gescheiterte CEOs tatsächlich große Einbußen erleiden, wenn sie ihre Karriere einfach bei einem anderen Unternehmen fortsetzen. Das eigentliche Risiko tragen vielmehr die Angestellten, die sich verbissen an der Umsetzung des gescheiterten Geschäfts festhalten mussten und dann bei der Auflösung ihrer Abteilung auf eine Weise die Verantwortung tragen, die ihr Leben bedroht.

 

Sind CEO und Großaktionär nicht ohnehin nicht immer dasselbe? Welches Risiko eingeht ein angestellter professioneller CEO, dem man etwas wegnehmen könnte?

 

Theoretisch sollten auf .NET Standard 2.0 ausgerichtete NuGet-Pakete auch in einer Unity-Umgebung geladen und verwendet werden können … aber offenbar gibt es dabei doch einige Unannehmlichkeiten.

https://learn.microsoft.com/ko-kr/dotnet/…

 

Bei großen Projekten beeinträchtigt die Editor-Performance die Developer Experience erheblich, daher ist auch die Editor-Performance wichtig. Das Starten des Editors ist langsam, der Asset-Import ist langsam, und auch die Schleife aus Debugging/Tests ist langsam ...

 

Ich weiß nicht, warum es immer mehr von diesen hingeworfenen, substanzlosen Unsinnsbeiträgen nach dem Motto „wenn nicht, dann eben nicht“ gibt. Es scheint ein globales Phänomen zu sein, haha.

Der CEO ist die einzige Person im Unternehmen, die aktiv Risiken auf sich nimmt. Es geht nicht um ein kleines Risiko auf dem Niveau, vielleicht kein Gehalt zu bekommen. Ein CEO trägt das Risiko, sogar alles zu verlieren, was er besitzt. Genau dieser Punkt ist der wichtigste. Wenn AI auch dieses Risiko übernehmen könnte, dann könnte man über dieses Thema noch einmal sprechen.

 

Es wäre schön, wenn auch NuGet-Kompatibilität hinzugefügt würde (oder liegt das daran, dass ich mich mit Unity nicht gut auskenne?)

 

Ich frage mich, wer die Verantwortung für die Entscheidungen eines AI-CEO tragen würde.

 
cronex 2025-12-30 | übergeordneter Kommentar | in: Setze immer auf Text (2014) (graydon2.dreamwidth.org)

Es stimmt, dass Text wirklich ein gutes und sehr wichtiges Ausdrucksmittel ist, aber …
Man kann eben nicht alles als Text speichern.
Text ist letztlich eine komprimierte Ausdrucksform. Was wir mit unseren fünf Sinnen wahrnehmen können (Sehen, Hören, Tasten, Schmecken, Riechen), wird in eine gesellschaftlich vereinbarte Form komprimiert und so ausgedrückt.
Wenn es jedoch keine Informationen über das ursprüngliche Objekt gibt, auf das sich das bezieht, verliert dieser Text seinen Sinn, selbst wenn man die Daten noch so sehr in Textform speichert, sobald spätere Menschen dieses ursprüngliche Objekt nicht mehr kennen.
Wir wissen zwar, was eine Kassette ist, aber wenn man Kindern, die erst vor Kurzem geboren wurden, nur das Wort „Kassette“ zeigt und sie fragt, was das ist, wie viele könnten wohl noch richtig antworten? Selbst wenn man Form, Funktion und Funktionsweise einer Kassette noch so ausführlich beschreibt: Könnte man in einigen tausend Jahren allein anhand dieses Textes eine Kassette wirklich perfekt rekonstruieren?
In solchen Fällen können ein paar Fotos der Kassette, technische Zeichnungen oder einige Minuten Video, in denen man sieht, wie eine Kassette benutzt wird, viel nützlicher sein.

 

Und ich fände es gut, wenn auch berücksichtigt würde, dass ab .NET 10 das Problem, das sie früher mit IL2CPP lösen wollten, zwar in eine andere Richtung entwickelt, aber dennoch präzise adressiert wird (Native AOT).

Natürlich bleibt die Einschränkung, dass dabei kein zwischendurch bearbeitbarer C++-Code erzeugt wird, aber letztlich hat sich die Erzeugung nativer Binärdateien ohne Just-in-Time von .NET 8 ausgehend bis .NET 10 weiter deutlich ausgereift.

Deshalb halte ich es für keine gute Entscheidung von Unity, die Modernisierung hin zu CoreCLR weiter aufzuschieben. Oder vielleicht wäre sogar ein vollständiger Wechsel zu einer ganz anderen Sprache oder Grundlage die sinnvollere Option!

 

Zum Jahresende … vielleicht waren GitHub-Stars ja Teil des KPI von irgendjemandem.
Ein Fall, in dem Goodharts Gesetz greift, aber aus Sicht von Verantwortlichen gibt es kaum etwas Bequemeres, als mit Zahlen zu steuern …

 

> Unity hat weder die Mittel noch den großen Willen, in die Performance von Mono zu investieren.

Dem stimme ich ebenfalls voll und ganz zu...

 

Manus – ein universeller KI-Agent, der Denken und Handeln verbindet
In den Kommentaren auf Hacker News fällt die Bewertung der Übernahme offenbar nicht besonders gut aus.

 

Auf einer Plattform wie GitHub dürften Stars ein nicht ganz unerheblicher Faktor sein. Hat GitHub kein Interesse an der Erkennung von Missbrauch? Sogar bei GeekNews wird so etwas sofort markiert.

 

Wenn man es über die Feiertags-API der Regierung abfragt, wird Weihnachten dort als 기독탄신일 angezeigt. Ich glaube, das ist die offizielle Bezeichnung.

 

Ein weiterer Grund, warum Mono unbedingt mit CoreCLR modernisiert werden muss, ist meiner Meinung nach, dass Unity weder besonders die Möglichkeiten noch den Willen haben dürfte, in Performance-Verbesserungen für Mono zu investieren. Ich denke, es ist richtig, die Altlasten aus der Zeit des .NET Frameworks so schnell wie möglich aufzuräumen. :-D

 

Stimmt schon, aber ich verstehe nicht so recht, warum man unbedingt die Editor-Performance vergleichen muss ... Man hätte zumindest einen Debug-Build zum Vergleich heranziehen können, oder? Oder auch nicht — hätte das die Aussagekraft am Ende noch weiter geschwächt? Andererseits wirken sowohl IL2CPP als auch Mono gleichermaßen wie veraltete Technologien.

 

Zynismus ist sicherlich nötig.
Sollten wir Bereiche wie Code-Reviews inzwischen nicht zunehmend an AI übergeben?
Schließlich sind das Talente, die gut für Zynismus geeignet sind.

 

Hammock-driven Development bedeutet ... der Begriff stammt aus einem Vortrag von Rich Hickey. Es ist eine Art zu entwickeln, bei der man die tiefen Randbedingungen klar formuliert, sie im Unterbewusstsein wirken lässt und dabei entwirft und verifiziert. Rich Hickey selbst sagt, dass sich Design nicht durch TDD oder komplexe Typsysteme ersetzen lässt.

https://secondb.ai/summary/11593/?tab=my

Unter den Entwicklern, die LLMs nutzen, scheinen diejenigen, die auf Rich Hickeys Gedanken zur Einfachheit (Simple Made Easy) achten, Ähnliches zu sagen. Man könnte sagen, dass es Spec-Driven ähnlich ist. Aber selbst um LLMs besser zu nutzen, wäre es vielleicht gut, auch auf die Unterschiede zu achten.

https://secondb.ai/summary/11587/?tab=all

 

Es ist wirklich faszinierend, dass sich moderne Technologie auf so alter Hardware betreiben lässt.

Wenn in Zukunft AGI erscheint: Könnte man sie dann ausführen, wenn man die gesamte derzeit auf der Erde verfügbare Rechenleistung bündelt?

 

Ich gehöre zum Wissenschafts- und Technologieausschuss der Grünen. Da dachte ich erst, Clojure-Entwickler ticken wohl ähnlich wie die Grünen. Dann kam mir aber der Gedanke, ob man nicht umgekehrt gerade wegen Clojure-Entwickler zum Grünen-Mitglied wird. ;)