Bisher hatte ich immer Macbooks mit Intel-Prozessor (i7, 32GB), da war das Aufsetzen einer Windows-Umgebung für Tests oder den Unterricht mit Virtualbox keine große Sache. Meine VMs booteten teilweise schneller als die vom Bildungsträger an die Kursteilnehmer übergebenen HP-Laptops ... Irgenwann muss man aber mit der Zeit gehen, also beschaffte ich mir ein gebrauchtes M2 14 Zoll Macbook. Sehr schön, leicht, flach, sehr schnell und auf MacOS-Seite keinerlei nachteilige Effekte hinsichtlich Anwendungen und des OS. Aber, o-weh, nicht bedacht, mit VirtualBox war es erstmal aus, die läuft nicht auf Apple-Silicon. Schnell fand ich jedoch die alternative Software "UTM". Allerdings war die Freude nur von kurzer Dauer, denn das zugrunde liegende QEMU kann in dieser Umgebung Intel-Prozessoren anscheinend nur sehr, sehr langsam emulieren. Ein installiertes Windows 11 war praktisch unbrauchbar, auch bei sehr viel gutem Willen und Geduld. Dann hab ich doch tatsächlich "Windows for ARM" entdeckt, es heruntergeladen und in die UTM installiert. Und was soll ich sagen? Es ist gefühlt genau so schnell wie auf einem echten Intel-PC. Auch optisch keinerlei Unterschied. Selbst die Software für Intel-Windows läuft ohne spürbaren (nicht gemessenen!) Geschwindigkeitsverlust. Anscheinend hat Microsoft den ARM-Intel-Emulator wirklich gut gemacht, man kann es tatsächlich benutzen! Ich bin ja richtig hin und weg ... :-)
Frank E. schrieb: > Dann hab ich doch tatsächlich "Windows for ARM" entdeckt, es > heruntergeladen und in die UTM installiert. Und was soll ich sagen? Es > ist gefühlt genau so schnell wie auf einem echten Intel-PC. Das Windows selbst ist auch nativer ARM-Code, da wird nichts emuliert. Frank E. schrieb: > Selbst die Software für Intel-Windows läuft ohne > spürbaren (nicht gemessenen!) Geschwindigkeitsverlust. Für x86- und x64-Code steckt ein JIT-Compiler drin, der beim Start ARM-Code daraus macht. Der erste Start dürfte deshalb etwas länger dauern, danach liegt der Code im Cache.
Hmmm schrieb: > Für x86- und x64-Code steckt ein JIT-Compiler drin, der beim Start > ARM-Code daraus macht. Damit dürfte alle Windows-Software mit HW-Kopierschutz schon mal aus dem Rennen sein, oder?
Ob S. schrieb: > Software mit HW-Kopierschutz Welche Wirkmechanismen meinst Du? USB-Dongles? Warum sollten die nicht funktionieren?
Ob S. schrieb: > Damit dürfte alle Windows-Software mit HW-Kopierschutz schon mal aus dem > Rennen sein, oder? Es wird bei allem schwierig, was spezielle Hardware braucht, denn die Emulation gibt es nur im Userland, Treiber müssen für ARM vorhanden sein.
Harald K. schrieb: > Welche Wirkmechanismen meinst Du? USB-Dongles? Ja. > Warum sollten die nicht funktionieren? Weil da Codeteile erst zur Laufzeit entschlüsselt werden, d.h., dass diese zur Laufzeit des JIT-Compilers noch garnicht in ausführbarer Form vorhanden sind und dementsprechend nicht von ihm "übersetzt" werden können.
Hmmm schrieb: > Es wird bei allem schwierig, was spezielle Hardware braucht, denn die > Emulation gibt es nur im Userland OK, daran hatte ich bei meiner Frage noch nichtmal gedacht. Diese Dongles erfordern ja i.d.R. auch noch Kernel-Treiber. Da nutzt ein "Durchreichen" des USB-Gerätes á la VirtualBox alleine noch garnix.
Ob S. schrieb: > Weil da Codeteile erst zur Laufzeit entschlüsselt werden, d.h., dass > diese zur Laufzeit des JIT-Compilers noch garnicht in ausführbarer Form > vorhanden sind und dementsprechend nicht von ihm "übersetzt" werden > können. OK, das ist ein Argument. Allerdings ist vorstellbar, daß derartiger Code dann halt ohne JIT ausgeführt wird, und dadurch halt langsamer läuft. Man wird es ausprobieren müssen, aber wer setzt schon freiwillig verdongelte Software ein? Mir müsste man mit wirklich sehr überzeigenden Argumenten kommen, die ich in meinen mehreren Jahrzehnten Berufserfahrung noch kein einziges Mal gehört habe.
Ob S. schrieb: > Damit dürfte alle Windows-Software mit HW-Kopierschutz schon mal aus dem > Rennen sein, oder? Reine Kopierschutzdongels werden in den allermeisten Fällen keine eigenen Hardwaretreiber brauchen da sie mit Standard CDC oder HMI Protokollen arbeiten. Wenn bestehen diese "Treiber" nur aus einer inf-Datei und der Rest ist schon im BS vorhanden.
Mit grausen erinnere ich mich an nicht funktionierende Drucker, die sich den Parallelport mit einem Dongle teilen mussten. Am zweiten und dritten Parallelport hingen oft weitere Dongles.
Unglaublich, sehe ich das richtig, Apple hat schon wieder den Prozessor gewechselt!? Habe erst kürzlich mitbekommen dass die von Motorola 68k auf Intel gewechselt haben... Sind die noch normal? Gruss Chregu
Christian M. schrieb: > Unglaublich, sehe ich das richtig, Apple hat schon wieder den Prozessor > gewechselt!? Vor 5 Jahren. Christian M. schrieb: > Habe erst kürzlich mitbekommen dass die von Motorola 68k auf Intel > gewechselt haben... Diesen Wechsel gab es nie. Erst von 68k auf PPC, dann von PPC auf x86. Christian M. schrieb: > Sind die noch normal? Im Vergleich zu Dir schon.
Jürgen schrieb: > Reine Kopierschutzdongels werden in den allermeisten Fällen keine > eigenen Hardwaretreiber brauchen da sie mit Standard CDC oder HMI > Protokollen arbeiten. Da kann ich sofort sagen, dass ich mindestens zwei Gegananzeigen kenne: -Datev -Altium Beides in unseren betrieblichen Abläufen nicht ganz unwichtige Software...
Das schöne an Datev ist, daß man das getrost dem Steuerberater überlassen kann. Soll der sich damit herumärgern, ist sein Job. Altium? Ja, das mag manch einer aus "Compliance"-Gründen noch benötigen. Das kann er dann halt nicht auf einem Macbook verwenden. KiCad läuft nativ unter macOS.
Harald K. schrieb: > Das schöne an Datev ist, daß man das getrost dem Steuerberater > überlassen kann. Soll der sich damit herumärgern, ist sein Job. Ab einer gewissen Betriebsgröße wirst du nicht umhinkommen, auch eigenes Personal mit Datev ausstatten zu müssen. Obwohl schon ein Steuerberaterbüro damit beschäftigt ist. > Altium? Ja, das mag manch einer aus "Compliance"-Gründen noch benötigen. Nicht nur aus "Compliance-Gründen"...
Alle Software-Hersteller, die unter den Mac-Useren eine relevante Clientel erblicken, erstellen ihre Produkte inzwischen so, dass sie auch unter MacOS laufen (Java, C#, C++, Xojo oder als WebApp). Beispiele: MSOffice, Adobe-Software für Grafiker und Layouter, Filemaker Pro Datenbanken, CorelDraw Suite u.v.a. Und die Hersteller der Compiler und IDEs folgen dann zwangsläufig dem Trend zu den neuen Prozessoren. Zu Beginn eines solchen Wechsels baute Apple bisher immer unter dem Codenamen "Rosetta"* jeweils einen JIT direkt ins System ein. Für eine Übergangszeit gibt es Mac-Apps auch als "universal", d.h. da ist sowohl ARM- als auch Intel-Code enthalten. Dann wurde das nach und nach in jeweils eigene Versionen aufgesplittet und über kurz oder lang werden die Apps mit Intel-Code wohl ganz wegfallen ... * benannt nach dem "rosetta stone", einem Felsen mit Inschriften in mehreren Sprachen, der für einen Durchburch bei der Entschlüsselung der ägyptischen Hieroglyphen sorgte.
:
Bearbeitet durch User
Ob S. schrieb: > Ab einer gewissen Betriebsgröße wirst du nicht umhinkommen, auch eigenes > Personal mit Datev ausstatten zu müssen. Aber auch dieses Personal wird es überleben können, den Datev-Kram auf einen nur dafür genutzten Windows-PC zu betreiben. Schon aus Gründen der Datenhygiene sollte das so sein; eine Notwendigkeit, ausgerechnet sowas auf einem Mac unter Windows for ARM laufen zu lassen, kann ich jetzt nicht erkennen. Wenn es ästhetische Gründe bei der Raumausstattung gibt: Der Windows-Rechner kann auch in einem 19"-Rack im Serverraum stecken und via RDP vom Mac aus bedient werden.
Ob S. schrieb: > Harald K. schrieb: >> USB-Dongles? > [...] >> Warum sollten die nicht funktionieren? > > Weil da Codeteile erst zur Laufzeit entschlüsselt werden, d.h., dass > diese zur Laufzeit des JIT-Compilers noch garnicht in ausführbarer Form > vorhanden sind und dementsprechend nicht von ihm "übersetzt" werden > können. Wann? "Zur Laufzeit des JIT-Compilers"? Wann ist die denn? :-)
Windowsspiele auf einer VR-Brille mit ARM-CPU: https://www.derstandard.at/story/3000000301013/valve-hat-womoeglich-die-zukunft-des-gamings-geknackt-und-sie-heisst-fex
Ein T. schrieb: > Wann? "Zur Laufzeit des JIT-Compilers"? Wann ist die denn? Wenn das Programm erstmalig vom Programmlader des Betriebssystems in den Speicher geladen wird - und bevor der Code dann tatsächlich ausgeführt wird. Wann denn sonst? Donnerstags, kurz bevor der Bus kommt?
Harald K. schrieb: > Wann denn sonst? Donnerstags, kurz bevor der Bus kommt? Ach, der will ja nur labern. Zum Ausprobieren, wie wohl https://github.com/dockur/windows-arm läuft, wäre der sich auch zu fein, ganz abgesehen von noch ganz anderen bewährten Möglichkeiten.
Harald K. schrieb: > Ein T. schrieb: >> Wann? "Zur Laufzeit des JIT-Compilers"? Wann ist die denn? > > Wenn das Programm erstmalig vom Programmlader des Betriebssystems in den > Speicher geladen wird - und bevor der Code dann tatsächlich ausgeführt > wird. Das denken viele (auch erfahrene) Entwickler, aber... es ist leider flashc. Ein JIT-Compiler kompiliert nur bestimmte Hotspots, meist häufig aufgerufene Funktionen und / oder häufig durchlaufene Schleifen. Um die Hotspots überhaupt zu identifizieren, wird nicht etwa der Code analysiert -- das würde ja ohnehin nichts nutzen und könnte auch einfach vom Interpreter (bzw. der VM) erledigt werden --, sondern es werden Statistiken zur Laufzeit gesammelt, und auf der Basis dieser Statistiken werden besonders häufig durchlaufende Teile des Code kompiliert und diese Teile durch die Kompilate ersetzt. Das bedeutet: es ist richtig, daß ein JIT-Compiler beim Start des Programms mit der Sammlung der besagten Laufzeitstatistiken beginnt. Die namensgebende Funktionalität des Just in Time Compilers, die Kompilation, erfolgt jedoch erst zur Laufzeit des Programms, also "just in time", und zwar anhand der konkret aufgerufenen Codepfade zur Laufzeit. Insofern macht der JIT-Compiler zunächst nur ein Profiling, um die heißen Pfade zu finden, also die Stellen, an denen sich die Kompilation überhaupt lohnt. Das bedeutet umgekehrt auch, daß Performancetests mit einem JIT-Compiler nur dann brauchbare Ergebnisse liefern, wenn die Aufrufpfade und Daten halbwegs denen entsprechen, die in der Realität erwartet werden. Ich zeige das einmal mit einem kleinen Beispiel mit dem Python-Interpreter Pypy3. Das Programm ist ein kleines Python-Programm mit dem (Micro-)Webframework Flask:
1 | #!/usr/bin/env pypy3 |
2 | from flask import Flask |
3 | |
4 | app = Flask(__name__) |
5 | |
6 | @app.route("/")
|
7 | def index(): return "huhu" |
8 | |
9 | if __name__ == '__main__': |
10 | app.run(host='0.0.0.0', port=5000, debug=True) |
Zunächst habe ich eine "Baseline" erzeugt, um die Ergebnisse zu beurteilen, und dazu den ab(1) "Apache Benchmark" des Apache httpd verwendet (unwichtige Teile habe ich hier einmal ausgelassen) und einen einzelnen Request gemessen:
1 | Time taken for tests: 0.022 seconds |
2 | Requests per second: 45.11 [#/sec] (mean) |
3 | Time per request: 22.170 [ms] (mean) |
4 | Time per request: 22.170 [ms] (mean, across all concurrent requests) |
5 | Transfer rate: 7.75 [Kbytes/sec] received |
Danach habe ich ab(1) 50.000 Requests mit einer Concurrency von 16 aufgerufen und die Ergebnisse aus wie ich hoffe verständlichen Gründen verworfen, und danach noch einmal den ab(1) mit einem einzelnen Request ausgeführt:
1 | Time taken for tests: 0.012 seconds |
2 | Requests per second: 85.61 [#/sec] (mean) |
3 | Time per request: 11.681 [ms] (mean) |
4 | Time per request: 11.681 [ms] (mean, across all concurrent requests) |
5 | Transfer rate: 14.71 [Kbytes/sec] received |
Du siehst, sogar in diesem einfachen Fall kann der JIT-Compiler die Laufzeit halbieren, wenn er die "heißen Pfade" im Code gefunden hat. Wobei die kleine Funktion "index()" sicherlich nicht kompiliert wird, sondern die (wesentlich aufwändigeren) Funktionen des in Flask eingebauten Webservers "Werkzeug". Was bedeutet das gerade Erläuterte nun für die Behauptung von "Ob S. (Firma: 1984now) (observer)" weiter oben: Ob S. schrieb: > Weil da Codeteile erst zur Laufzeit entschlüsselt werden, d.h., dass > diese zur Laufzeit des JIT-Compilers noch garnicht in ausführbarer Form > vorhanden sind und dementsprechend nicht von ihm "übersetzt" werden > können. Richtig: daß sie völliger Unsinn ist, weil der JIT-Compiler zur Laufzeit, eben "just in time" arbeitet, und deswegen auch seinen zur Laufzeit entschlüsselten Code (und vermutlich sogar die Entschlüsselung selbst) kompilieren kann, wenn dieser Code häufig genug durchlaufen wird. Und wenn nicht, dann spielt das eh keine Rolle -- nichtsdestotrotz wird ein JIT-Compiler die häufig durchlaufenen ("heißen") Pfade im Code finden und kompilieren. > Wann denn sonst? Donnerstags, kurz bevor der Bus kommt? Das kommt natürlich darauf an, ob Du Dein Programm am Donnerstag kurz vor Ankunft des Busses laufen läßt. Darauf habe ich allerdings keinen Einfluß.
Angehängte Dateien:
Rbx schrieb: > Ach, der will ja nur labern. Zum Ausprobieren, wie wohl > https://github.com/dockur/windows-arm läuft, wäre der sich auch zu fein, > ganz abgesehen von noch ganz anderen bewährten Möglichkeiten. Ach, zu fein eher nicht, allerdings... ich habe kein Windows und möchte auch keines haben, zudem mangelt es mir an einer ARM-Maschine (mit der Ausnahme einiger Raspberry Pi 1 bis 5, von denen ich jedoch annehme, daß ein Windows auch dann nicht darauf laufen würde, wenn ich eines hätte). Allerdings... update: der Docker Hub hat anscheinend ein X86-Image, das auch unter Linux zu laufen scheint... okay, zumindest lädt der Container ein Image von Microsoft Windows und ich bin gespannt, was danach passieren wird, siehe Anhang. Spannend, bisher war mein Kenntnisstand, daß Windows-Container nicht unter Linux lauffähig seien. Wenn das mittlerweile funktioniert, muß ich mir wohl ein Problem für diese Lösung suchen... hast Du eine Idee? :-) Update: jetzt "Installing Windows 44% complete"... ui.
Ein T. schrieb: > Wenn das > mittlerweile funktioniert, muß ich mir wohl ein Problem für diese Lösung > suchen... hast Du eine Idee? :-) > > Update: jetzt "Installing Windows 44% complete"... ui. Also wenn das fertig ist, könntest du ja ein Downgrading versuchen, auf eine 32/16 Bit Version. Oder einfach mal versuchen Python zu installieren, und vorzeigen, damit ich auch endlich mal weiß, wie man Python einigermaßen eindeutig auf Windows installiert. (ach so, und dann noch schauen, wie wohl Eclipse läuft, und wie fluffig sich das dann mit Python handlen ließe.) Fedora kommt jetzt dauernd mit Meldungen hinsichtlich der neuesten Version an. Viel besser als die Windowsgängelungen (auf Windows10 updaten) ist das hinsichtlich des Nerv-Statusses auch nicht. Was man noch versuchen könnte, wäre cygwin auf Windows 11 zu installieren. Weitere Hilfen wären vielleicht noch https://learn.microsoft.com/de-de/sysinternals/
Ein T. schrieb: > Update: jetzt "Installing Windows 44% complete"... ui. Okay, nicht zu fassen, Windows 11 läuft in einem Docker-Container unter Linux. Es ist ziemlich langsam und daher schwierig zu bedienen, allerdings ist dieser Laptop hier mit einem Intel i7-7820HQ und 32 GB RAM jetzt auch nicht unbedingt das Erste, was einem zum Thema "Performancewunder" einfallen würde. Jedenfalls sind sogar Youtube-Videos halbwegs (halbwegs!) flüssig möglich, jedoch scheint die Audioausgabe (noch?) nicht zu funktionieren. Am Ende läuft dieses Windows allerdings auf QEMU+KVM, also in einer virtuellen Maschine... Okay, mein Desktopsystem wird das schon aus Performancegründen nicht werden, aber trotzdem ist es spannend, daß es offensichtlich geht. Wenn ich also mal einen Anwendungsfall für Windows habe, der keiner hohen Performance bedarf, könnte das womöglich ein gangbarer Weg sein, auch wenn ich den Anwendungfall bislang noch nicht einmal am Horizont erblicken kann... egal, möglicherweise fällt mir ja künftig etwas ein oder jemand von Euch postet eine schöne Idee. Wie dem auch sei, danke für den Tipp und den Link, Rbx.
Rbx schrieb: > Also wenn das fertig ist, könntest du ja ein Downgrading versuchen, auf > eine 32/16 Bit Version. Öhm... ich habe nicht die geringste Ahnung, was und wie ich da machen sollte, denn -- wie ja schon ein paarmal gesagt -- ich habe keine Ahnung von Windows. Und um ehrlich zu sein fällt mir auch kein plausibler Grund ein, warum ich so etwas ausgerechnet in einer Frankenstein-Umgebung (Windows unter Docker unter QEMU/KVM unter Linux) ausprobieren wollen würde, sorry. Zumal ich kaum glaube daß das funktionieren wird, einerseits weil es mir an Windows-Kompetenz sehr deutlich mangelt, andererseits auch, weil Windows selbst schon nicht den Ruf hat, sonderlich transparent zu sein, und die ganzen Zwischenlayer solch ein Ansinnen sicherlich noch wesentlich verkomplizieren. > Oder einfach mal versuchen Python zu installieren, und vorzeigen, damit > ich auch endlich mal weiß, wie man Python einigermaßen eindeutig auf > Windows installiert. Nach allem, was ich bisher gesehen und eben selbst durchgeführt habe, ist das nicht besonders schwierig, allerdings: man muß sich entscheiden. Es existiert eine Python-Distribution namens Anaconda, die sich insbesondere an KI-Leute wendet und deswegen schon eine Menge der dafür nötigen Pakete installiert. In Anaconda sollte man Python-Pakete ausdrücklich nur mit dem darin enthaltenen Paketmanager "conda" installieren, sonst kann es Probleme geben. Ich persönlich empfehle allerdings ohnehin den ofiziellen Python-Installer von der offiziellen Python-Website [1], das darin enthaltene venv-Modul für die Erzeugung von Virtuellen Umgebungen, und den Python-Paketmanager "pip". Das Paket läßt sich einfach über einen normalen Windows-Installer installieren (ebendies habe ich eben gemacht und encodiere gerade ein Video davon), und vermutlich sollte man (wie ich) das Python-Executable in den Pfad (%PATH%) aufnehmen. Besonderheit aus meiner Erinnerung: die Dateinamenerweiterungen .pyw und .py werden bei der Installation mit Python verknüpft, und während .py-Dateien bei der Ausführung ein Kommandozeilenfenster mit der Ausgabe des Python-Programms öffnen, auch wenn es sich um grafische Programme mit Tkinter oder PyQt bzw. PySide handelt, wird das Kommandozeilenfenster bei Dateien mit der Dateinamenerweiterung .pyw nicht geöffnet, so daß das Programm sich mehr wie ein "richtiges GUI-Programm" anfühlt. [1] https://python.org/ > (ach so, und dann noch schauen, wie wohl Eclipse läuft, und wie fluffig > sich das dann mit Python handlen ließe.) Nunja, Eclipse habe ich als ziemlich fette Veranstaltung kennengelernt, das dürfte die knappen Ressourcen meines kleinen Schleppi sicherlich vollkommen überfordern. Zudem bin ich ja, wie Du vielleicht weißt, ohnehin kein großer Freund von IDEs und mit meinem Emacs sehr zufrieden, wobei sich beim Emacs streiten läßt, ob er ein Editor, eine IDE oder ein Betriebssystem ist. :-) > Fedora kommt jetzt dauernd mit Meldungen hinsichtlich der neuesten > Version an. Viel besser als die Windowsgängelungen (auf Windows10 > updaten) ist das hinsichtlich des Nerv-Statusses auch nicht. Die Meldungen lassen sich vermutlich irgendwo deaktivieren, aber ich bin auch in der Linux-Welt ziemlich wählerisch, und mache um Produkte von RedHat seit dem Desaster mit dem GCC-2.96 einen größtmöglichen Bogen. Ansonsten wäre meine Empfehlung, den Meldungen zu folgen und auf eine noch unterstützte Version von Fedora zu aktualisieren, möglicherweise könnte das ja auch Deine Probleme mit der Audioausgabe von Windows-Spielen unter Wine verbessern. Das Dumme ist ja, daß Entwickler irgendwann den Support für alte Versionen einstellen und dann meistens auch Supportanfragen für die alten Versionen mit einem gleichermaßen verständlichen wie lapidaren "aktualisiere doch erst einmal auf die aktuelle Version" beantworten. Vielleicht kannst Du ja ein paar Gigabyte von Deiner Festplatte freiräumen und darauf ein aktuelles Fedora oder gar eine *Ubuntu- oder Debian-Distribution ausprobieren? > Was man noch versuchen könnte, wäre cygwin auf Windows 11 zu > installieren. Öhm, warum denn Cygwin? Windows hat doch jetzt dieses Windows Subsystem for Linux oder WSL2 (wenngleich mir der Name etwas irreführend erscheint, denn dabei handelt es sich ja eher um ein Linux Subsystem for Windows... aber ok, das ist ja nicht mein Produkt). > Weitere Hilfen wären vielleicht noch > https://learn.microsoft.com/de-de/sysinternals/ Puh... okay, ich komme ja aus der Betriebssystemecke, aber Systeminternals... ist das nicht vielleicht mit Kanonen auf Spatzen geschossen? Ich meine, ich habe ja ein System (Kubuntu Linux), mit dem ich für meine Anwendungsfälle wunderbar zurecht komme, und von dem ich auch nicht ablassen möchte (außer vielleicht in Richtung Free- oder NetBSD, wenn mir unter Linux irgendwann einmal etwas zu sehr auf den Keks gehen sollte). Insofern kann ich für mich aktuell noch keinen echten Mehrwert darin sehen, mich ohne konkreten Anlaß tiefer in Windows einzuarbeiten, sorry... vielleicht in Zukunft.
Ein T. schrieb: > Öhm... ich habe nicht die geringste Ahnung, was und wie ich da machen > sollte, denn -- wie ja schon ein paarmal gesagt -- ich habe keine Ahnung > von Windows. War auch nur als Scherz gemeint. Eventuell wäre FreeDOS in der VM etwas erhellender für den Anfang ;) Ein T. schrieb: > Nunja, Eclipse habe ich als ziemlich fette Veranstaltung kennengelernt, Ja, ich auch - aber wenn Eclipse erstmal läuft (so nach einer halben Stunden vielleicht..) kann das durchaus interessant werden. Gelegentliches über den Tellerrand hinaussehen sollte nicht verschrecken, bei Windows läuft auch nicht alles Supi, und Programme ausprobieren gehört eigentlich zum Alltag - vor allem am Anfang. Ein T. schrieb: > Ansonsten wäre meine Empfehlung, den Meldungen zu folgen und auf eine > noch unterstützte Version von Fedora zu aktualisieren, möglicherweise > könnte das ja auch Deine Probleme mit der Audioausgabe von > Windows-Spielen unter Wine verbessern. Habe ich schon gemacht, bin gerade ganz zufrieden. Die nervigen Meldungen wollen aber F43 verklappen, und diesbezüglich habe ich vor allem mit Wine keine guten Erfahrungen gemacht. Im Moment habe ich in Skyrim z.B. Modabstürze, die typisch für das neue Fedora ist. Erfahrungsgemäß gehen diese CTDs zurück, wenn die Fedora-Version schon etwas älter ist. Also die allerneueste Version (hier F43) wäre allenfalls was zu Testzwecken, und wenn man Alternativen zum Ausprobieren hat. Ein T. schrieb: > ist das nicht vielleicht mit Kanonen auf Spatzen > geschossen? Je nachdem. Früher waren die Urprogramme recht praktisch um z.B Störenfriede zu finden, oder Eingriffsmöglichkeiten in Programme - aber damals gab es auch noch den Sourcecode dazu. Schadprogramme hatten diese Programme, oder das Know How darin auch genutzt, um z.B. Fake-Desktops zu erstellen. Ein T. schrieb: > mich ohne konkreten Anlaß tiefer in Windows > einzuarbeiten, sorry... vielleicht in Zukunft. Und das auch noch, wo viele Leute Windows schon den Rücken zugekehrt haben. Ein anderer Punkt sind noch die Vorinstallierungen oder eben auch VHS-Kurse - die wohl auch von MS gekauft wurden - oder weiß ich nicht. Volkshochschulen brauchen auch von irgendwoher Geld..
:
Bearbeitet durch User
Rbx schrieb: > VHS-Kurse - die wohl auch von MS gekauft wurden - oder weiß ich nicht. Überleg mal, was die meisten Arbeitgeber einsetzen und was ein VHS-Kunde deshalb am ehesten lernen will. Volkshochschulen haben überwiegend Mainstream-Angebote, da geht niemand hin, der als Unix-Admin arbeiten will.
Hmmm schrieb: > Überleg mal, was die meisten Arbeitgeber einsetzen und was ein VHS-Kunde > deshalb am ehesten lernen will. Volkshochschulen bieten häufig auch Kurse für Freizeitaktivitäten an, ein Freund von mir gibt dort beispielsweise Theoriekurse für den Segelschein. > Volkshochschulen haben überwiegend Mainstream-Angebote, da geht niemand > hin, der als Unix-Admin arbeiten will. Ich glaube, das ist eher der Punkt: die Leute kaufen einen Computer, da ist Windows drauf, deshalb wollen sie lernen, wie sie damit umgehen können. Und dennoch gibt es Volkshochschulen, die Linux-Schulungen anbieten, und einige Menschen nehmen offenbar sogar an solchen Kursen teil.
Ein T. schrieb: > Ich glaube, das ist eher der Punkt: die Leute kaufen einen Computer, da > ist Windows drauf, deshalb wollen sie lernen, wie sie damit umgehen > können. Ja. Es geht also überhaupt nicht darum, das OS zu verstehen oder gar zu beherrschen. Nur darum, es benutzen zu können. Sprich: Schluß ist i.d.R. da, wo irgendwas nicht so läuft, wie es laufen sollte. > Und dennoch gibt es Volkshochschulen, die Linux-Schulungen > anbieten, und einige Menschen nehmen offenbar sogar an solchen Kursen > teil. Kein Ahnung, was da dann vermittelt wird. Fakt ist jedenfalls, dass man bei Linux sehr viel häufiger auf Situationen stößt, die nicht mit ein paar Klicks irgendwo im GUI zu lösen sind. Und mehr kann man einem Standard-DAU einfach nicht abverlangen.
Ob S. schrieb: > Ein T. schrieb: >> Ich glaube, das ist eher der Punkt: die Leute kaufen einen Computer, da >> ist Windows drauf, deshalb wollen sie lernen, wie sie damit umgehen >> können. > > Ja. Es geht also überhaupt nicht darum, das OS zu verstehen oder gar zu > beherrschen. Nur darum, es benutzen zu können. Sprich: Schluß ist i.d.R. > da, wo irgendwas nicht so läuft, wie es laufen sollte. Ja, natürlich geht es um einen Einstieg. "Normalen Benutzern" (was auch immer das sein mag, meinen Erfahrungen zufolge sind Benutzer sehr individuell) etwas über die Interna und Funktionsweise eines Betriebssystem beibringen zu wollen, das sie noch nicht einmal bedienen können, scheint mir ein eher hoffnungsloses Unterfangen zu sein. Ich sehe auch nicht, daß jeder, der einen Computer (oder ein Windows, Linux, MacOS, *BSD... you name it) benutzt, dazu zwingend "das OS [...] verstehen" müsse. Wenngleich es vielleicht manchmal wünschenswert wäre, wenn die Leute ihren Computer und seine Funktionsweise besser verstünden, sind die internen Funktionen und Arbeitsweisen von Betriebssystemen nicht ganz trivial -- und dürften die meisten Anwender zumindest heraus-, wenn nicht gar überfordern. Was ist also Dein Punkt? >> Und dennoch gibt es Volkshochschulen, die Linux-Schulungen >> anbieten, und einige Menschen nehmen offenbar sogar an solchen Kursen >> teil. > > Kein Ahnung, was da dann vermittelt wird. Fakt ist jedenfalls, dass man > bei Linux sehr viel häufiger auf Situationen stößt, die nicht mit ein > paar Klicks irgendwo im GUI zu lösen sind. Und mehr kann man einem > Standard-DAU einfach nicht abverlangen. Das sehe ich allerdings anders. Auch wenn ich es mangels Windowskenntnissen und -Erfahrungen nur anhand der Threads in diesem Forum annehmen kann, glaube ich kaum, daß Linux-Anwender "sehr viel häufiger auf Situationen [stoßen], die nicht mit ein paar Klicks irgendwo im GUI zu lösen sind". Außerdem haben doe Kommandozeilen gerade bei der Fehleranalyse und -Behebung ein paar deutliche Vorteile, vor allem sind sie leichter zu übermitteln und oft auch eindeutiger. Davon abgesehen habe ich allerdings den Eindruck, daß Du Dir gerade selbst widersprichst: während Du oben kritisierst, daß VHS-Kurse zu oberflächlich seien und Computer-Anfänger nicht direkt zu Administratoren qualifizieren, sagst Du nun, daß man dem "Standard-DAU" nicht zu viel abverlangen dürfe? Irgendwie erscheint mir das widersprüchlich, warum nur? :-)
Ein T. schrieb: > irgendwo im GUI zu lösen sind". Außerdem haben doe Kommandozeilen gerade > bei der Fehleranalyse und -Behebung ein paar deutliche Vorteile, vor > allem sind sie leichter zu übermitteln und oft auch eindeutiger. Und Du erwartest nun, dass ein ganz normaler Computernutzer, der irgendeinen Befehl im Internet gefunden hat, den Output dieses Befehls zu verstehen weiß? Die meisten User werden schon mit simplen Befehlen wie cd, dir/ls, type/cat, ... vollkommen überfordert sein.
:
Bearbeitet durch User
Nach den wiederholten Umgestaltungen der Windows Systemsteuerung sind viele Hilfsangebote auf die Kommandozeile gewechselt.
Jens G. schrieb: > Ein T. schrieb: >> irgendwo im GUI zu lösen sind". Außerdem haben doe Kommandozeilen gerade >> bei der Fehleranalyse und -Behebung ein paar deutliche Vorteile, vor >> allem sind sie leichter zu übermitteln und oft auch eindeutiger. > > Und Du erwartest nun, dass ein ganz normaler Computernutzer, der > irgendeinen Befehl im Internet gefunden hat, den Output dieses Befehls > zu verstehen weiß? Die meisten User werden schon mit simplen Befehlen > wie cd, dir/ls, type/cat, ... vollkommen überfordert sein. Und mit "Klick auf Start, dann Einstellungen, dann Systemsteuerung, dann System, dann..." ist er weniger überfordert? Zudem geht es mir primär um interaktive Unterstützung in zum Beispiel Foren wie diesem hier. Textein- und -ausgaben von Befehlen sehe ich hier häufiger als Screenshots.
Nemopuk schrieb: > Nach den wiederholten Umgestaltungen der Windows Systemsteuerung sind > viele Hilfsangebote auf die Kommandozeile gewechselt. Nicht wirklich. Vielmehr werden sehr häufig Tips veröffentlicht, wie man wieder an die alten, weitaus mächtigeren Dialoge herankommt. Denn die existieren ja fast durchgängig nach wie vor im System. Übrigens halte ich es für eine große Sauerei, was MS da veranstaltet. Wenn die ihre Dialoge unbedingt "webifizieren" wollen: meinetwegen. Aber dann darf nicht 1/2..2/3 der Funktionalität verloren gehen. Aber genau das ist leider meist der Fall.
Bei meiner Suche nach der benötigten Software für die Eingangs erwähnte Windows-Installation (Programmier-Unterricht) habe ich bemerkt, dass einige wichtige Softwares wie Visual Studio, VSC oder PyCharm sogar direkt für Windows-on-ARM angeboten wird ...
Frank E. schrieb: > dass > einige wichtige Softwares wie Visual Studio, VSC oder PyCharm sogar > direkt für Windows-on-ARM angeboten wird ... Was soll da eigentlich programmiert werden? Für Rust, Haskell oder andere Sachen empfiehlt sich eher Linux (Unix vielleicht auch noch) - wäre vielleicht gut, verschiedene Ansätze durchzugehen. (https://github.com/open-watcom/open-watcom-v2/issues/176)
Rbx schrieb: > Frank E. schrieb: >> dass >> einige wichtige Softwares wie Visual Studio, VSC oder PyCharm sogar >> direkt für Windows-on-ARM angeboten wird ... > > Was soll da eigentlich programmiert werden? Für Rust, Haskell oder > andere Sachen empfiehlt sich eher Linux (Unix vielleicht auch noch) - > wäre vielleicht gut, verschiedene Ansätze durchzugehen. > (https://github.com/open-watcom/open-watcom-v2/issues/176) Es ist ein Einsteiger-Kurs für FI Anwendungsentwickler, das Curiculum habe nicht ich mir ausgedacht! Erstmal nur das Übliche wie Variablen, Konstanten, Kontrollstrukturen und schließlich Klassen, jeweils in C# und Python mit Ausgabe in die Konsole. Das Ganze als Remote-Unterricht mit Screen-Sharing. Obwohl es die genannen Werkzeuge auch für MacOS gibt, besteht der Veranstalter darauf, es in einer Windows-Umgenung zu machen. Da ich nur Macs besitze, eben dann über die VM ... geht aber nun problemlos. Für mich selbst bzw. die Projekte der Firma werden völlig andere Tools bzw. IDEs verwendet, aber das ist eine andere Geschichte.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.