Ich bin vor kurzem vollständig auf Linux umgestiegen, benötige aber leider etwas Software noch auf Windows (unter anderem Altium Designer). Ich hab nun ein kleines Board mit KiCAD erstellt aber an das Feature-Set von Altium kommt es einfach vor allem beim Routen nicht an. Deswegen wieder Altium auf einer Windows 10 VM unter VirtualBox installiert. Leider ist Altium in der VM nicht wirklich angenehm bedienbar. Es dauert einfach alles etwas länger und ruckelt teilweise auch (klar, die virtuelle Grafikkarte hat ja nur 256MB RAM, was anscheinend das Maximum ist). Ich hab schon GuestAdditions von VirtualBox installiert, RAM + CPU hochgeschraubt aber so wirklich geholfen hat das alles nichts. Dann hab ich mir heute Abend den Spaß gegönnt dochmal KVM/QEMU auszuprobieren. Läuft auch halbwegs aber erstmal nicht merklich schneller. Dazu gekommen irgendwas zu installieren bin ich nicht, da SharedFolder anscheinend nativ mit dem virt-manager nicht möglich ist sondern man über irgendwelche Umwege gehen muss - sprich ich hab dann enttäuscht aufgegeben (was nützt mir ein Guest-Betriebssystem ohne SharedFolder). DualBoot möchte ich überhaupt nicht da das für mich noch weniger Komfort ist als die lahme VM über VirtualBox. Kennt ihr noch Alternativen (nein, komplett zurück zu Windows auch nicht)?
:
Bearbeitet durch User
Alternative? Entweder den Rechner soweit aufrüsten, das Win+Altium in der VM wirklich gut läuft, oder einen zweiten Windows Rechner mit der Software "headless" laufen lassen und Remote vom Linux darauf zugreifen.
Thomas schrieb: > Entweder den Rechner soweit aufrüsten, das Win+Altium in der VM wirklich > gut läuft, Ich bezweifle aktuell, dass es eine Hardware-Kombination gibt, mit der das möglich ist. Mir scheint, dass die Virtualisierung von VirtualBox einfach bei weitem nicht an ein "natives" Erlebnis herankommt (vor allem von der Grafikkarte her). Mein Rechner ist eigentlich recht gut ausgestattet, hab einen i7 6700K, GTX1050, 16GB RAM und 2 SSDs. Auch wenn es nicht mehr das Neueste vom Neuesten ist, ist das bei weitem keine langsame Kiste (meiner Ansicht nacht). Thomas schrieb: > oder einen zweiten Windows Rechner mit der Software > "headless" laufen lassen und Remote vom Linux darauf zugreifen. Wäre tatsächlich eine Idee. Das Problem ist nur, dass ich einen 4K Monitor als Hauptmonitor verwende. 4K x 60FPS per WLAN übertragen (Remote) wird denke ich nicht ordentlich bzw. flüssig funktionieren. Ich weiß, das ist jetzt etwas mimimi, ich versuche nur gerade andere Möglichkeiten abzuklappern. Ansonsten bleibe ich bei der VirtualBox.
:
Bearbeitet durch User
Hallo, das sollte aber in Griff zu kriegen sein. Ich nutze Altium 17 in der gleichen Konstellation und empfinde kein Ruckeln o.ä. Allerdings habe ich Altium auch noch nie in einer nativen Installation verwendet. Kann sein, dass mir auch nur der Vergleich fehlt ;) In den Einstellungen der VM solltest Du "3D" und "2D Video" Beschleunigung aktivieren können. Wenn das bereits aktiviert ist, wäre meine nächste Frage, was Du denn für eine Grafikkarte hast. Bei NVIDIA Karten bspw. solltest Du die propritären NVIDIA Treiber verwenden. Mit den quelloffenen Treibern hatte ich seinerzeit auch Performanceprobleme. Bei ATI Karten würde ich ebenfalls mal nach aktuellen Treibern beim Hersteller schauen.
Vielleicht mal VMWare Workstation testen, kann man 30 Tage (glaube ich) kostenlos nutzen. Dort empfand ich die 3D Beschleunigung immer etwas angenehmer als in VirtualBox.
KVM wurde Dir ja bereits als bessere Lösung genannt. Du kannst eine zweites Grafikboard installieren und das als PCI passthrough an die VM durchreichen. Um Daten zwischen Host und VM auszutauschen bietet sich das erstellen eines zweiten (virtuellen) NIC an.
Angehängte Dateien:
-
nvidia_driver.png
60 KB
Alias schrieb: > In den Einstellungen der VM solltest Du "3D" und "2D Video" > Beschleunigung aktivieren können. Sobald ich 3D Beschleunigung aktiviere (unter VBoxSVGA), wird z.B. das Startmenü stellenweise schwarz und flickert und in Altium zeigen gewissen Fenster keinen Inhalt mehr an. Alias schrieb: > Bei NVIDIA Karten bspw. solltest Du die propritären NVIDIA Treiber > verwenden. Hab eine GTX1050 von Nvidia, propritäre Treiber sind installiert (siehe Anhang). Donni D. schrieb: > Vielleicht mal VMWare Workstation testen Danke, die kenne ich noch von Windows. Wusste ich nicht, dass die auch unter Linux läuft. Den VMWare Player gibt es ja auch noch. Eric schrieb: > KVM wurde Dir ja bereits als bessere Lösung genannt. Wie auch beschrieben, "besser" kam sie mir nicht vor. Oberfläche war auch nicht wirklich flüssig und die Displayauflösung im Guest passt sich nicht automatisch der Monitorauflösung im Host an bzw. war auch 2560 x 1440 beschränkt. Eric schrieb: > Du kannst eine zweites Grafikboard installieren und das als PCI > passthrough an die VM durchreichen. Das hab ich auch schon gelesen. War mir um ehrlich zu sein erstmal zu viel Aufwand. Eric schrieb: > Um Daten zwischen Host und VM auszutauschen bietet sich das erstellen > eines zweiten (virtuellen) NIC an. Blöd gefragt, aber was mache ich dann mit diesem 2. NIC? Google sagt Samba-Server, aber das halte ich für Overkill für einen SharedFolder.
:
Bearbeitet durch User
Max M. schrieb: > Wäre tatsächlich eine Idee. Das Problem ist nur, dass ich einen 4K > Monitor als Hauptmonitor verwende. 4K x 60FPS per WLAN übertragen > (Remote) wird denke ich nicht ordentlich bzw. flüssig funktionieren. In beide Rechner eine 1000 MBit Netzwerkkarte (wenn die nicht sowieso auf dem Boards drauf sind) rein und mit einem kleinen Patch-Kabel direkt verbinden. Der zweite "Headless"-Rechner steht ja bestimmt auch in Schreibtischnähe.
Virt-viewer sollte das Guest VM in entsprechender Auflösung darstellen. Allerdings musst du dann noch die virtuellen Grafiktreiber in der vm installieren etc. alles Aufwand und wird nicht schneller ohne echte GPU in der VM. Also extra Rechner und dann per Remote Desktop drauf zugreifen.. Alles andere kostet dich nur mehr nerven und Zeit... Virtualbox unter windows Host war immer ein gebastel mit usb etc. Da freue Ich mich heute über linux und kvm....
:
Bearbeitet durch User
Max M. schrieb: > Leider ist Altium in der VM nicht wirklich angenehm bedienbar. Ich benutze (dienstlich) Altium in einer VM unter VMware. Ist allerdings noch die V16, da die 19er Demoversion Späne gemacht hatte. Andere wiederum scheinen auch die 18er/19er in VMware laufen zu haben, es ist also vermutlich kein grundsätzliches Problem. Wenn du es einfach mal testen willst: VMware Workstation Player ist für private Nutzung kostenlos benutzbar. Die VM ist an manchen Stellen insgesamt langsamer als der Host (nicht nur auf Altium bezogen), aber das liegt natürlich auch daran, dass ich ihr bspw. nur eine CPU "gönne" und dass die VM-Dateisysteme alle auf einer rotierenden Platte liegen, während der Host für OS und wesentliche Anwenderdaten eine SSD hat. Die 3D-Grafik lässt sich auf jeden Fall flüssig bedienen, und als ich das beim Kunden mal nebenbei auf einem inzwischen schon betagten Laptop laufen lassen habe, fanden sie vom Draufgucken her die Performance nicht schlechter als das, was sie native unter Windows benutzen. Sicher wird es Details geben, wo die VM nicht so flink ist.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Wenn du es einfach mal testen willst: VMware Workstation Player ist für > private Nutzung kostenlos benutzbar. Danke! Wieso bin ich nicht schon früher drauf gekommen. Hab unter Windows auch öfter VMware Player mit Linux als Guest eingesetzt - hat immer einwandfrei funktioniert. Ich dachte nur, das wäre eine reine Windows Applikation. Naja, was soll ich sagen. VMware Player installiert, VMware Tools im Guest installiert, Vtx-d aktiviert...und es fühlt sich an wie nativ - unglaublich was gute Software ausmacht (oder ich bin zu blöd für VirtualBox). 4K Display überhaupt kein Problem. Geil :)
Max M. schrieb: > oder ich bin zu blöd für VirtualBox Nö, die ist in mancherlei Hinsicht wirklich viel schlechter. Auch im Bereich USB liegen da Welten zwischen beiden. Selbst solche Sachen wie Firmwareupgrade von USB-Geräten (bspw. Atmel-Tools aus Atmel Studio heraus) funktionieren – und bei denen muss das Gerät zwischenzeitlich im Bootloader-Modus die IDs ändern. Ich musste lediglich für Dualmonitor-Betrieb den fvwm patchen, den ich nach wie vor gern benutze: VMware setzt dafür offenbar ein mittlerweile obsoletes Protokoll voraus, und die fvwm-Maintainer weigern sich, das noch zu implementieren. Aber gut, dafür isses Opensource, ich patche das dann einfach für mich selbst, und habe beide Monitore auch im VMware-Guest zur Verfügung.
:
Bearbeitet durch Moderator
Übrigens, das (für meine Begriffe) wirklich schöne an dieser Konstellation: du musst dem Windows nur dann ein richtiges Netzwerk geben, wenn du das wirklich mal willst (bspw. um Windows-Updates zu holen). Ansonsten läuft das Netzwerkinterface bei mir permanent auf "host only". Damit hat man Filesharing zwischen Host und Guest, aber so gut wie kein Risiko, dass einem da irgendeine Malware reinkommt.
Max M. schrieb: > Blöd gefragt, aber was mache ich dann mit diesem 2. NIC? Google sagt > Samba-Server, aber das halte ich für Overkill für einen SharedFolder. Du kannst natürlich auf dem Host einen Samba-Server installieren oder den Ordner in deiner (Windows) VM erstellen und vom Host aus darauf zugreifen. Aber Mal ehrlich, Samba installieren und drei Zeilen in eine Config zu schreiben ist doch kein allzu grosser Aufwand, oder? Warum dieser 2. nic? Nun, ich bin mal davon ausgegangen, dass Du ein separates Netzwerk nur zwischen Host und VM haben willst. Gerade wenn die VM ein Windows System ist dass nur dem Ausführen einer Software dient, macht es eventuell Sinn, es gar nicht erst aufs Netzwerk bzw Internet zugreifen zu lassen. Aber das muss jeder für sich entscheiden.
Max M. schrieb: > Eric schrieb: >> KVM wurde Dir ja bereits als bessere Lösung genannt. > > Wie auch beschrieben, "besser" kam sie mir nicht vor. Oberfläche war > auch nicht wirklich flüssig und die Displayauflösung im Guest passt sich > nicht automatisch der Monitorauflösung im Host an bzw. war auch 2560 x > 1440 beschränkt. Und Du hast auch alle virtio Treiber installiert und vor dem Start ausgewaehlt?
Eric schrieb: > Oberfläche war >> auch nicht wirklich flüssig und die Displayauflösung im Guest passt sich >> nicht automatisch der Monitorauflösung im Host an bzw. war auch 2560 x >> 1440 beschränkt. Und natuerlich unter Windows die Guest Tools von Spice installieren: https://spice-space.org/ Dann klappt das auch mit der Aufloesung und Copy&Paste
Jetzt mal ganz ehrlich, was spricht denn gegen eine zweite Installation von Windows neben Linux?! ? So läuft das bei mir hier auf dem Schleppe und auf dem Desktop.
Max M. schrieb: > Ich bezweifle aktuell, dass es eine Hardware-Kombination gibt, mit der > das möglich ist. Mir scheint, dass die Virtualisierung von VirtualBox > einfach bei weitem nicht an ein "natives" Erlebnis herankommt (vor allem > von der Grafikkarte her). Dreh das ganze um, benutz VM-Ware in win windows für linux
Rene K. schrieb: > Jetzt mal ganz ehrlich, was spricht denn gegen eine zweite Installation > von Windows neben Linux?! ? So läuft das bei mir hier auf dem Schleppe > und auf dem Desktop. Das heutzutage die Hardware Virtualisierung bei auch schon älteren Geräten so ausgereift und Hardware unterstützt ist das eine doppelinstallation schon eine komische Idee ist. EDIT: Das war im letzten Jahrzehnt modern.
:
Bearbeitet durch User
Rene K. schrieb: > was spricht denn gegen eine zweite Installation von Windows neben > Linux?! Dass es viel lästiger ist, jedesmal neu zu booten, statt einfach auf ein anderes Fenster umzuschalten und dort seine VM mit dem Altium innerhalb von weniger als einer Sekunde zur Hand zu haben. Der wirklich einzig verbleibende Nachteil eines zweiten, (vernünftig) virtualisierten OSes heutzutage ist, dass man natürlich RAM für zwei parallel laufende Betriebssysteme braucht. Das wird ansonsten der Flaschenhals. Im Gegenzug, mit ausreichend RAM kann man auch problemlos zwischen drei oder vier verschiedenen Systemen hin und her schalten. ;-)
:
Bearbeitet durch Moderator
Philipp K. schrieb: > ax M. schrieb: >> Ich bezweifle aktuell, dass es eine Hardware-Kombination gibt, mit der >> das möglich ist. Mir scheint, dass die Virtualisierung von VirtualBox >> einfach bei weitem nicht an ein "natives" Erlebnis herankommt (vor allem >> von der Grafikkarte her). > > Dreh das ganze um, benutz VM-Ware in win windows für linux Brauchst du nicht. Windows hat schon Unterstützung für Linux dabei: https://docs.microsoft.com/de-de/windows/wsl/install-win10
udok schrieb: > Windows hat schon Unterstützung für Linux dabei: Das mag für Leute gut sein, die neben Windows gern ein Linux hätten. Wer aber Windows eher nur notgedrungen und am Rande haben möchte, wird mit sowas nicht recht glücklich. Ich sage da nur "Schalten Sie Ihren Computer nicht aus" – um mal ein Beispiel zu nennen, was man mit dieser Variante eben doch nicht los wird. (Wenn ich diese Ausschrift in einer VM habe, dann schalte ich einfach die Fenster um und arbeite derweil weiter.) Was ich persönlich auch sehr praktisch finde: Snapshots. Wenn die VM sich mit irgendwas verrannt hat, oder man bspw. irgendwelche testhalber installierte Software wieder los werden will: einfach auf einen älteren Snapshot zurückleiern. Klar, das kostet extra Plattenplatz, aber der hat sich schon manches Mal bezahlt gemacht. (Geht allerdings bei VMware nur mit der Bezahlversion VMware Workstation, nicht mit dem Player.)
Ich würde ja auch gerne auf Windows verzichten... Geht aber in der Praxis nur schlecht, wenn man auf CAD Software (DirectX) angewiesen ist, oder wenn der Kunde Windows verwendet. Ich tue mir schon schwer, mich halbwegs in Windows auszukennen. Linux braucht da noch mal deutlich mehr Zeit.
Ich hab den Tread nicht wirklich komplett gelesen. Vorschlag: Bootmanager wie BootUS, oder BootStar. Beides bei mir seit Jahren ohne Probleme am laufen. Betriebssysteme wirden 'richtig' versteckt, sodass kein Schaden vom anderen BS entsteht. Andere Partitionen, wie Daten-Partition, ect. lassen sich individuell zuordnen, oder eben auch 'ect verstecken' Linux, Win 7, usw. kein Problem
udok schrieb: > Geht aber in der Praxis nur schlecht, wenn man auf > CAD Software (DirectX) angewiesen ist, Genau darum geht's im Thread, und genau das funktioniert durchaus auch in einer VM – wenn man das will. Der TE will es, und hat nun offenbar mit VMware Player eine praktikable Lösung. Ansonsten ist natürlich jeder frei, solche Entscheidungen für sich zu treffen, aber das gehört dann einfach mal nicht in diesen Thread. Der Thread-Titel ist zugegebenermaßen etwas sehr allgemein formuliert, aber man sollte sich vielleicht vor dem Mitdiskutieren wenigstens mal das Eröffnungsposting durchlesen.
Max M. schrieb: > Kennt ihr noch Alternativen (nein, komplett zurück zu Windows auch > nicht)? Ich habe hier zwei Rechner stehen, einen mit Windows 7 (unter anderem für Altium Designer) und einer mit Linux, auf das ich auch nicht verzichten kann. Anders geht es bei mir nicht - ich brauche unbedingt zwei physikalische Maschinen, weil da auch noch etwas Hardware dranhängt, was nicht virtualisierbar ist. fchk
Bei mir gibt es einen Linux Rechner an dem 2 Monitore hängen und ein Umschalter (USB/DVI). Monitor 1 ist auf HDMI, Monitor 2 auf beiden Rechnern DVI am Umschalter. Daneben ein 2ter Rechner mit windows/linux/bsd..Ich probiere gerne viel aus. Entweder ich arbeite mit den 2 Monitoren unter Fedora oder ich schalte um (Tastatur/Maus/Monitor2/Sound) auf den Win Rechner. Den Linux Rechner stört die Umschaltung nicht weil die USB Sachen sich nicht abmelden. Sie funktionieren dann eben auf dem anderen Rechner. Monitor 1 (HDMI) bleibt an. So kann ich immer wieder hin und her schalten ohne das die Rechner das aus dem Tritt bringt. Also Video Rendern auf der Linux Maschine und Iphone sichern auf der Windows Maschine. the Raccoon by the way. Auf dem Fedora ist ein win7 in der virtualbox und das läuft auch sehr gut.
Man kann fast alles virtualisieren - und was man nicht virtualisieren kann, wird durchgereicht. Das geht sogar mit dem USB Dongle von Architrend Zero - einer knapp 15k Euro teuren CAD Lösung aus dem Architektur Bereich. Wie andere vor mir bereits angemerkt haben kommt es auf die Ressourcen des Hosts an. RAM kann nie genug vorhanden sein; manchmal macht auch mehr als eine CPU Sinn. Beziehungsweise eine dediziertes Graphikboard für entsprechende Anwendungen als PCI passthrough. Wenn man unter Linux KVM einsetzt - mit den richtigen Treibern (spice und virtio) - dann merkt man auch keinen Unterschied zu einem System welches auf einem physikalischen Rechner läuft.
Jörg W. schrieb: > udok schrieb: >> Geht aber in der Praxis nur schlecht, wenn man auf >> CAD Software (DirectX) angewiesen ist, > > Genau darum geht's im Thread, und genau das funktioniert durchaus auch > in einer VM – wenn man das will. Der TE will es, und hat nun offenbar > mit VMware Player eine praktikable Lösung. > > Ansonsten ist natürlich jeder frei, solche Entscheidungen für sich zu > treffen, aber das gehört dann einfach mal nicht in diesen Thread. Der > Thread-Titel ist zugegebenermaßen etwas sehr allgemein formuliert, aber > man sollte sich vielleicht vor dem Mitdiskutieren wenigstens mal das > Eröffnungsposting durchlesen. Klar kann man theoretisch alles virtualisieren. Es macht nur nicht immer viel Sinn. Manchmal ist die beste Lösung eben die, das Problem zu umschiffen. Aber natürlich kann jeder seine Zeit verbraten, wie er mag.
udok schrieb: > Aber natürlich kann jeder seine Zeit verbraten, wie er mag. Eben. Beispielsweise durch Warten auf "Bitte schalten Sie den Computer nicht aus". :-)) SCNR …
Angehängte Dateien:
-
Altium_VMWare.png
30 KB
Eine Zwischenfrage, an alle die Altium unter VMWare Workstation auf einem Linux Host nutzen: Habt ihr auch solche Rendering Probleme im 3D Modus, dass keine Pads und Silkscreen angezeigt werden? VMWare Workstation 15.5 Altium 19.1.8 Host: openSUSE Leap 15.1
Ich denke das dein KVM nicht richtig eingerichtet war/ist. Videotreiber QXL/spice mit passenden Treibern im Windows. Bei mir läuft Windows gefühlt in der VM sogar schneller als Nativ auf der selben Maschine. (Dank Linux Festplattencache im RAM)
Tobias .. schrieb: > Habt ihr auch solche Rendering Probleme im 3D Modus, dass keine Pads und > Silkscreen angezeigt werden? Ich nicht, ist allerdings noch Altium 16.
Tobias .. schrieb: > Eine Zwischenfrage, an alle die Altium unter VMWare Workstation auf > einem Linux Host nutzen VMware nutze ich zwar beruflich (ESXi), allerdings werden auf den VMs dort keine grafiklastigen Anwendungen ausgeführt. Wie ich bereits angemerkt habe, ist KVM die bessere Lösung. Ausreichend RAM, die richtigen Treiber und gegebenfalls ein dediziertes Grafikboard als PCI passthrough und ich bin mir sicher dass auch Altium keine Probleme beim Rendern hat.
Max M. schrieb: > was nützt mir ein Guest-Betriebssystem ohne SharedFolder). Mach dir doch einen Netzwerkordner. Zb. USB HDD an einer fritzbox oder die freigabe unter Windows/linux Nutzen.
Jörg W. schrieb: > udok schrieb: >> Aber natürlich kann jeder seine Zeit verbraten, wie er mag. > > Eben. Beispielsweise durch Warten auf "Bitte schalten Sie den Computer > nicht aus". :-)) > > SCNR … Im Ernst: Worauf sollte ich da warten? Der Computer schaltet sich dann selbst aus.
Reinhard S. schrieb: > Jörg W. schrieb: >> Eben. Beispielsweise durch Warten auf "Bitte schalten Sie den Computer >> nicht aus". :-)) >> >> SCNR … > > Im Ernst: Worauf sollte ich da warten? Der Computer schaltet sich dann > selbst aus. Immer wieder erfreulich am Ende des Arbeitstags wenn man das Notebook mit nach Hause nimmt/nehmen muss. Ist man eh shon spät dran, beglückt einen das Windows dann mit "1 von 50 Updates werden installiert..,"
Andreas M. schrieb: > Reinhard S. schrieb: >> Jörg W. schrieb: >>> Eben. Beispielsweise durch Warten auf "Bitte schalten Sie den Computer >>> nicht aus". :-)) >>> >>> SCNR … >> >> Im Ernst: Worauf sollte ich da warten? Der Computer schaltet sich dann >> selbst aus. > > Immer wieder erfreulich am Ende des Arbeitstags wenn man das Notebook > mit nach Hause nimmt/nehmen muss. Ist man eh shon spät dran, beglückt > einen das Windows dann mit "1 von 50 Updates werden installiert..," Oder wenn man wie weiter oben vorgeschlagen ein Dual-Boot aufgesetzt hat und das Windows alle paar Monate mal für ein paar Stunden braucht. Da kann man schon mal jedesmal noch ne extra Stunde zusätzlich einplanen für die Zeit die es braucht bis es sich nach dem Boot wieder beruhigt hat und die Zeit die es anschließend zum Herunterfahren braucht. Da bekomm ich jedesmal Hautausschlag davon. Der Blick auf den Kalender zeigt ganz klar 2019 und dann kommt der Windows-Flashback mit User-Experience aus den späten 80ern, ganz egal welche Versionsnummer es hat, im Gegenteil sogar: Je höher die Versionsnummer desto schlimmer.
:
Bearbeitet durch User
Dann schalt die Windows Kiste doch einfach aus. So einfach kann es sein...
udok schrieb: > Dann schalt die Windows Kiste doch einfach aus. Das letzte mal als ich das gemacht habe (nachdem ich 1 Stunde lang "Bitte schalten Sie nicht aus" betrachten durfte, morgens beim Hochfahren) war das Windows anschließend kaputt. Manch einer würde wohl geneigt sein zu sagen sowas ist kein Werkzeug für professionellen Einsatz sondern eher ein Spielzeug, aber diese Diskussion möchte ich hier nicht lostreten, deshalb sag ich da jetzt mal nichts dazu.
:
Bearbeitet durch User
Das dürfte dann aber noch unter Windows 98 mit FAT32 gewesen sein. Seit XP gibt es einen Cache, der die wichtigen DLLs sichert. Auch ist das NTFS ziemlich abgesichert gegen DAUs (Wiederherstellungspunkte, Journaling File System, redundante Tabellen). Windows 7/10 ist unter der Haube ein ziemlich fortschrittliches BS, das wegen einem fehlgeschlagenen Update nicht gleich die Haxn streckt.
Max M. schrieb: > Ich bin vor kurzem vollständig auf Linux umgestiegen, benötige aber > leider etwas Software noch auf Windows[...]VirtualBox[...]ruckelt. Hast du es schon mit Wine probiert?
Andreas M. schrieb: > Reinhard S. schrieb: >> Jörg W. schrieb: >>> Eben. Beispielsweise durch Warten auf "Bitte schalten Sie den Computer >>> nicht aus". :-)) >> >> Im Ernst: Worauf sollte ich da warten? Der Computer schaltet sich dann >> selbst aus. > > Immer wieder erfreulich am Ende des Arbeitstags wenn man das Notebook > mit nach Hause nimmt/nehmen muss. Ist man eh shon spät dran, beglückt > einen das Windows dann mit "1 von 50 Updates werden installiert..," Und wenn man die Kiste am nächsten Morgen wieder anmacht, dauert es gerade mal einen halben Tag, bis sie wieder neu starten will... Naja, ich werde für die Zeit ja bezahlt, und wenn die Firma das mit der IT nicht hinbekommt... Privat tue ich mir das nicht mehr an. MfG, Arno
A. M. schrieb: > Hast du es schon mit Wine probiert? Die aktuellen Altium Designer versionen soll laut WineHQ.org nicht besonders gut laufen: https://appdb.winehq.org/objectManager.php?sClass=version&iId=37491 Aber es wird wohl dran gearbeitet: https://bugs.winehq.org/show_bug.cgi?id=46107
Das grösste Problem mit Windows dürfte sein, dass man meist keine Admin Rechte hat, und die IT nicht wirklich für einen da ist. Man hat keine Kontrolle. Das nächstgrössere Problem ist, dass sich - ausser Programmierer - keiner mit Windows beschäftigt und daher auch kein tieferes Verständnis hat, wie man Probleme lösen kann. Windows lädt auch nicht gerade dazu ein, es ist ja ein Werkzeug, das zu funktionieren hat, und keine Spielzeug wie Linux. Daraus resultiert dann dieses typische Draufhauen auf Windows. Linux hingegen sucht man sich selbst aus, in dem Wissen, dass es erst mal viele Probleme machen wird, aber das ist ja eine Herausforderung. Es ist wie ein Spielzeug, man hat die Kontrolle darüber, und könnte es auch jdederzeit durch eine andere Distri ersetzen oder sogar die Platte formatieren :-) Mit dieser positiven Einstellung sieht man dann die Probleme nicht mehr als Probleme sondern als nette Eigenheiten des Systems, die man Nichtwissenden lange und ausführlich erklären kann. Und man könnte ja den Source Code anpassen, wenn man gar nicht mehr weiterweiss. Wenn aber erst mal Linux in die Büros einzieht, und es zu einem dummen Werkzeug wird, das zu funktionieren hat, und der Frustlevel steigt, dann wünscht man sich manchmal sein buntes Windows zurück. (Vielleicht so geschehen in der Münchner Bürokratie...).
Udo K. schrieb: > dass sich - ausser Programmierer - > keiner > mit Windows beschäftigt und daher auch kein tieferes > Verständnis hat, wie man Probleme lösen kann. Softwareentwickler beschäftigen sich auch nicht wirklich mit Windows. Das sind eher die Systemadmins.
Andreas M. schrieb: > Reinhard S. schrieb: >> Jörg W. schrieb: >>> Eben. Beispielsweise durch Warten auf "Bitte schalten Sie den Computer >>> nicht aus". :-)) >>> >>> SCNR … >> >> Im Ernst: Worauf sollte ich da warten? Der Computer schaltet sich dann >> selbst aus. > > Immer wieder erfreulich am Ende des Arbeitstags wenn man das Notebook > mit nach Hause nimmt/nehmen muss. Ist man eh shon spät dran, beglückt > einen das Windows dann mit "1 von 50 Updates werden installiert..," Wenn man das auf Arbeit so "runterfährt" ist es zuhause doch fertig. Schlimmer find ich dann beim darauffolgenden Start die "Restarbeiten" samt schlimmstenfalls nochmaligem Reboot. Aber wenn mans weiß startet man eben mal so oder holt sich in der Zeit nen Kaffee. Bernd K. schrieb: > Oder wenn man wie weiter oben vorgeschlagen ein Dual-Boot aufgesetzt hat > und das Windows alle paar Monate mal für ein paar Stunden braucht. Da > kann man schon mal jedesmal noch ne extra Stunde zusätzlich einplanen > für die Zeit die es braucht bis es sich nach dem Boot wieder beruhigt > hat und die Zeit die es anschließend zum Herunterfahren braucht. Hier ist der Punkt für mich schon eher nachvollziehbar. Wobei ne Stunde nun auch übetrieben ist, meiner Erfahrung nach. Aber klar, selbst 10 Minuten Wartezeit und Gerödel nervt da. > Da bekomm ich jedesmal Hautausschlag davon. Der Blick auf den Kalender > zeigt ganz klar 2019 und dann kommt der Windows-Flashback mit > User-Experience aus den späten 80ern, ganz egal welche Versionsnummer es > hat, im Gegenteil sogar: Je höher die Versionsnummer desto schlimmer. Kann nicht sein, in den späten 80ern gabs noch keine derartigen Updates ;) Ich kenn jetzt die Update-Mechanismen von Linux nicht (mehr), werd sie aber im Rahmen des Win7-Supportendes sicher kennenlernen.
Reinhard S. schrieb: > Ich kenn jetzt die Update-Mechanismen von Linux nicht (mehr) Bei Arch-Linux (manuell):
1 | sudo pacman -Syu |
Automatisch updated sich das System nicht.
Reinhard S. schrieb: > Ich kenn jetzt die Update-Mechanismen von Linux nicht (mehr), Sie haben ihre Abhängigkeiten insgesamt besser im Griff, und müssen daher nicht für allen Krimskrams „vorsichtshalber“ gleich mal die Kiste runterfahren. Außerdem haben alle Unixe ein völlig anderes Dateisystem-Verhalten, was es einem problemlos gestattet, eine aktuell ausgeführte Datei zu löschen: die noch in Ausführung befindliche Datei wird erst dann gelöscht, wenn nicht nur der letzte Verzeichniseintrag darauf entfernt worden ist, sondern auch die letzte in Ausführung befindliche Instanz beendet ist. Du kannst dann jedoch bereits eine neue (bspw. aktualisierte) Datei gleichen Namens anlegen, die dann jedoch auf eine völlig andere Datei zeigt. Die Dateien selbst werden durch Beschreibungsblöcke eindeutig gekennzeichnet (i-node). Windows unterscheidet dagegen nicht zwischen Verzeichniseintrag und Dateibeschreibungsblock, deshalb musst du dort zwangsweise einen entsprechenden Serverprozess erst einmal anhalten, damit du die zugehörige Datei löschen / ersetzen kannst. Allein dadurch sind Aktualisierungen natürlich viel „smoother“ zu arrangieren. Wenn man einen neuen Kernel braucht, muss man natürlich auch neu booten, aber das ist dann ein ganz normaler Neustart (dessen Zeitpunkt man sich selbst aussuchen kann), ohne nennenswerten weiteren Overhead. Ladbare Kernelmodule lassen sich dagegen normalerweise auch ohne Neustart austauschen, nur das durch sie implementierte Subsystem steht dann halt für einen Moment nicht zur Verfügung.
Uhuhu... Also Debian hat mittlerweile auch immer die Eigenart einen Neustart nach einem Update machen zu müssen. Update muss man zwar Manuel starten aber bei Windows kann man sich die Automatischen Updates ja auch ausschalten... Achja, und ein Zeitpunkt in der nicht produktiven Zeit zum installieren kann man mittlerweile unter Windows 10 auch einstellen. Ich arbeite übrigens unter Linux und Windows, auf dem Familierechner zu Hause läuft übrigens Windows 10... Weil es, für einen Ottonormal-Benutzer (in dem Fall meine Frau), intuitiver zu bedienen ist.
Rene K. schrieb: > bei Windows kann man sich die Automatischen Updates ja auch > ausschalten.. Das war einmal...!
Jörg W. schrieb: > Reinhard S. schrieb: >> Ich kenn jetzt die Update-Mechanismen von Linux nicht (mehr), > > Sie haben ihre Abhängigkeiten insgesamt besser im Griff, und müssen > daher nicht für allen Krimskrams „vorsichtshalber“ gleich mal die Kiste > runterfahren. Ist das so? Die Abhängigkeiten innerhalb des Windows Betriebssystems sind relativ gering, da zumindest bis Windows 7 nur wenige DLLs für wichtige Betriebssystemkomponenten erlaubt waren. Das ist aber in der Hand von MS gut aufgehoben. Anwenderprogramme sind Sache der Hersteller. Die hängen typischerweise von einer bestimmten Version einer DLL (wie msvcrt-x.y.dll) ab, und die muss irgendwo im Pfad sein. Diese DLLs werden aber nur bei Sicherheitsproblemen gepatcht. Abgesehen von wenigen Desastern ist die Abwärtskompatibilität von Windows ziemlich gut. Da werden viele Programmierfehler und Schlampigkeiten verziehen, damit alte Programme laufen. Unter Linux hat jede Distro ein bis zwei Packetmanager, und es gibt keinen Standard. Da hat es mir schon für mich wichtige Programme zerschossen, weil irgendwas geupdated wurde, weil die Packetmanager nichts voneinander wussten. Die Abhängigkeiten von grossen Packeten wie Latex oder KDE sind Seitenlang, das macht alles einen fragilen Eindruck. Die Doku, Libs und Config Files der Programme sind über das ganze Filesystem verteilt, und der Wildwuchs der Config Files wird immer schlimmer. Das war zu Zeiten, wo ein Directory Eintrag viel Platz brauchte und es sowieso nur eine man Page gab ok, aber heute? Abwärtskompatibilität unter Linux? Ich schätze mal das es kein ein einziges komplexes 32 Bit Program gibt, das heute noch auf einem 64 Bit Linux läuft, oder sich neu kompilieren lässt. Unter Windows ist es schon ziemlich lange her, dass ich wegen einem Update neu booten musste. Es gibt dazu auch seit Jahren keinen wirklichen Grund mehr. Wichtige Systemfiles werden beim nächsten Booten vor dem Start von Hintergrundprozessen überschrieben. Dazu gibt es eine API. Die meisten Files werden aber im laufenden Betrieb geupdated. > > Außerdem haben alle Unixe ein völlig anderes Dateisystem-Verhalten, was > es einem problemlos gestattet, eine aktuell ausgeführte Datei zu > löschen: die noch in Ausführung befindliche Datei wird erst dann > gelöscht, wenn nicht nur der letzte Verzeichniseintrag darauf entfernt > worden ist, sondern auch die letzte in Ausführung befindliche Instanz > beendet ist. Das hat für viele Programcrashes gesorgt, wenn dem Program wichtige Config und Daten Files unter dem Hintern wegkopiert wurden :-) Daher hat jedes ernstzunehmende Programpacket seinen eigenen Locking Mechanismus erfunden... ach herrje, den konnte man ja auch einfach umgehen. Du kannst dann jedoch bereits eine neue (bspw. > aktualisierte) Datei gleichen Namens anlegen, die dann jedoch auf eine > völlig andere Datei zeigt. Die Dateien selbst werden durch > Beschreibungsblöcke eindeutig gekennzeichnet (i-node). Windows > unterscheidet dagegen nicht zwischen Verzeichniseintrag und > Dateibeschreibungsblock, deshalb musst du dort zwangsweise einen > entsprechenden Serverprozess erst einmal anhalten, damit du die > zugehörige Datei löschen / ersetzen kannst. Windows hat dasselbe Verhalten, nur ist der Default beim Öffnen einer Datei, diese nicht zu "sharen". Das lässt sich aber bei fopen() einstellen. > > Allein dadurch sind Aktualisierungen natürlich viel „smoother“ zu > arrangieren. Wenn man einen neuen Kernel braucht, muss man natürlich > auch neu booten, aber das ist dann ein ganz normaler Neustart (dessen > Zeitpunkt man sich selbst aussuchen kann), ohne nennenswerten weiteren > Overhead. Ladbare Kernelmodule lassen sich dagegen normalerweise auch > ohne Neustart austauschen, nur das durch sie implementierte Subsystem > steht dann halt für einen Moment nicht zur Verfügung. Ist auch unter Windows seit langem so. Ich behaupte mal, das sich die Betriebssysteme heute nicht mehr stark unterscheiden. Alle wichtigen Features gibt es bei Windows und bei Linux. Die Systeme sind erwachsen geworden. Der DAU User ist halt unter Linux noch nicht so sehr verbreitet. Dafür ist dort der Egomane daheim. Die Entwicklung wird bei beiden Systemen seit langem von Firmen gestemmt. Beide Systeme sind hässlich komplex, inkonsistent, und protzen mit Bloatware.
Udo K. schrieb: >> Sie haben ihre Abhängigkeiten insgesamt besser im Griff, und müssen >> daher nicht für allen Krimskrams „vorsichtshalber“ gleich mal die Kiste >> runterfahren. > > Ist das so? Warum zum Geier™ muss Windows denn sonst diese berüchtigte Ausschrift ausspucken? > Windows hat dasselbe Verhalten, Du hast offenbar nicht den grundsätzlichen Unterschied beider Dateisystemkonzepte begriffen. Es ist eben etwas völlig anderes, ob ein Verzeichniseintrag die Datei selbst beschreibt (CP/M, RSX-11, MS-DOS, Windows, vermutlich auch VMS), oder ob er nur einen (von potenziell vielen) Verweis auf das Dateiobjekt enthält, welches komplett unabhängig von Verzeichniseinträgen (und damit "Dateinamen") existiert (alle Unixe). Wenn du diesen Unterschied begriffen hättest, würdest du eine solche Behauptung nicht aufstellen. Ich habe nicht behauptet, dass es jederzeit unproblematisch ist, entsprechende Dateien im Betrieb auf diese Weise zu ersetzen, aber es ist eben grundsätzlich dadurch erst einmal möglich – und zwar, indem beide Dateiversionen noch für eine gewisse Zeit parallel existieren. > Unter Windows ist es schon ziemlich lange her, dass ich wegen einem > Update neu booten musste. Sorry, dann machen alle meine Kollegen wohl was falsch. Sie dürfen sich regelmäßig damit rumärgern. (Bei mir sind die durch Updates verursachten Reboots auch selten, aber nur, weil ich das Windows in der VM sowieso nur sehr selten update – und ansonsten getrennt vom großen Netz halte.)
Max M. schrieb: > DualBoot möchte ich überhaupt nicht da das für mich noch weniger Komfort > ist als die lahme VM über VirtualBox. > > Kennt ihr noch Alternativen (nein, komplett zurück zu Windows auch > nicht)? Ja, du hast genau zwei Möglichkeiten 1. Klassisches Dualbooten, ist am einfachsten und am günstigsten, bedeutet aber doppelter Pflegeaufwand und ja, willst du nicht, habe ich gelesen. 2. Zweite dedizierte GPU kaufen und in den Rechner einbauen. Und diese extra GPU an die VM durchreichen, so dass die VM die alleinige Kontrolle über die GPU bekommt. Damit bekommst du eine sehr gute Performance hin, vergleichbar, als wenn du einfach Dualbooten würdest. Der Nachteil sind aber extra kosten für die extra Grafikkarte und das Problem, dass du einen Monitor mit zwei Eingängen benötigst und dann am Monitor immer zwischen Gast OS und Host OS umschalten musst. Für einen Betrieb von Windows im Fenstermodus auf dem Host OS (Linux) ist das also nicht gedacht. Eine alternative zum Umschalten des Eingangssignal am Monitor wäre ein zweiter Monitor, aber das ist auch doof, da man dann auf dem Schreibtisch nicht mehr die beste Ergonomie hat. Auf jeden Fall ist es auch teurer, vor allem wenn du auch unter Linux eine High-End GPU nutzen möchtest und so etwas auch für Windows haben willst. Dann musst du praktisch zweimal eine High End GPU kaufen, da ist Dualbooten viel günstiger. Falls dir aber die integrierte GPU auf der CPU unter dem Host- oder Gastsystem genügt, ist es nicht all zu teuer.
Bernd K. schrieb: > Windows alle paar Monate mal für ein paar Stunden braucht. Da kann man > schon mal jedesmal noch ne extra Stunde zusätzlich einplanen für die > Zeit die es braucht bis es sich nach dem Boot wieder beruhigt hat und > die Zeit die es anschließend zum Herunterfahren braucht. > Da bekomm ich jedesmal Hautausschlag davon. Der Blick auf den Kalender > zeigt ganz klar 2019 und dann kommt der Windows-Flashback mit > User-Experience aus den späten 80ern, ganz egal welche Versionsnummer es > hat, im Gegenteil sogar: Je höher die Versionsnummer desto schlimmer. Dem kann ich nur zustimmen. Gestern auf der Arbeit wieder erlebt als der Rechner den ganzen Vormittag für ein Update gebraucht hat. Während dieser Zeit kann man das System im Gegensatz zu Linux/BSD natürlich nicht benutzen. Für den Produktiven Einsatz völlig ungeeignet. Zumal nach dem Update auch noch die Vlan Einstellungen weg waren...
Hauke Haien schrieb: >> bei Windows kann man sich die Automatischen Updates ja auch >> ausschalten.. > > Das war einmal...! Das geht tatsächlich über die GPOs - zumindest bei Version 1604 LTSB. Warum man das nicht wie bei vernünftigen OS im Menü einstellen kann, erschliesst sich mir nicht. Das gilt natürlich auch für diverse andere Dinge, die in Windows einfach miserabel gelöst sind. Nur weil Windows 10 weniger häufig abstürzt als Windows 95, wird daraus nicht gleich ein gutes OS.
Udo K. schrieb: > Ich schätze mal das es kein ein einziges komplexes 32 Bit Program gibt, > das heute noch auf einem 64 Bit Linux läuft, > oder sich neu kompilieren lässt. Gegenfrage: Nenne doch Mal ein 32bit Programm dass sich nicht kompilieren/ausführen lässt. i386/lib32 Pakete vorausgesetzt. Wenn eine alte Software nicht läuft, liegt es nicht an der Architektur (32 oder 64 Bit), sondern an den Abhängigkeiten. Eine Möglichkeit wäre ein LXC/Jail mit den entsprechenden Abhängigkeiten zu erstellen und die Software darin auszuführen.
Rene K. schrieb: > Also Debian hat mittlerweile auch immer die Eigenart einen > Neustart nach einem Update machen zu müssen. Ich verwende seit Jahren devuan (im grunde genommen debian ohne systemd), und kann definitiv sagen, dass das bullshit ist. Nach einem update muss man nie einen Neustart machen. Falls der Kernel aktuallisiert wird sollte man einen neustart machen, aber man muss nicht (Scheint weniger als einmal pro Monat zu sein, dadd das mal einen neuen gibt. https://sources.debian.org/src/linux-latest/105+deb10u1/debian/changelog/). Services werden normalerweise automatisch neu gestartet, sollten sie zumindest (angeblich soll das sogar bei systemd gehen, aber wer weiss bei dem zeug schon, ob das geht), wenn man apt manuell aufruft fragt es manchmal sogar noch, aber von service neustarts merkt man eigentlich sowieso nie was, das läuft einfach. Bei Programmen sollte man diese halt neu starten, wenn sie geupdatet wurden, damit das Update aktiv wird, auch dort muss man das aber nicht, man kann noch bequem zuerst fertig machen woran auch immer man gerade gearbeitet hat. (Wenn man es zusätzlich nochmal öffnet greift das Update bei der neuen instanz in der regel auch, sofern die Anwendung nicht nur ein IPC Signal an den alten Prozess sendet.). Der X Server ist etwas unpraktischer, das kann man nicht restarten, ohne das sich alle damit verbundenen GUI Anwendungen beenden, aber auch hier gibt es keinen restart zwang, und updates sind dort sowieso nur alle paar Jahre mal. Wayland ist noch etwas nerviger, dort kann man den Window Manager nicht separat neu starten, aber wer nutzt das zeug schon. Die meisten der Updates sind auch garnicht sicherheitsrelevant. Und falls man sich entschliesst, doch mal den ganzen Rechner neu zu starten, dann ist das wirklich nur ein Neustart, kein "warten sie erstmal, wir machen da noch irgendwelche geheimen Updatedinge im Hintergrund."
Nano schrieb: > 2. Zweite dedizierte GPU kaufen und in den Rechner einbauen. Nein, braucht er nicht. Wenn du den Thread komplett gelesen hättest, hättest du bemerkt, dass er mit der VMware-Player-Variante alles hat, was er braucht – mit der regulären Grafikkarte. Das Problem des TE kann man mithin als erledigt betrachten. Ergänzung: > Eine alternative zum Umschalten des Eingangssignal am Monitor wäre ein > zweiter Monitor Der TE will mit Altium arbeiten. Wenn man sowieso schon zwei Monitore auf dem Tisch hat (und mithin den Platz für diese), dann glaub' mir, möchte man auch im Altium (wie in jedem andere EDA-Tool) beide gleichzeitig verwenden können. Dann hat man nämlich auf einem den Schaltplan und auf dem anderen das Layout, oder wenn das Layout noch nicht begonnen ist, auf einem den Schaltplan und auf dem anderen die Bauteilbibliothek.
:
Bearbeitet durch Moderator
Udo K. schrieb: > Das grösste Problem mit Windows dürfte sein, dass man meist > keine Admin Rechte hat, und die IT nicht wirklich für einen da ist. > Man hat keine Kontrolle. Und ich dachte schon, das größte Problem wäre die viel zu große Komplexität und die daraus folgende latente Unsicherheit, die man mit Antiviren-Schlangenöl zu bekämpfen versucht. Udo K. schrieb: > Das nächstgrössere Problem ist, dass sich - ausser Programmierer - > keiner > mit Windows beschäftigt und daher auch kein tieferes > Verständnis hat, wie man Probleme lösen kann. Sagt wer? Aber ja, dass mittlerweile nicht mal MS selbst weiß, wie man die Probleme löst, ist richtig. Udo K. schrieb: > Windows lädt auch nicht gerade dazu ein, es ist ja ein > Werkzeug, das zu funktionieren hat, und keine Spielzeug wie Linux. Es läuft zwar ein Großteil der Server in den Weiten des Internets auf Linux oder UNIX, aber wenn du das sagst... Sicher alles Spielzeug. Udo K. schrieb: > Linux hingegen sucht man sich selbst aus, in dem Wissen, dass > es erst mal viele Probleme machen wird, aber das ist ja eine > Herausforderung. Stimmt. Linux verwendet man deshalb in Industrie und IT, weil man die Herausforderung liebt. Und Windows weil es so toll ist, und nicht etwa, weil dank gutem Marketing halt ein Großteil der Endanwender-Software nur dafür released wird. Udo K. schrieb: > Wenn aber erst mal Linux in die Büros einzieht, und es zu einem > dummen Werkzeug wird, das zu funktionieren hat, > und der Frustlevel steigt, > dann wünscht man sich manchmal sein buntes Windows zurück. > (Vielleicht so geschehen in der Münchner Bürokratie...). In der Münchner Bürokratie gab es mit Linux weniger Probleme als zuvor. Der Wechsel zurück zu MS war in erster Linie eine politische Entscheidung von selbst-titulierten Microsoft-Fans, zufälligerweise gerade als Microsoft einen neuen Standort bei München eröffnete...
habe hier Mentors Expedition in einem VM Workstation Fenster laufen und das geht ohne merkliche Unterschiede. U.a. wegen inkompatibler Bibliotheken und Designs habe ich keine Lust auf neue Lizenzen und die alte Version läuft nach Windows XP definitiv nicht mehr. Sie ist aber schon älter 10 Jahre und lief bereits unter NT4.0 ganz passabel. Auf einem Laptop mit Suse hatte ich vor etwa 15 Jahre mal das Gleiche mit einer VM Workstation probiert und da hat der PCB Scroll deutlich geruckelt. Man konnte aber arbeiten, war halt nicht so smooth wie gewohnt. Ansonsten mache ich einfachere neue Designs auf Kicad und habe auch meine alte Eagle Lizenz in die Tonne getreten bzw. das Abo abbestellt. Das sind klare Rückschritte aber die V6 Vorhaben scheinen durch CERN ambitioniert. Anstelle mit Workarounds graue Haare zu kriegen kann man ja selbst Hand anlegen und es gibt immer Details die auch besser sind als vom alten Teil gewohnt. Es ist halt nicht gleich und meist findet man das auch nicht raus wenn man sich nicht drauf einlässt. Als Motivation dies zu tun: MS ist noch immer eine amerikanische Firma. Was mir da per Präsidentenerlass passieren kann ist genauso fragwürdig wie die gesetzliche Verpflichtung für chinesische Firmen der Regierung Spionagedaten beizusteuern. Daher mein (erneuter) Schwenk auf Linux. Bestimmte Dinge sind hier einfach besser - nicht alle - und andere eben auf W10 das ich noch immer gleichzeitig betreibe. https://www.heise.de/ct/artikel/Adobe-drohte-die-Abschaltung-seiner-Creative-Cloud-in-Venezuela-4563862.html
Jörg W. schrieb: > Udo K. schrieb: > >>> Sie haben ihre Abhängigkeiten insgesamt besser im Griff, und müssen >>> daher nicht für allen Krimskrams „vorsichtshalber“ gleich mal die Kiste >>> runterfahren. >> >> Ist das so? > > Warum zum Geier™ muss Windows denn sonst diese berüchtigte Ausschrift > ausspucken? Wenn du das Reboot meinst: Daran sind sind die Installationsprogramme schuld. Die meisten Anwendungen verwenden ein oder zwei zugekaufte Installationsroutinen, und die booten aus Gewohnheit, oder um auf der sicheren Seite zu sein, immer neu. Aber installiere mal aktuelle, neu entwickelte SW. Du wirst staunen. > >> Windows hat dasselbe Verhalten, > > Du hast offenbar nicht den grundsätzlichen Unterschied beider > Dateisystemkonzepte begriffen. Es ist eben etwas völlig anderes, ob ein > Verzeichniseintrag die Datei selbst beschreibt (CP/M, RSX-11, MS-DOS, > Windows, vermutlich auch VMS), oder ob er nur einen (von potenziell > vielen) Verweis auf das Dateiobjekt enthält, welches komplett unabhängig > von Verzeichniseinträgen (und damit "Dateinamen") existiert (alle > Unixe). > > Wenn du diesen Unterschied begriffen hättest, würdest du eine solche > Behauptung nicht aufstellen. Auch NTFS verwendet intern einen B-Tree mit 64 bit "Inode" Nummern (nFileIndexHigh und nFileIndexLow in https://docs.microsoft.com/en-us/windows/win32/api/fileapi/ns-fileapi-by_handle_file_information?redirectedfrom=MSDN), ähnlich wie Unix. Die Windows Inode gilt aber nur innerhalb einer Partition, Partitionen und Devices werden in Windows intern mit eindeutigen Strings angesprochen, nicht mit Nummern. Unter der Haube also nicht viel Unterschied. Diese Strings sind im Gegensatz zu den Inodes auch in einem Netzwerk eindeutig. Die Default Einstellungen von Linux sind krank, da jedes Program potentiell einem anderen Program die Datenbank unterm Hintern weglöschen/verändern kann. Das wird eine der ersten Lücken sein, auf die sich Virenschreiber stürzen werden. Unter Windows muss man für dieses Verhalten explizit beim Öffnen des Files FILE_SHARE_DELETE angeben. > > Ich habe nicht behauptet, dass es jederzeit unproblematisch ist, > entsprechende Dateien im Betrieb auf diese Weise zu ersetzen, aber es > ist eben grundsätzlich dadurch erst einmal möglich – und zwar, indem > beide Dateiversionen noch für eine gewisse Zeit parallel existieren. Was zu Inkonsistenzen und Sicherheitslücken ohne Ende in jeder komplexeren Anwendung führt! Ein 0815 Program stürzt halt ab, oder liefert einen komischen Fehler. Wen das Program aber eine 10 Millionen $ teure Industrieanlage steuert, ist das mehr als ärgerlich. > >> Unter Windows ist es schon ziemlich lange her, dass ich wegen einem >> Update neu booten musste. > > Sorry, dann machen alle meine Kollegen wohl was falsch. Sie dürfen sich > regelmäßig damit rumärgern. Na ja, sollen sie halt auf einen Kaffee gehen... fördert die Kommunikation in der Firma. Der Sysadmin kann sich in der Zwischenzeit weiterbilden, und in der Gruppenrichtlinie eintragen, dass automatische Neustarts nicht gemacht werden sollen, während der Anwender angemeldet ist...
Udo K. schrieb: > Die Default Einstellungen von Linux sind krank, da jedes Program > potentiell einem anderen Program die Datenbank unterm Hintern > weglöschen/verändern kann. > Das wird eine der ersten Lücken sein, auf die sich Virenschreiber > stürzen werden. Wenn die Aussage ernst gemeint sein sollte, empfehle ich Dir dringend, dich einmal mit Linux/Unix zu beschäftigen.
Um noch mal auf das Problem vom Max zu kommen: Ich finde die Idee eine komplexe CAD SW auf einem anderen BS laufen zu lassen schlecht. Man schichtet auf der Linux Bloatware noch mal die nachgebaute Windows Bloatware drauf, und hofft dass alles besser wird. Gründe: - Zeitaufwand - potentiellen Probleme von Linux - und potentielle Probleme der Windows Portierung - das BS ist unwichtig, man arbeitet ohnehin 95% der Zeit in der CAD SW. - Probleme mit dem Datenaustausch (die Altium Files verwenden einige sehr spezielle, hässlich komplexe und schlecht dokumentierte MS APIs um Files zu schreiben...) - keine Gewährleistung der 7000 Euro SW im Schadensfall - Als Entwickler kann ich mich nicht mal auf einen Bug in der SW ausreden, wenn ich die SW nicht in der unterstützten Umgebung verwende! - Ich kann auch nicht den Altium Support fragen, die werden nur mit der Schulter zucken und sich denken: wieder so ein *****. - Ich habe keine Gewährleistung, und auch die berufliche Haftpflicht wird nicht zahlen im Worstcase Fall. Der letzte Punkt ist zwar unwahrscheinlich und nur in sicherheitsrelevanten Branchen wichtig, aber hat potentiell hässliche Auswirkungen in komplexen Designs, wo nicht alles händisch geprüft wird. Ich erinnere dran, dass schon die Floating Point Unit unter Windows und Linux anders initialisiert wird...
Eric schrieb: > Udo K. schrieb: >> Die Default Einstellungen von Linux sind krank, da jedes Program >> potentiell einem anderen Program die Datenbank unterm Hintern >> weglöschen/verändern kann. >> Das wird eine der ersten Lücken sein, auf die sich Virenschreiber >> stürzen werden. > > Wenn die Aussage ernst gemeint sein sollte, empfehle ich Dir dringend, > dich einmal mit Linux/Unix zu beschäftigen. Hast du irgendwelche Argumente ausser der üblichen Pro Linux Polemik.
Udo K. schrieb: > Hast du irgendwelche Argumente ausser der üblichen Pro Linux Polemik. Da ich seit mehr als 25 Jahren mit Linux/BSD arbeite weiss ich die Vorteile dieser Systeme zu schätzen. Mit Polemik hat das erstmal nichts zu tun. Aber deine Aussage Udo K. schrieb: > da jedes Program > potentiell einem anderen Program die Datenbank unterm Hintern > weglöschen/verändern kann. Ist entweder scherzhaft gemeint, oder Dir fehlt tatsächlich das Grundwissen über unixoide Betriebssysteme. Denn genau dass passiert unter Linux eben nicht, weil jede wichtige Software als eigener Benutzer ausgeführt wird. Und die Datenbank hat ebenfalls mehrere Benutzer - für jedes Programm mindestens einen - so dass auch hier der Zugriff ausgeschlossen ist.
Udo K. schrieb: > Jörg W. schrieb: >> Udo K. schrieb: >> >>>> Sie haben ihre Abhängigkeiten insgesamt besser im Griff, und müssen >>>> daher nicht für allen Krimskrams „vorsichtshalber“ gleich mal die Kiste >>>> runterfahren. >>> >>> Ist das so? >> >> Warum zum Geier™ muss Windows denn sonst diese berüchtigte Ausschrift >> ausspucken? > > Wenn du das Reboot meinst: > > Daran sind sind die Installationsprogramme schuld. > Die meisten Anwendungen verwenden ein oder zwei zugekaufte > Installationsroutinen, Bei meinem Win7 kommt das von Windows (Update) selbst. Weil es ja, wie du selbst geschrieben hast, Dateien ersetzen muss, die in Benutzung sind. > Aber installiere mal aktuelle, neu entwickelte SW. Du wirst staunen. Ändert halt nix an den WindowsUpdates. > Die Default Einstellungen von Linux sind krank, da jedes Program > potentiell einem anderen Program die Datenbank unterm Hintern > weglöschen/verändern kann. > Das wird eine der ersten Lücken sein, auf die sich Virenschreiber > stürzen werden. Wenn Linux jetzt neu und unverbreitet wäre würde ich das glauben. > Was zu Inkonsistenzen und Sicherheitslücken ohne Ende > in jeder komplexeren Anwendung führt! > Ein 0815 Program stürzt halt ab, oder liefert einen komischen Fehler. > Wen das Program aber eine 10 Millionen $ teure Industrieanlage steuert, > ist das mehr als ärgerlich. Deshalb stürzt es früher oder später trotzdem ab oder liefert einen komischen Fehler. Die Auswirkungen sind halt größer. Und behaupte jetzt nicht, das Win da fehlerfrei ist.
Udo K. schrieb: > Um noch mal auf das Problem vom Max zu kommen: … das er gar nicht mehr hat inzwischen. > Ich finde die Idee eine komplexe CAD SW auf einem anderen > BS laufen zu lassen schlecht. Gut. Andere finden sie nicht schlecht. > Man schichtet auf der Linux Bloatware noch mal die nachgebaute > Windows Bloatware drauf, und hofft dass alles besser wird. Nein, man hofft nicht, sondern weiß es. :-) Es gibt ja Leute (wie mich), die das schon eine Weile so machen. Das Windows wird dabei übrigens sogar schneller. Der Grund? Ganz einfach: indem ich das Windows nicht mehr am Netz habe, sondern nur noch einen sehr expliziten und gezielten Übergabepunkt, kann ich mir den Virenscanner klemmen. > Gründe: > > - Zeitaufwand Einmal-Investition. Habe ich vor 5 Jahren getätigt, seitdem weniger als einen Arbeitstag in die Wartung investiert (hauptsächlich zwischenzeitliches Upgrade von VMware). > - potentiellen Probleme von Linux "Potenzielle" Probleme hast du sowieso immer. Die realen halten sich in Grenzen. > - und potentielle Probleme der Windows Portierung Welche Portierung? Da ist nichts portiert. > - das BS ist unwichtig, man arbeitet ohnehin 95% der Zeit in der CAD SW. Nein. Ich arbeite 95 % der Zeit mit Compilern, allein dafür ist der Geschwindigkeitsunterschied beim Compilieren so erheblich (wenn man beide auf gleiche Hardware loslässt), dass mir das wohl schon genug reale Einsparung gebracht hat. Keine Ahnung, warum das so ist, eventuell ist es ja „nur“ der Virenscanner (der jede Assembler- und Objektdatei des Compilers ja auf Viren testet), vielleicht auch was anderes. Ich muss da aber keinen Aufwand in irgendeine Analyse investieren. No Windows, no problem. Ganz davon abgesehen, ich arbeite nun seit fast 30 Jahren mit Unixen, ich bin da wirklich um Welten schneller in allem, was ich damit mache. Ich erhebe natürlich nicht den Anspruch, dass anderen das genauso geht. Das fängt bei mir schon bei einem vernünftig funktionierenden focus-follows-mouse an. (Ich weiß, geht unter Windows auch, habe ich wegen Altium sogar aktiviert, aber ist im Vergleich zu meinem fvwm einfach nur gruselig zu benutzen. Dass das dort sonst niemand groß benutzen will, kann ich voll und ganz verstehen.) > - Probleme mit dem Datenaustausch > (die Altium Files verwenden einige sehr spezielle, hässlich komplexe > und schlecht dokumentierte MS APIs um Files zu schreiben...) Welchen Datenaustausch? Das Altium muss sich doch praktisch nur mit sich selbst verstehen. Davon abgesehen, ein-, zweimal hatten wir auch schon Contractors, die uns Altiumprojekte zugearbeitet haben. Das Einzige, was dabei nicht funktioniert hat, war so ein Draftsman-Dokument, weil AD16 das von AD17 generierte hier nicht schlucken wollte. Aber da war eh verzichtbar, der Contractor wollte das nur mal ausprobieren. > - keine Gewährleistung der 7000 Euro SW im Schadensfall Hast du jemals für irgendeine Software erfolgreich einen Gewährleistungsanspruch geltend gemacht? > Ich erinnere dran, dass schon die Floating Point Unit unter Windows > und Linux anders initialisiert wird... ???
:
Bearbeitet durch Moderator
Udo K. schrieb: > Eric schrieb: >> Udo K. schrieb: >>> Die Default Einstellungen von Linux sind krank, da jedes Program >>> potentiell einem anderen Program die Datenbank unterm Hintern >>> weglöschen/verändern kann. >>> Das wird eine der ersten Lücken sein, auf die sich Virenschreiber >>> stürzen werden. >> >> Wenn die Aussage ernst gemeint sein sollte, empfehle ich Dir dringend, >> dich einmal mit Linux/Unix zu beschäftigen. > > Hast du irgendwelche Argumente ausser der üblichen Pro Linux Polemik. Gegenfrage, hast du was anderes zu bieten außer deinen abstrusen Behauptungen? Würde sich da tatsächlich ein Problem darstellen, warum hat das noch niemand ausgenutzt? Linux-Server wären ein lohnendes Ziel... Aber du weißt halt nix über das Unix-Rechtesystem. Udo K. schrieb: > Jörg W. schrieb: >> Udo K. schrieb: >> >>>> Sie haben ihre Abhängigkeiten insgesamt besser im Griff, und müssen >>>> daher nicht für allen Krimskrams „vorsichtshalber“ gleich mal die Kiste >>>> runterfahren. >>> >>> Ist das so? >> >> Warum zum Geier™ muss Windows denn sonst diese berüchtigte Ausschrift >> ausspucken? > > Wenn du das Reboot meinst: > > Daran sind sind die Installationsprogramme schuld. > Die meisten Anwendungen verwenden ein oder zwei zugekaufte > Installationsroutinen, > und die booten aus Gewohnheit, > oder um auf der sicheren Seite zu sein, > immer neu. > > Aber installiere mal aktuelle, neu entwickelte SW. Du wirst staunen. Äh, was hat das nunmal mit den Leidigen Update-Reboots zu tun?
Eric schrieb: > Udo K. schrieb: >> Hast du irgendwelche Argumente ausser der üblichen Pro Linux Polemik. > > Da ich seit mehr als 25 Jahren mit Linux/BSD arbeite weiss ich die > Vorteile dieser Systeme zu schätzen. Mit Polemik hat das erstmal nichts > zu tun. Ich sage ja nicht dass Linux schlecht oder unbrauchbar ist. Mir ist es auch herzlich egal, unter welchem BS irgendwas läuft. Wichtig ist, das es was sinnvolles macht, und dafür braucht es erfahrene Leute und getestete Software. Beides ist auf allen OS der Welt zu finden. Wenn aber eine komplexe Software XYZ auf Linux entwickelt worden ist, und ich XYZ dann auf Windows laufen lassen möchte, dann habe ich erst mal viele Probleme und schlechte Performance. Wenn die SW komplex ist, dann gibt es neben der Aussage läuft oder läuft nicht auch noch sehr viele "aber". Und ja, ich habe das schon gemacht, und weiss auch wovon ich rede... > > Aber deine Aussage > > Udo K. schrieb: >> da jedes Program >> potentiell einem anderen Program die Datenbank unterm Hintern >> weglöschen/verändern kann. > > Ist entweder scherzhaft gemeint, oder Dir fehlt tatsächlich das > Grundwissen über unixoide Betriebssysteme. > Denn genau dass passiert unter Linux eben nicht, weil jede wichtige > Software als eigener Benutzer ausgeführt wird. > Und die Datenbank hat ebenfalls mehrere Benutzer - für jedes Programm > mindestens einen - so dass auch hier der Zugriff ausgeschlossen ist. Anstatt zu unterstellen, das ich ja ein Dorftrottel wäre, könntest du auch mit harten Fakten argumentieren? Genau das passiert wenn ich rm -rf /etc/* eintippe. Ja sicher kann man alles mit Zugriffsrechten absichern, nur das war ja nicht die Frage. Es ging drum, ob das Überschreiben von Files im laufenden Betrieb eine gute Idee ist, oder eher nicht. Ich meine, das das keine gute Idee ist.
Udo K. schrieb: > Genau das passiert wenn ich rm -rf /etc/* eintippe. Du bekommst eine Latte an Fehlermeldungen, das die Datei(en) mangels Rechten nicht gelöscht werden konnten. Root wird dies nicht tun, denn der weis ja, was dies bedeuten würde.
Udo K. schrieb: > Ich meine, das das keine > gute Idee ist. Deine Meinung ist dir natürlich unbenommen. 4.4BSD hatte versucht, mit den file flags (bspw. "immutable") das Gefahrenpotenzial in dieser Hinsicht zu reduzieren. Wenn das System in einem erhöhten Securelevel läuft, dürfen derartige Dateien nicht mehr modifiziert werden. Der Securelevel lässt sich ohne Reboot nur erhöhen, nicht verringern. So gab es auch noch append-only als Flag (für Logfiles). In der Praxis hat das niemand benutzt, denn man hätte damit deutlich häufigere Reboots erzwingen müssen, bspw. um Logfiles zu rotieren. War dann wohl doch zu unhandlich. MacOS hat nun etwas ähnliches für einen Teil der Dateisystemhierarchie implementiert, den sie als extrem lebenswichtig für das OS kennzeichnen. Dort gestatten sie eine Modifikation nur, wenn das aktuell laufende System nicht von der gleichen Partition gebootet worden ist wie die zu ändernden Dateien. Auch hier wird, allerdings eben nur für wichtige Systemdateien, ein Reboot erzwungen, wenn man Updates machen möchte. Für einen PC (wir erinnern uns, dass das Ding ja ein "persönlicher Computer" ist) mag das gehen, für einen Server würde ich das nicht haben wollen. Ist halt ein tradeoff zwischen Sicherheit und Bequemlichkeit / Ausfallzeit. In der Praxis scheint sich der Schaden, der durch versehentliche oder vorsätzlich böswillig gelöschte oder überschriebene wichtige Dateien oder Datenbanken entsteht, doch recht arg in Grenzen zu halten.
Jörg W. schrieb: > Nano schrieb: >> 2. Zweite dedizierte GPU kaufen und in den Rechner einbauen. > > Nein, braucht er nicht. Wenn du den Thread komplett gelesen hättest, > hättest du bemerkt, dass er mit der VMware-Player-Variante alles hat, > was er braucht – mit der regulären Grafikkarte. Das Problem des TE kann > man mithin als erledigt betrachten. Ich habe den Thread nicht komplett gelesen, allerdings ist die VMware-player Variante nur eine Softwarelösung, das kann gut funktionieren, muss es aber nicht. Wenn er die volle GPU Geschwindigkeit haben will, dann ist eine dedizierte GPU, abgesehen von dem Punkt das es wegen dem Umschalten umständlicher ist, die bessere Wahl. > Ergänzung: > >> Eine alternative zum Umschalten des Eingangssignal am Monitor wäre ein >> zweiter Monitor > > Der TE will mit Altium arbeiten. Wenn man sowieso schon zwei Monitore > auf dem Tisch hat (und mithin den Platz für diese), dann glaub' mir, > möchte man auch im Altium (wie in jedem andere EDA-Tool) beide > gleichzeitig verwenden können. Dann hat man nämlich auf einem den > Schaltplan und auf dem anderen das Layout, oder wenn das Layout noch > nicht begonnen ist, auf einem den Schaltplan und auf dem anderen die > Bauteilbibliothek. Ich habe nirgends gesagt, dass er nur einen Monitor nutzen soll. Sondern wenn er nicht umschalten möchte, dass er auch einen separaten Monitor ansteuern kann. Wenn er also für Altium zwei Monitore für Windows haben will und nicht umschalten will, dann braucht er halt noch zwei zusätzliche Monitore. Oder er muss mit umschalten, dann halt zwei umschalten. Und wenn er n Monitore haben will, dann heißt es eben auf n Monitoren umschalten oder n Monitore zusätzlich kaufen und an die dedizierte GPU anschließen. Prinzipiell könnte er auch einen zweiten Tisch hinstellen, dann da seine n Monitore anschließen und zusätzlich noch eine USB Tastatur und Maus allein für die VM aufstellen, das geht auch.
Udo K. schrieb: > Die Default Einstellungen von Linux sind krank, da jedes Program > potentiell einem anderen Program die Datenbank unterm Hintern > weglöschen/verändern kann. > Das wird eine der ersten Lücken sein, auf die sich Virenschreiber > stürzen werden. Auch Windows hat keine Trennung der Rechte pro Anwendung, sondern auch da sind alle Daten des Nutzers unter seinem Nutzeraccount mit seinen Rechten zugänglich. Eine echte Trennung der Nutzerdaten auf Anwendungsebene gibt es momentan meines Wissens nach nur bei Android. Bei den Systemen von Apple weiß ich es nicht. > Unter Windows muss man für dieses Verhalten explizit beim Öffnen des > Files > FILE_SHARE_DELETE angeben. Und das soll jetzt inwiefern ein Hindernis für Prozess A sein, um die Nutzdaten von Prozess B zu verändern?
Nano schrieb: > Wenn er die volle GPU Geschwindigkeit haben will, dann ist eine > dedizierte GPU, abgesehen von dem Punkt das es wegen dem Umschalten > umständlicher ist, die bessere Wahl. Naja. Es ging hier nicht um ein Ballerspiel, sondern um ein EDA-Tool. Das braucht den 3D-Modus vor allem, weil sich damit viele Zeichenprimitiven der Boarddarstellung effizienter lösen lassen, siehe auch Horizon und seine Mindestanforderungen. Ansonsten noch für die 3D-Boarddarstellung, aber die braucht man doch eher selten. Da wird also eh keine "Spiele-Performance" in irgendeiner Form benötigt, sondern nur, dass es insgesamt überhaupt und stabil funktioniert, das 3D-API von Windows auf den Host abzubilden. Das bekommt VMware gut (genug) hin. Dafür muss man sich nicht den Arbeitsplatz mit Monitoren zunageln. :)
Jörg W. schrieb: > Nein. Ich arbeite 95 % der Zeit mit Compilern, allein dafür ist der > Geschwindigkeitsunterschied beim Compilieren so erheblich (wenn man > beide auf gleiche Hardware loslässt), dass mir das wohl schon genug > reale Einsparung gebracht hat. Keine Ahnung, warum das so ist, > eventuell ist es ja „nur“ der Virenscanner (der jede Assembler- und > Objektdatei des Compilers ja auf Viren testet), vielleicht auch was > anderes. Ich muss da aber keinen Aufwand in irgendeine Analyse > investieren. No Windows, no problem. Man kann die Buildverzeichnis vom Virencheck herausnehmen. Das kann man in der Antivirensoftware in der Regel einstellen. Das geht natürlich nur mit der Pro Version, die kostenlosen privat Editions können das in der Regel nicht, aber wer auf dem Rechner kommerziell arbeitet, der muss sowieso die kostenpflichtige Version verwenden. Die private Edition ist nur für die private Nutzung erlaubt. @TS Das gilt übrigens auch für den Threadstarter und VMWare Player. Wenn er Altrium kommerziell nutzt, dann braucht er eine gewerbliche VMWare Lizenz, wenn er VMWare nutzen möchte.
Nano schrieb: > Man kann die Buildverzeichnis vom Virencheck herausnehmen. Kann man. Allerdings muss man dafür die Buildverzeichnisse (vor allem die temporären) erstmal kennen. Dann muss man rausfinden, wo und wie man das konfiguriert. Da ist mir die VM jedoch lieber, bei der man den ganzen Zirkus mangels Netzwerkzugriff (und mangels entsprechender Nutzung für Webbrowsen, Mails lesen etc.) gar nicht erst braucht – muss ich keine Zeit in solch unproduktive Dinge investieren. :-)
Jörg W. schrieb: > Nano schrieb: >> Wenn er die volle GPU Geschwindigkeit haben will, dann ist eine >> dedizierte GPU, abgesehen von dem Punkt das es wegen dem Umschalten >> umständlicher ist, die bessere Wahl. > > Naja. Es ging hier nicht um ein Ballerspiel, sondern um ein EDA-Tool. Das weiß ich und das ist umso mehr ein Grund eine dedizierte GPU zu verwenden. Weil die Softwarelösung Treiber auf dem Gastsystem benötigt und diese Softwarelösung für Spiele optimiert werden. Es heißt nicht umsonst VMWare Player. Es kann natürlich sein, dass die EDA Suite nur einen Bruchteil der Direct3d oder OpenGL Funktionen verwendet und das dann mit diesen "Spiele" Treibern problemlos läuft. Optimiert sind die darauf aber nicht und eine Funktionsgarantie hat man ohnehin nicht. Will man dem aus dem Weg gehen, dann ist die dedizierte GPU das Mittel der Wahl, weil man dann die für die GPU geschriebenen Originaltreiber von bspw. NVidia oder AMD nehmen kann, je nach Hersteller der GPU natürlich. > Das bekommt VMware gut (genug) hin. Dafür muss man sich nicht den > Arbeitsplatz mit Monitoren zunageln. :) Ja, wie schon gesagt, das mag ausreichen, muss es aber nicht. Wenn er Altium in einer WMWare Player Umgebung gewerblich verwenden möchte, dann braucht er meines Wissens nach zudem noch eine kostenpflichtige Lizenz von WMWare Player, ansonsten gilt das wie nicht lizensiert.
Udo K. schrieb: > Genau das passiert wenn ich rm -rf /etc/* eintippe. > > Ja sicher kann man alles mit Zugriffsrechten absichern, nur das war > ja nicht die Frage. Natürlich ist genau das die Frage, denn genau aufgrund der Zugriffsrechte wird nix schlimmes passieren. Nano schrieb: > Man kann die Buildverzeichnis vom Virencheck herausnehmen. > Das kann man in der Antivirensoftware in der Regel einstellen. > Das geht natürlich nur mit der Pro Version, die kostenlosen privat > Editions können das in der Regel nicht, aber wer auf dem Rechner > kommerziell arbeitet, der muss sowieso die kostenpflichtige Version > verwenden. Es stellt sich die Frage, warum überhaupt derartiges Schlangenöl verwenden?
Nano schrieb: > Das weiß ich und das ist umso mehr ein Grund eine dedizierte GPU zu > verwenden. Weil die Softwarelösung Treiber auf dem Gastsystem benötigt > und diese Softwarelösung für Spiele optimiert werden. Huh? > Es heißt nicht umsonst VMWare Player. Das hat völlig andere (historische) Hintergründe. Früher konnte man mit dem "Player" nur vorab mit der vollen Version von VMware Workstation erzeugte und exportierte VMs "abspielen". Irgendwann haben sie dann den Player so weit aufgebohrt, dass er nun praktisch eine leicht abgerüstete Variante der normalen Workstation-Version ist, bspw. kann man damit keine disk snapshots anlegen. Mit "playing games" hat das Dingens nun wirklich nichts zu tun. > Ja, wie schon gesagt, das mag ausreichen, muss es aber nicht. Es mag nicht bloß, es reicht. Mach ich nun seit Jahren so, und der TE war nach der Umstellung von Virtualbox auf VMware ja auch zufrieden mit der Performance. > Wenn er Altium in einer WMWare Player Umgebung gewerblich verwenden > möchte, dann braucht er meines Wissens nach zudem noch eine > kostenpflichtige Lizenz von WMWare Player, ansonsten gilt das wie nicht > lizensiert. Du wiederholst dich – und das hatten wir oben sowieso schon geklärt, dass das Teil nur für private Nutzung frei ist. Wenn man es kommerziell nutzen will, sollte man eh die paar Euro mehr ausgeben und nicht bloß den Player, sondern die volle Version kaufen. Gerade Snapshots sind ein Feature, das einem schnell mal das Gesäß retten kann. Man muss sich dann nicht dreimal überlegen, ob man irgendeine Demoversion von irgendwas im Gast installiert oder nicht oder ob die einem ggf. hinterher unliebsame Spuren hinterlässt – einfach einen Snapshot anlegen, installieren, ausprobieren, danach Snapshot zurückleiern, alles wieder wie zuvor.
Jörg W. schrieb: > Nano schrieb: > >> Das weiß ich und das ist umso mehr ein Grund eine dedizierte GPU zu >> verwenden. Weil die Softwarelösung Treiber auf dem Gastsystem benötigt >> und diese Softwarelösung für Spiele optimiert werden. > > Huh? Windows 10 liefert die für VMWare schon mit. Bei Virtualbox müsste man die noch separat installieren. Für KVM gibt es auch schon welche. Guck einfach mal in den Gerätemanager und schaue, was da als Treiber für die GPU läuft, die Windows in der VM meint vor sich zu haben. > Mit "playing games" hat das Dingens nun wirklich nichts zu tun. Als solches wird es aber inzwischen beworben. Das hat auch damit etwas zu tun, dass diese 3d Softwaretreiber eben immer besser geworden sind und nun auch viele Spiele damit relativ gut funktionieren sollen. > >> Ja, wie schon gesagt, das mag ausreichen, muss es aber nicht. > > Es mag nicht bloß, es reicht. Mach ich nun seit Jahren so, und der TE > war nach der Umstellung von Virtualbox auf VMware ja auch zufrieden mit > der Performance. Er hätte für die Virtualbox noch die Gastsystemtreiber installieren müssen. Die muss man separat downloaden, da die bei Windows nicht mitgeliefert werden. Die sind auf der Webseite von virtualbox verfügbar. Zu beachten ist allerdings, dass diese noch längst nicht so ausgereift und gut sind, wie die für VMWare. VMWare funktioniert in dieser Hinsicht immer noch besser und Virtualbox muss da noch nachholen. Das gleiche gilt für KVM + QEMU. > Du wiederholst dich – und das hatten wir oben sowieso schon geklärt, > dass das Teil nur für private Nutzung frei ist. Ok, ich bin in den Thread später eingestiegen und habe nicht alles gelesen.
Nano schrieb: > Guck einfach mal in den Gerätemanager und schaue, was da als Treiber für > die GPU läuft, die Windows in der VM meint vor sich zu haben. Ja, natürlich VMware, anders kann es ja nicht gehen. > Er hätte für die Virtualbox noch die Gastsystemtreiber installieren > müssen. Ich gehe davon aus, dass man das beim Aufsetzen eines Gastes sowieso als erstes tut. Ohne 3D-Grafiktreiber wäre Altium gar nicht gelaufen. So lief es ja lediglich zäh. > Zu beachten ist allerdings, dass diese noch längst nicht so ausgereift > und gut sind, wie die für VMWare. Genau da liegt offenbar der Hase im Pfeffer.
>Er hätte für die Virtualbox noch die Gastsystemtreiber installieren >müssen. > ... >Ok, ich bin in den Thread später eingestiegen und habe nicht alles >gelesen. Das hätest Du aber mal machen sollen, sonst würdest Du nicht stämndig im Trüben fischen, und dem TO empfehlen, was er bereits im ersten Post als erledigt abgehakt hat. Denn der TO schrieb anfangs: >Ich hab schon GuestAdditions von VirtualBox installiert, RAM + CPU >hochgeschraubt aber so wirklich geholfen hat das alles nichts.
Jörg W. schrieb: > Nein. Ich arbeite 95 % der Zeit mit Compilern, allein dafür ist der > Geschwindigkeitsunterschied beim Compilieren so erheblich (wenn man > beide auf gleiche Hardware loslässt), dass mir das wohl schon genug > reale Einsparung gebracht hat. Keine Ahnung, warum das so ist, > eventuell ist es ja „nur“ der Virenscanner (der jede Assembler- und > Objektdatei des Compilers ja auf Viren testet), vielleicht auch was Das hat etwas mit der Funktionsweise des GCC (eventuell andere Compiler auch) und der Dateisysteme unter Linux / Windows zu tun. Der GCC arbeitet sehr viel mit temporären Dateien. Windows schreibt Dateien im Allgemeinen immer direkt auf die Festplatte. (Sobald der Schreibvorgang beginnt) Man kennt das von USB-Sticks, selbst ohne die explizit auszuwerfen kann man die unter Windows meist direkt nach dem Kopiervorgang abziehen und die Daten sind trotzdem drauf. Bei Linux ist das anders. Dort landen die Daten erst mal im RAM und die Festplatte rührt sich überhaupt überhaupt nicht. Typischerweise beginnt Linux erst nach einigen Sekunden mit den Festplattenzugriffen. Da der GCC die temporären Dateien nur kurzzeitig anlegt und dann dann alsbald wieder löscht, kommt es unter Linux meist zu gar keinen Festplattenzugriffen, da die Dateien schon wieder gelöscht wurden bevor sie überhaupt auf die Platte geworfen wurden. Unter Windows werden diese "brav" geschrieben und wieder gelöscht. Dadurch werden unter Windows die übrigen Festplattenzugriffe (Include Dateien, C Dateien, Objektdateien) verlangsamt, unter Linux kaum. Dazu kommt, dass das "/tmp" unter Linux heute oftmals gleich direkt eine RAM Disk ist (tmpfs).
Andreas M. schrieb: > Dazu kommt, dass das "/tmp" unter Linux heute oftmals gleich direkt eine > RAM Disk ist (tmpfs). Das könnte Windows auch – das ist also überhaupt kein Argument…
Uhu U. schrieb: > Andreas M. schrieb: >> Dazu kommt, dass das "/tmp" unter Linux heute oftmals gleich direkt eine >> RAM Disk ist (tmpfs). > > Das könnte Windows auch – das ist also überhaupt kein Argument… Wobei das Thema "RAM Disk" doch ein reichlich historisches ist. Das hat man damals mal befeuert als noch Festplattenzugriffe grottenlahm waren. Heutzutage gibt es ultra schnelle SSDs. Da braucht es sowas wie eine "RAM Disk" nun wirklich nicht mehr (allenfalls für die Fortschrittsverweigerer). ;)
Andreas M. schrieb: > (Sobald der Schreibvorgang > beginnt) Man kennt das von USB-Sticks, selbst ohne die explizit > auszuwerfen kann man die unter Windows meist direkt nach dem > Kopiervorgang abziehen und die Daten sind trotzdem drauf. Das kannst Du nur weil ein USB-Stick unter Windows per Default (sofern nicht vom Benutzer anders konfiguriert) mit der Option "sync" (oder dem Windows-Äquivalent davon) gemountet wird. Das kann man auch abschalten wenn man will. Und für interne HDD ist das standardmäßig sowieso abgeschaltet, hier cached Windows genauso aggressiv wie Linux auch. Daß es trotzdem langsamer ist liegt einfach daran daß Dateioperationen unter Windows halt einfach generell um Größenordnungen langsamer sind als bei vernünftigen Betriebssystemen, der Teufel allein weiß warum das so ist.
:
Bearbeitet durch User
Naja schrieb: > Wobei das Thema "RAM Disk" doch ein reichlich historisches ist. Das hat > man damals mal befeuert als noch Festplattenzugriffe grottenlahm waren. > Heutzutage gibt es ultra schnelle SSDs. Da braucht es sowas wie eine > "RAM Disk" nun wirklich nicht mehr (allenfalls für die > Fortschrittsverweigerer). > > ;) Ultraschnell? Mein RAM schafft 34GB/s Zeig mir bitte mal eine SSD die das kann.
Andreas M. schrieb: > Mein RAM schafft 34GB/s Zeig mir bitte mal eine SSD die das kann. Der Compiler muss den Salat ja auch erstmal produzieren, insofern dürfte der praktische Unterschied minimal sein. Eine RAM-Disk ist eigentlich eh' nur RAM-Verschwendung, da sie den dafür dedizierten RAM von der on-demand-Aufteilung entzieht. Wie schon genannt worden ist, kurzlebige Dateien profitieren hinreichend vom RAM als Cache. Das dürfte zumindest auf die Assembler-Zwischendateien zutreffen – Objektdateien können in etwas größeren Projekten schon ein bisschen länger leben, bis sie dem Linker präsentiert werden. Außerdem bleiben sie im Allgemeinen hinterher stehen. Aber wir bewegen uns mächtig vom Thema weg, und das Beispiel mit dem unter Unixen deutlich schnelleren Compilieren war eh nur einer meiner Punkte, warum ich Windows lieber als Sekundär-OS denn als primäres haben will (und der TE offensichtlich ja auch, um den Bogen mal wieder zu schließen :).
:
Bearbeitet durch Moderator
[OT] Arno schrieb: > Andreas M. schrieb: >> Reinhard S. schrieb: >>> Jörg W. schrieb: >>>> Eben. Beispielsweise durch Warten auf "Bitte schalten Sie den Computer >>>> nicht aus". :-)) >>> >>> Im Ernst: Worauf sollte ich da warten? Der Computer schaltet sich dann >>> selbst aus. >> >> Immer wieder erfreulich am Ende des Arbeitstags wenn man das Notebook >> mit nach Hause nimmt/nehmen muss. Ist man eh shon spät dran, beglückt >> einen das Windows dann mit "1 von 50 Updates werden installiert..," > > Und wenn man die Kiste am nächsten Morgen wieder anmacht, dauert es > gerade mal einen halben Tag, bis sie wieder neu starten will... Muss mich korrigieren: Das war eine "Fehlbedienung" meinerseits - offenbar ist für Windows 10 "Herunterfahren" und "Wieder einschalten" nicht das gleiche wie "Neu starten", was die Installation von Updates angeht...[/OT] MfG, Arno
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.