Windows mit Linux-Kernel? Realistisch oder Phantasterei? https://www.heise.de/news/Eric-Raymond-Windows-wird-irgendwann-durch-Linux-Unterbau-ersetzt-4916104.html
Der Unterbau spielt doch heute überhaupt keine Rolle mehr. Mit einer Weiterentwicklung dessen kann man keinen Blumentopf mehr gewinnen. Was zählt ist einzig und allein die Oberfläche. Also bei der Hardware das Gehäusedesign - Apple hat das schon früh herausgefunden. Bei der Software hippe Oberflächen mit wischen usw. Von daher - wenn man beim Unterbau auf kostenlos verfügbare Systeme zurückgreift und seine Ressourcen für die Oberflächenentwicklung verwendet ist das nur folgerichtig.
zulu schrieb: > Windows mit Linux-Kernel? Realistisch oder Phantasterei? Das finde ich gar nicht so weit her geholt. Ein Grund könnte sein, Windows auch auf anderen Plattformen laufen zu lassen. So z.B. auf ARM Prozessoren, genau hier tut sich Windows schwer, auch wenn es auf dem Windows Phone schon recht Gut funktioniert hat.
zulu schrieb: > Realistisch oder Phantasterei? Jedenfalls irre innovativ. Apple macht das erst seit 2000 mit Darwin (auch ein UNIX).
zulu schrieb: > Windows mit Linux-Kernel? Realistisch oder Phantasterei? Was ist ein Kernel? Also: Wenn Windwos genau so funktioniert wie immer.... Dann ist mir der Kern egal...
Anarchist schrieb: > Was zählt ist einzig und allein die Oberfläche. Diesbezüglich ist die Windows-Usability ziemlich schlecht. Viele Grundfunktionen fehlen oder lassen sich nur sehr umständlich einstellen. Man nenne da nur mouse-over-aktivität bei sich überlappenden Fenstern. Bei Linux kann man immerhin die GUI einfach austauschen.
zulu schrieb: > Windows mit Linux-Kernel? Realistisch oder Phantasterei? Technisch denkbar, mit WINE & Co. laufen Windows-Binaries ja schon länger unter Linux, und zwar nicht als Emulation, sondern als (relativ) kompatible API-Nachbildung. Aber die Firmenpolitik wird wohl erstmal weiter Windows 10 verfolgen, denn nicht nur "Cloud"-Kram ist in Mode, sondern auch das Einsammeln von Daten. Nick M. schrieb: > Jedenfalls irre innovativ. > Apple macht das erst seit 2000 mit Darwin (auch ein UNIX). Was macht Apple seit 2000 Innovatives? Windows auf einem Unix-Kernel? Nö. GUI auf einem Unix-Kernel? Ja, war aber da schon ein alter Hut. MacOS-9-Anwendungen auf einem Unix-Kernel? Naja, als Emulation und von vornherein nicht für die Ewigkeit gedacht. Aber mir wollte auch schon ein Apple-Lemming erzählen, dass Apple der erste Anbieter von 64-Bit-Workstations gewesen wäre.
OliTV schrieb: > Ein Grund könnte sein, Windows auch auf anderen Plattformen laufen zu > lassen. > So z.B. auf ARM Prozessoren, genau hier tut sich Windows schwer, auch > wenn es auf dem Windows Phone schon recht Gut funktioniert hat. Unsinn. Windows (insbesondere der Kernel, aber auch das allermeiste von dem, was Windows ansonsten ausmacht) läuft auf ARM völlig problemlos. Wenn es (auch) für ARM kompiliert wurde, was im Fall von Windows Phone passiert ist. Was nicht läuft, sind halt Windows-Anwendungen, die nicht auf ARM portiert sind und die nicht über den Store vertrieben wurden. Deswegen ist Windows Phone baden gegangen. Die User wollten genau diese Anwendungen und nicht den Scheiß, der den Weg in den Store gefunden hat...
c-hater schrieb: > Deswegen ist Windows Phone baden gegangen. Die User wollten genau diese > Anwendungen und nicht den Scheiß, der den Weg in den Store gefunden > hat... Ach ja! Und Android oder iOS sind nicht auf den jeweiligen Store angewiesen? Eine i386, AMD64 Anwendung kann nicht einfach neu kompiliert werden und Gut ist es.
zulu schrieb: > Anarchist schrieb: >> Was zählt ist einzig und allein die Oberfläche. > > Diesbezüglich ist die Windows-Usability ziemlich schlecht. Viele > Grundfunktionen fehlen oder lassen sich nur sehr umständlich einstellen. > Man nenne da nur mouse-over-aktivität bei sich überlappenden Fenstern. > Bei Linux kann man immerhin die GUI einfach austauschen. Linux hat kein GUI. Linux, richtig GNU/Linux ist der Kernel. 11!!ölf UJnd der regelt sowas
PhilCol schrieb: > c-hater schrieb: >> Deswegen ist Windows Phone baden gegangen. Die User wollten genau diese >> Anwendungen und nicht den Scheiß, der den Weg in den Store gefunden >> hat... > > Ach ja! > Und Android oder iOS sind nicht auf den jeweiligen Store angewiesen? > > Eine i386, AMD64 Anwendung kann nicht einfach neu kompiliert werden und > Gut ist es. Android ist auf keinen Store angewieses. iOS auch nicht nach Jailbreak. Nur weil Du etwas für eine Architekturs/OS kompilieren kannst, läuft es nicht unbedingt auch darauf. Weil Du es nihct installieren kannst, siehe apple
Anarchist schrieb: > Der Unterbau spielt doch heute überhaupt keine Rolle mehr. Mein Profiler ist anderer Meinung.
Warum eigentlich Linux? Warum nicht xyz-BSD? Die BSD-Lizenz wäre doch besser für sie. wie soll das sonst mit der GPL-Lizenz funktionieren? Werden sie ihren Quelcode zu allen Anwendungen veröffentlichen? (rethorische Frage) Mac benutzt ja auch BSD.
wie soll das gehen? schrieb: > wie soll das sonst mit der > GPL-Lizenz funktionieren? Werden sie ihren Quelcode zu allen > Anwendungen veröffentlichen? (rethorische Frage) Userspace Anwendungen sind vom Copyleft der GPL des Linux kernel codes ausgenommen.
wie soll das gehen? schrieb: > Warum eigentlich Linux? Warum nicht xyz-BSD? > > Die BSD-Lizenz wäre doch besser für sie. wie soll das sonst mit der > GPL-Lizenz funktionieren? Werden sie ihren Quelcode zu allen > Anwendungen veröffentlichen? (rethorische Frage) Wie macht das google? Android basiert ja auch auf Linux.
OliTV schrieb: > zulu schrieb: >> Windows mit Linux-Kernel? Realistisch oder Phantasterei? > > Das finde ich gar nicht so weit her geholt. > Ein Grund könnte sein, Windows auch auf anderen Plattformen laufen zu > lassen. > So z.B. auf ARM Prozessoren, genau hier tut sich Windows schwer, auch > wenn es auf dem Windows Phone schon recht Gut funktioniert hat. Der Windows NT Kernel tut sich hier gar nicht schwer, da der schon immer auf andere Plattformen portierbar war. Das Problem ist das Ökosystem, das auf x86 Prozessoren läuft. Man kriegt nämlich keine neuen Binaries von Windowsanwendungen für ARM Prozessoren. Deswegen gibt's auch in Zukunft keinen Grund, Windows auf ARM laufen zu lassen, MS tut das ja jetzt schon mit Windows RT und Co, aber mangels Software führt das zu nichts. Die Windowssoftwarewelt verlangt nach x86 CPUs und x86 Emulationen auf fremden Architekturen sind langsam.
Dann können wir gespannt sein, was hier bei rauskommt: https://www.heise.de/news/Windows-on-ARM-Testphase-fuer-x64-Emulation-startet-im-November-2020-4918453.html
Wenn das NTFS schneller würde, dann würde mir das schon reichen. Selbst das WSL kompiliert um Faktoren schneller, das ist schon signifikant. Auf welchem Prozessor ist eigentlich egal.
Nano schrieb: > Das Problem ist das Ökosystem, das auf x86 Prozessoren läuft. > Man kriegt nämlich keine neuen Binaries von Windowsanwendungen für ARM > Prozessoren. Das OS koennte ja einen Recompiler/Reassembler bereitstellen, der die 386er Binaries auf die entsprechende Plattform uebersetzt. Apple macht das wohl bei ihren neuen PCs mit "eigener" Architektur. Fuer ARM-Linux (oder RISC-V-Linux) waere das eigentlich auch interessant.
Sorry, das Thema war ja von Johannes im Link angesprochen.
Gab es nicht bereits so um 2001 den Versuch, ein LINDOWS auf Basis von WINE zu entwickeln? Hat sich m.W. im Sande verlaufen.
Maxe schrieb: > Fuer ARM-Linux (oder RISC-V-Linux) waere das eigentlich auch > interessant. Gibt es längst, qemu-user, läuft recht gut, aber nicht besonders schnell. Unter debian, einfach:
1 | apt-get install qemu-user-static |
Damit kann man dann von einem arm64, riscv64, powerpc, amd64, etc. rechner aus arm64, riscv64, powerpc, amd64, etc. Anwendungen ausführen. Alles ausser statische binaries sind damit aber etwas umständlich. Richtig nützlich wird's aber erst zusammen mit dem restlichen Userspace. z.B.
1 | debootstrap --arch=arm64 buster buster_amd64 |
2 | chroot buster_amd64 |
Und schon ist man in einer amd64 Umgebung. Funktioniert eigentlich alles einwandfrei. Wenn debian ihr Multiarch auf binaries ausweiten würde, und nicht nur für libraries, bräuchte man das chroot nicht mehr. Obwohl, eigentlich müsste das in den meisten fällen reichen, habs aber noch nicht ausprobiert. Ein aktuelles qemu-user+wine geht damit im moment leider gerade nicht mehr so rund wie auch schon, aber das wird schon wieder.
Johannes S. schrieb: > Wenn das NTFS schneller würde, dann würde mir das schon reichen. NTFS war immer schon schlimm. So schlimm, daß mittlerweile sogar Microsoft das anerkennt^Hen muß. WSL kann mittlerweile auch richtige Filesysteme. Fefe sieht das als Anhaltspunkt, daß Windows demnächst nur noch ein Emulations-Layer über dem Linux Kernel sein wird: https://blog.fefe.de/?ts=a19f3925
Johannes M. schrieb: > Dann können wir gespannt sein, was hier bei rauskommt Neu daran ist die Emulation von 64-Bit x86 Code. Die für 32-Bit x86 Code gibt es längst und wird z.B. beim Microsoft Surface Pro X eingesetzt.
:
Bearbeitet durch User
Nick M. schrieb: > zulu schrieb: >> Windows mit Linux-Kernel? Realistisch oder Phantasterei? > > Jedenfalls irre innovativ. > Apple macht das erst seit 2000 mit Darwin (auch ein UNIX). Apple nutzt den Linux-Kernel? Hmmm schrieb: > Aber die Firmenpolitik wird wohl erstmal weiter Windows 10 verfolgen, > denn nicht nur "Cloud"-Kram ist in Mode, sondern auch das Einsammeln von > Daten. Das hat ja nichts mit dem Kernel zu tun. Nutzerdaten sammeln könnten sie auf einem Linux-Kernel genauso gut wie auf einem Windows-Kernel. UnLinx schrieb: > Linux hat kein GUI. Linux, richtig GNU/Linux ist der Kernel. Nein, "GNU/Linux" ist nicht der Kernel. Der Kernel heißt nur Linux®. "GNU/Linux" ist die Bezeichnung, die Richard Stallman gerne für das komplette Betriebssystem hätte, weil typische Linux-basierte Betriebssysteme viele Komponenten enthalten, die von seinem GNU-System kommen. Denn ursprünglich wollte er ein Betriebssystem namens GNU rausbringen. Der Kernel hat noch gefehlt, und gerade da kam Linus Torvalds mit seinem Linux-Kernel um die Ecke, und der wurde verwendet. Sehr zum Ärger von Stallman wurde das Betriebssystem dann umgangssprachlich nicht als GNU, sondern als Linux bekannt. Stallman möchte da einfach sein "GNU" im Namen haben. Allerdings gibt es im System noch sehr viele Komponenten, die weder Teil des GNU-Projekts, noch von Linux sind, die man dann auch allen nennen müsste, um konsequent zu sein. Und dann wäre der Name für das Betriebssystem sehr sehr sehr lang. 🐧 DPA 🐧 schrieb: > wie soll das gehen? schrieb: >> wie soll das sonst mit der >> GPL-Lizenz funktionieren? Werden sie ihren Quelcode zu allen >> Anwendungen veröffentlichen? (rethorische Frage) > > Userspace Anwendungen sind vom Copyleft der GPL des Linux kernel codes > ausgenommen. Interessanter könnte es bei Treibern werden. Die dürfen zwar auch als closed-Source geschrieben werden, aber es gibt gewisse Einschränkungen. Nano schrieb: >> So z.B. auf ARM Prozessoren, genau hier tut sich Windows schwer, auch >> wenn es auf dem Windows Phone schon recht Gut funktioniert hat. > > Der Windows NT Kernel tut sich hier gar nicht schwer, da der schon immer > auf andere Plattformen portierbar war. Ja. Viele wissen wohl nicht mehr, dass Windows NT auch z.B. mal auf DEC Alpha (welches schon Anfang der 90er eine reine 64-Bit-Architektur war), MIPS und PowerPC lief. > Das Problem ist das Ökosystem, das auf x86 Prozessoren läuft. > Man kriegt nämlich keine neuen Binaries von Windowsanwendungen für ARM > Prozessoren. Deswegen gibt's auch in Zukunft keinen Grund, Windows auf > ARM laufen zu lassen, MS tut das ja jetzt schon mit Windows RT und Co, > aber mangels Software führt das zu nichts. Nur warum tut Microsoft nichts dagegen? Sie könnten doch wie Apple früher ihren Compiler/Linker so auslegen, dass er im Executable einfach den Code für beide Architekturen ablegt und je nach System den passenden Code lädt. Bei Apple heißt das "universal binary". https://de.wikipedia.org/wiki/Universal_Binary Johannes S. schrieb: > Wenn das NTFS schneller würde, dann würde mir das schon reichen. Selbst > das WSL kompiliert um Faktoren schneller, das ist schon signifikant. Auf > welchem Prozessor ist eigentlich egal. Liegt das tatsächlich an NTFS? Ich könnte mir auch vorstellen, dass es am fehlenden fork() und generell an der extrem langsamen Art liegt, wie Windows Prozesse startet. Axel S. schrieb: > NTFS war immer schon schlimm. So schlimm, daß mittlerweile sogar > Microsoft das anerkennt^Hen muß. WSL kann mittlerweile auch richtige > Filesysteme. Wie sieht es mit Netzwerk aus? Da ist Windows auch nicht gerade flott unterwegs. Funktioniert das mit WSL auch besser?
Rolf M. schrieb: > Liegt das tatsächlich an NTFS? Ich könnte mir auch vorstellen, dass es > am fehlenden fork() und generell an der extrem langsamen Art liegt, wie > Windows Prozesse startet. hier ist z.B. ein Benchmark: https://vxlabs.com/2019/12/06/wsl2-io-measurements/ Beim gcc fällt es eben auch extrem auf. Ich denke nicht das da viele Prozesse gestartet werden (wenn nicht gerade zigfach parallel kompiliert wird) und wirklich die File I/O reinhauen.
Rolf M. schrieb: > 🐧 DPA 🐧 schrieb: >> wie soll das gehen? schrieb: >>> wie soll das sonst mit der >>> GPL-Lizenz funktionieren? Werden sie ihren Quelcode zu allen >>> Anwendungen veröffentlichen? (rethorische Frage) >> >> Userspace Anwendungen sind vom Copyleft der GPL des Linux kernel codes >> ausgenommen. > > Interessanter könnte es bei Treibern werden. Die dürfen zwar auch als > closed-Source geschrieben werden, aber es gibt gewisse Einschränkungen. Ja, die GPL exports bei kernel Modulen sind sehr fragwürdig / umstritten. Nicht wenige sind der Meinung, dass die Nutzung von kernel Symbolen in nicht GPL kernel Modulen generell nicht zulässig sei. Ich persönlich glaube auch, dass Thorvalds Idee mit den GPL exports, um auch nicht GPL Module die nicht GPL exports brauchen zu ermöglichen, um dinge wie Nvidias proprietäre Treiber und Oracles inkompatibel lizenziertes ZFS offtree zu ermöglichen, gigantischer (il)legaler Bullshit ist.
🐧 DPA 🐧 schrieb: > Ich > persönlich glaube auch, dass Thorvalds Idee mit den GPL exports, um auch > nicht GPL Module die nicht GPL exports brauchen zu ermöglichen, um dinge > wie Nvidias proprietäre Treiber und Oracles inkompatibel lizenziertes > ZFS offtree zu ermöglichen, gigantischer (il)legaler Bullshit ist. Hmm, ich dachte, der Kernel-Teil der Nvidia-Treiber sei der Einfachheit halber auch GPL (die ganze Magie findet ja eh im X-Treiber, also im Userspace statt). Aber anscheinend stehen die Module, die zu dem Kernel-Treiber gehören, sogar unter verschiedenen Lizenzen:
1 | kwayk@tardis:/usr/src/nvidia-440.100$ grep LICENSE -r * |
2 | nvidia/nv-frontend.c:#if defined(MODULE_LICENSE) |
3 | nvidia/nv-frontend.c:MODULE_LICENSE("NVIDIA");
|
4 | nvidia-drm/nvidia-drm-linux.c:#if defined(MODULE_LICENSE) |
5 | nvidia-drm/nvidia-drm-linux.c: MODULE_LICENSE("MIT");
|
6 | nvidia-modeset/nvidia-modeset-linux.c:#if defined(MODULE_LICENSE) |
7 | nvidia-modeset/nvidia-modeset-linux.c: MODULE_LICENSE("NVIDIA");
|
8 | nvidia-uvm/uvm8.c:MODULE_LICENSE("Dual MIT/GPL");
|
Maxe schrieb: > Nano schrieb: >> Das Problem ist das Ökosystem, das auf x86 Prozessoren läuft. >> Man kriegt nämlich keine neuen Binaries von Windowsanwendungen für ARM >> Prozessoren. > Das OS koennte ja einen Recompiler/Reassembler bereitstellen, der die > 386er Binaries auf die entsprechende Plattform uebersetzt. Selbst wenn das technisch halbwegs sauber funktionieren würde, wäre es rechtlich nicht erlaubt. Das Urheberrecht verbietet meist das Dissassmeblieren für den nicht bestimmungsgemäßen Gebrauch. Und die bestimmungsgemäße Plattform ist eben ein x86 Rechner.
Rolf M. schrieb: > Nano schrieb: >> Das Problem ist das Ökosystem, das auf x86 Prozessoren läuft. >> Man kriegt nämlich keine neuen Binaries von Windowsanwendungen für ARM >> Prozessoren. Deswegen gibt's auch in Zukunft keinen Grund, Windows auf >> ARM laufen zu lassen, MS tut das ja jetzt schon mit Windows RT und Co, >> aber mangels Software führt das zu nichts. > > Nur warum tut Microsoft nichts dagegen? Sie könnten doch wie Apple > früher ihren Compiler/Linker so auslegen, dass er im Executable einfach > den Code für beide Architekturen ablegt und je nach System den passenden > Code lädt. Bei Apple heißt das "universal binary". > https://de.wikipedia.org/wiki/Universal_Binary Microsoft tut dagegen schon was. Das nennt sich .NET und die neue App Infrastruktur. Damit sind die Anwendungen dank .NET Laufzeitumgebung wie Java ohne Neucompilierung gut auf Windowssystemen, die alle benötigten zusätzlichen Libs haben, portabel. Daran haben die schon die letzten > 15 Jahre gearbeitet. Nur kriegst du die nativen gewachsenen C und C++ Anwendungen so nicht auf Windows für ARM. Universal Binaries haben den Nachteil, dass sie mehr Platz brauchen und den braucht Windows schon dafür, weil sie anders als bei Linux, gleich mehrere Versionen der gleichen Bibliothek zwecks Binärkompatibilität auf Anwendungsebene mitliefern. Das ist der Grund, warum unter Windows für gewöhnlich eine über 20 Jahre alte 32 Bit Anwendung noch auf einem aktuellen Windows läuft. Klar für Neuentwicklungen könnte man das so machen. Die Entwickler könnten auch zwei verschiedene Plattformen bedienen und ihren C und C++ Code jeweils für die entsprechende Plattform compilieren. Aber da die Nutzer Zuhause noch eine riesen Sammlung an Bestandssoftware haben, kaufen die trotzdem bevorzugt x86 Prozessoren. Das führt dazu, dass der Markt für Win auf ARM klein bleibt und weil das so ist, macht sich kein Entwickler die Mühe, auch noch ARM als Plattform zu supporten. Deswegen versucht Microsoft das in dem es einfach die Laufzeitumgebung abstrahiert. .NET Anwendungen sollten daher überall laufen und wenn die Verbreitung dann irgendwann groß genug ist, könnte man den Schwenk zu ARM dann forcieren. Im Prinzip arbeitet man ja daran. Aber für die alten nativen Anwendungen muss man trotzdem einen x86 Emulator bereitstellen. Auch das macht man, nur sind die eben grottenlangsam. Bis die schnell genug sind, vergehen noch ein paar Rechnergenerationen. Tja und dann gibt's da noch die immer neuen nativen C++ Anwendungen, die viel Performance schlucken und daher immer höchstens erst 20 Jahre später in der Emulation halbwegs akzeptabel laufen. Wir werden also noch eine ganze Weile mit Windows auf x86 bleiben.
Nano schrieb: > Selbst wenn das technisch halbwegs sauber funktionieren würde, wäre es > rechtlich nicht erlaubt. Das Urheberrecht verbietet meist das > Dissassmeblieren für den nicht bestimmungsgemäßen Gebrauch. > Und die bestimmungsgemäße Plattform ist eben ein x86 Rechner. Hast du dafür irgendwelche Referenzen? Ich habe das noch nie gehört und halte das für Unfug. Es gibt ein Haufen Software, die Bytecode in irgendwelchen anderen Bytecode übersetzt, z.B. qemu oder vmware, wenn sie andere Plattformen emulieren, Wine wenn es D3D Shader auf OpenGL umbaut, oder Spielekonsolen-Emulatoren wie Dolphin, der PPC-Bytecode in X86-Bytecode JITed. Man hört von gelegentlich rechtlichen Problemen bei diesen Projekten, da geht es aber immer um rechtmäßigen Erwerb und Vertrieb der Original-Binaries, nicht um die Emulation an sich.
Beitrag #6429793 wurde vom Autor gelöscht.
Binary translation ist ein alter Hut. Nur die Vorstellung, das wäre als Rückübersetzung in Quellcode und anschliessende Neuübersetzung zu verstehen, die ist daneben. Umgekehrt gab es das auch schon, also ARM zu x86 Umsetzung: Android Handys mit Intel Prozessor nutzten "Houdini", wenn ihnen nativer ARM Code zugemutet wurde.
:
Bearbeitet durch User
Sven B. schrieb: > Nano schrieb: >> Selbst wenn das technisch halbwegs sauber funktionieren würde, wäre es >> rechtlich nicht erlaubt. Das Urheberrecht verbietet meist das >> Dissassmeblieren für den nicht bestimmungsgemäßen Gebrauch. >> Und die bestimmungsgemäße Plattform ist eben ein x86 Rechner. > > Hast du dafür irgendwelche Referenzen? Ich habe das noch nie gehört und > halte das für Unfug. Du scheinst wohl das UrHG nie gelesen zu haben: § 69c Zustimmungsbedürftige Handlungen § 69d Ausnahmen von den zustimmungsbedürftigen Handlungen und § 69e Dekompilierung > Es gibt ein Haufen Software, die Bytecode in irgendwelchen anderen > Bytecode übersetzt, z.B. qemu oder vmware, wenn sie andere Plattformen > emulieren, Wine wenn es D3D Shader auf OpenGL umbaut, oder > Spielekonsolen-Emulatoren wie Dolphin, der PPC-Bytecode in X86-Bytecode > JITed. Man hört von gelegentlich rechtlichen Problemen bei diesen > Projekten, da geht es aber immer um rechtmäßigen Erwerb und Vertrieb der > Original-Binaries, nicht um die Emulation an sich. Hier geht es auch nicht um Emulation, sondern Maxe will die Programme dissassemblieren und dann daraus für die neue Architektur wieder native Programme erstellen. Das ist weit mehr, als nur eine Emulation.
(prx) A. K. schrieb: > Binary translation ist ein alter Hut. Nur die Vorstellung, das > wäre als > Rückübersetzung in Quellcode und anschliessende Neuübersetzung zu > verstehen, die ist daneben. So ist es. Das ist das nächste Problem.
Nano schrieb: > Du scheinst wohl das UrHG nie gelesen zu haben: > > § 69c Zustimmungsbedürftige Handlungen > § 69d Ausnahmen von den zustimmungsbedürftigen Handlungen > und > § 69e Dekompilierung Dekompilierung ist nicht Emulation oder Bytecode-Translation oder JIT Recompilation. Dekompilierung ist, wenn ich versuche, aus dem Bytecode wieder C++ zu machen. Davon redet hier keiner. Darüber hinaus gibt sich der von dir genannte Text doch jede erdenkliche Mühe, das Verbot "zum Zweck der Interopabilität" genau eben nicht auszusprechen, und genau um diesen Zweck geht es doch hier offensichtlich. -> Ich halte das immer noch für Nonsens.
Nano schrieb: > Hier geht es auch nicht um Emulation, sondern Maxe will die Programme > dissassemblieren und dann daraus für die neue Architektur wieder native > Programme erstellen. > Das ist weit mehr, als nur eine Emulation. Die Liste von Beispielen, die du von mir im Satz drüber zitiert hat, hat dafür doch sogar auch eines: Dolphin JIT-ed die PPC-Instruktionen in natives x86 während der Ausführung.
Mikroprogrammierte Prozessoren sind auch illegal, weil sie während der Programmausführung ohne Zutun des Benutzers Maschinencode in Mikrocode umsetzen. Jetzt muss ich mich mit dem Tippen auf meinem PC mit Intel-Prozessor aber beeilen, hinter mir hämmert schon die Polizei gegen die Tür ... ;-)
Rolf M. schrieb: > Hmmm schrieb: >> Aber die Firmenpolitik wird wohl erstmal weiter Windows 10 verfolgen, >> denn nicht nur "Cloud"-Kram ist in Mode, sondern auch das Einsammeln von >> Daten. > > Das hat ja nichts mit dem Kernel zu tun. Nutzerdaten sammeln könnten sie > auf einem Linux-Kernel genauso gut wie auf einem Windows-Kernel. Ich bezog mich auf die Aussage, dass man wegen der höheren Bedeutung des Azure-"Cloud"-Zeugs evtl. die Entwicklungskosten von Windows reduzieren will. Mit Windows 10 gibt es bereits ein fertiges Produkt, das ein Kaufargument liefert (weitestgehend kompatibel zu bestehenden Anwendungen, dürfte bei etwas auf Linux-Basis schlechter aussehen), sich in die tolle moderne "Cloud"-Welt integriert (sammelt Daten) und wohl auch deshalb immer noch halb verschenkt wird (Aktivierung mit Windows-7-Seriennummer).
Sven B. schrieb: > Nano schrieb: >> Du scheinst wohl das UrHG nie gelesen zu haben: >> >> § 69c Zustimmungsbedürftige Handlungen >> § 69d Ausnahmen von den zustimmungsbedürftigen Handlungen >> und >> § 69e Dekompilierung > > Dekompilierung ist nicht Emulation oder Bytecode-Translation oder JIT > Recompilation. Dekompilierung ist, wenn ich versuche, aus dem Bytecode > wieder C++ zu machen. Davon redet hier keiner. Doch, genau das hat Maxe gemeint. Lies sein Kommentar auf das ich oben geantwortet habe. Er schrieb: Maxe schrieb: > Nano schrieb: >> Das Problem ist das Ökosystem, das auf x86 Prozessoren läuft. >> Man kriegt nämlich keine neuen Binaries von Windowsanwendungen für ARM >> Prozessoren. > Das OS koennte ja einen Recompiler/Reassembler bereitstellen, der die > 386er Binaries auf die entsprechende Plattform uebersetzt. Maxe möchte also x86 Binärcode dissassemblieren und dann aus dem lesbaren x86 Assemblercode irgendwie ARM Binärcode erstellen oder eben über den Umweg über C Code und daraus dann aus dem C Code zurück zu ARM Assembler und dann ARM Binärcode. Es ist also genau anders herum, die Emulation und Bytecode-Translation oder JIT Recompilation, waren hier nie gemeint. Die sind gar nicht das Thema. Das hast erst du selber aufgemacht, weil du Maxe nicht verstanden hast. > Darüber hinaus gibt sich der von dir genannte Text doch jede erdenkliche > Mühe, das Verbot "zum Zweck der Interopabilität" genau eben *nicht* > auszusprechen, und genau um diesen Zweck geht es doch hier > offensichtlich. Bei Interopabilität geht es darum, dass du bspw. eine Schnittstelle wie das SMB Protokoll erforschen kannst, damit du eine eigene Implementierung schreiben kannst. D.h. du nimmst die Windowsbinaries, dekompilierst sie um das SMB Protokoll und dessen Funktionsweise zu erforschen und dann implementierst du, wie es die Samba Entwickler gemacht haben, einen eigene SMB Implementierung. Das deckt aber nicht ab, dass du ein bestehendes x86 Binary nimmst, dieses dissassemblierst, den Code an arm anpasst und dann daraus ein natives arm Binary machst. Das deckt das Urheberrecht nämlich nicht ab, dafür bräuchtest du die Zustimmung des Rechteinhabers bzw. darf nur er selber das machen.
Sven B. schrieb: > Nano schrieb: >> Hier geht es auch nicht um Emulation, sondern Maxe will die Programme >> dissassemblieren und dann daraus für die neue Architektur wieder native >> Programme erstellen. >> Das ist weit mehr, als nur eine Emulation. > > Die Liste von Beispielen, die du von mir im Satz drüber zitiert hat, hat > dafür doch sogar auch eines: Dolphin JIT-ed die PPC-Instruktionen in > natives x86 während der Ausführung. Das ist aber nicht bleibend, sondern eben nur zur Laufzeit.
Nano schrieb: > Maxe möchte also x86 Binärcode dissassemblieren und dann aus dem > lesbaren x86 Assemblercode irgendwie ARM Binärcode erstellen oder eben > über den Umweg über C Code und daraus dann aus dem C Code zurück zu ARM > Assembler und dann ARM Binärcode. Jo, aber das ist doch im Verständnis des normal denkenden Menschein keine "Dekompilierung"! Eine Dekompilierung ist etwas, wo das Ergebnis eine Hochsprache ist. Ist es hier nicht, das Ergebnis ist anderer Bytecode. Das ist Bytecode-Translation, was soll das sonst sein? Selbst wenn dazu zwischendrin eine C-Repräsentation erzeugt werden sollte (was ich ziemlich kurios fände und nicht glaube), ist das ein Implementierungsdetail, was rechtlich vermutlich nicht von Belang ist, da im Zweifel eh keiner versteht was das bedeutet. Die Intention hingegen ist ganz klar nicht den Code zu dekompilieren, sondern ihn auf einer anderen Plattform auszuführen.
Sven B. schrieb: > Nano schrieb: >> Maxe möchte also x86 Binärcode dissassemblieren und dann aus dem >> lesbaren x86 Assemblercode irgendwie ARM Binärcode erstellen oder eben >> über den Umweg über C Code und daraus dann aus dem C Code zurück zu ARM >> Assembler und dann ARM Binärcode. > > Jo, aber das ist doch im Verständnis des normal denkenden Menschein > keine "Dekompilierung"! Eine Dekompilierung ist etwas, wo das Ergebnis > eine Hochsprache ist. Ist es hier nicht, das Ergebnis ist anderer > Bytecode. Das ist Bytecode-Translation, was soll das sonst sein? Nun, Maxe hat aus dem Kontext ja erkennen lassen, was er möchte, auch wenn sein Begriff Dekompilierung sicher falsch gewählt war, aber als Antworter irgnoriert man das und geht darauf ein, was er aus dem Kontext eigentlich wissen will. Deswegen sagte ich ja auch dissassemblieren. Was er aus dem Kontext definitiv nicht meinte, war die Emulation von x86 Code, wie du es meinst. So viel ist klar. > Selbst wenn dazu zwischendrin eine C-Repräsentation erzeugt werden > sollte (was ich ziemlich kurios fände und nicht glaube), ist das ein > Implementierungsdetail, was rechtlich vermutlich nicht von Belang ist, > da im Zweifel eh keiner versteht was das bedeutet. Rechtlich interessant ist eigentlich nur, ob du die Daten umbearbeitest und neue daraus machst. Und da schon die Konvertierung eines PNG Bildes ins JPG Format eine Umkodierung verlangt und rechtlich ohne Zustimmung des Rechteinhabers nicht erlaubt ist, ja, kaum zu glauben, ist aber juristisch so, wird das bei der Konvertierung von x86 Code in ARM Code erst Recht nicht möglich sein. > Die Intention > hingegen ist ganz klar nicht den Code zu dekompilieren, sondern ihn auf > einer anderen Plattform auszuführen. Nein, die Intention ist native Binares zu erhalten. Das geht auch aus dem Kontext hervor, da ich vor seinem Kommentar ja schon auf die langsame Emulation hingewiesen habe und er dann deswegen native Binaries ins Spiel brachte um die Langsamkeit zu umgehen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.