Hallo wie der Betreff schon sagt. Aktuellen Nightly gezogen, Installer sagt Minimum Windows 8.1. Gibt es irgendeinen Workaround, oder kann mir jemand einen triftigen Grund sagen warum Windows 7 nicht mehr supported ist. Das Nightly von Februar 2021 ging problemlos.
https://forum.kicad.info/t/windows-7-soon-to-be-no-longer-functional-for-6-0/27149 KiCad nutzt jetzt Python 3.8 für Windows, und das ist nicht länger kompatibel mit Windows 7.
Na dann "schönen Dank" an die Entwickler, nur wegen der Scriptsprache mein liebstes OS nicht mehr zu unterstützen. Und der süffisante Satz ein up-to-date OS zu verwenden können sie sich sonstwohin schieben. Wenn das etwas angepisst klingt, liegt das daran daß ich angepisst bin.
Gerader Ast schrieb: > Wenn das etwas angepisst klingt, liegt das daran > daß ich angepisst bin. Ich stimme dir zu 10000 % zu. Dann sollen sie den Mist behalten. Ich kann mit meinen KiCad unter Win-7 alles machen was ich will.
Gerader Ast schrieb: > Und der süffisante Satz ein up-to-date OS zu verwenden können sie sich > sonstwohin schieben. Zeit, auf Linux umzusteigen. Nur mal als Denkanstoß. ;-)
Bei mir läuft die letzte funktionierende KiCad-Version unter Win XP, da geht auch alles was ich brauche.
Gerader Ast schrieb: > Na dann "schönen Dank" an die Entwickler, nur wegen der Scriptsprache > mein liebstes OS nicht mehr zu unterstützen. Du musst die Scriptsprache nicht benutzen. Aussage aus dem Thread: "People will always be able to build KiCad with Python disabled if they really need to get it up and running on an obsolete system. We just don’t want to support that officially." "Yep, the check is put into the kicad codebase for the compilation of kicad + python3.8 or above." Das Einzige ist, dass du dir dann entweder jemanden suchen musst, der es dir compiliert oder es dir einfach selbst compilierst. Die Welt wird sich natürlich trotzdem weiter drehen.
Jörg W. schrieb: > Das Einzige ist, dass du dir dann entweder jemanden suchen musst, der es > dir compiliert oder es dir einfach selbst compilierst. Wieder einmal die Arroganz schlechthin! Wieso gibt es kein Prebuild? Ich bezweifel dass Windows-Nutzer problemlos eine Umgebung aufsetzen können um KiCad für Win7 zu compillieren... Und da schimpft noch einer auf Eagle oder Target...
BrownCoat schrieb: > Wieso gibt es kein Prebuild? Es gibt eins, nur halt nicht mehr für Windows 7. (Also nicht für die nächste Version. 5.x wirst du wohl auch weiterhin dafür bekommen.) > Ich > bezweifel dass Windows-Nutzer problemlos eine Umgebung aufsetzen können > um KiCad für Win7 zu compillieren... Warum sollten Windows-Nutzer dööfer sein als Nutzer anderer Betriebssysteme? Oder was genau wolltest du damit ausdrücken?
Jörg W. schrieb: > Warum sollten Windows-Nutzer dööfer sein als Nutzer anderer > Betriebssysteme? Oder was genau wolltest du damit ausdrücken? Ja, was wollte ich damit ausdrücken? Jedenfalls nicht das was du wieder verstanden hast! Aber wenn ein Win7-Nutzer das hinbekommt, wird er vorher ein Linux sekundär installieren und da dann KiCad nutzen. Oder Jörg, findest du etwa das Win7-Nutzer doof sind?
BrownCoat schrieb: > Oder Jörg, findest du etwa das Win7-Nutzer doof sind? Nein, aber ich kann auch nicht verstehen, warum unterstellt wird, dass Windows-Nutzer zu blöd seien, einen Compiler zu installieren und zu bedienen. Anders als noch vor 10, 15 Jahren bekommt man ja mittlerweile auch die Microsoft-Compiler kostenlos.
Jörg W. schrieb: > Gerader Ast schrieb: >> Na dann "schönen Dank" an die Entwickler, nur wegen der Scriptsprache >> mein liebstes OS nicht mehr zu unterstützen. > > Du musst die Scriptsprache nicht benutzen. Naja, manchmal ist Scripting auch beim Layouten schon hilfreich, selbst wenn man es in Python machen muss. Für mich stellt sich eher die Frage warum man unbedingt auf Python 3.9 umsteigen musste, bzw. (und das trifft den Punkt eigentlich genauer) warum Python 3.9 win7 nicht mehr unterstützt. Es war bis jetzt ja immer ein Alleinstellungsmerkmal das man mit Open-Source Tools sehr lange auch ältere Systeme weiterbenutzen konnte. GNU Autoconf et. al. schaffen das ja eigentlich ganz gut. Warum das nun beiPython auf Win7 nicht funktioniert? kA.^^ /regards
Andreas H. schrieb: > Für mich stellt sich eher die Frage warum man unbedingt auf Python 3.9 > umsteigen musste, 3.8 > bzw. (und das trifft den Punkt eigentlich genauer) > warum Python 3.9 win7 nicht mehr unterstützt. Keine Ahnung, aber ehrlich gesagt habe ich auch keine Ahnung, was sich API-mäßig zwischen Windows 7 und 8 überhaupt geändert hat. Vielleicht ließe sich das ja auch mit irgendwelchen Abstrichen noch unter Win7 compilieren und die Python-Maintainer haben auch nur keine Lust, noch Packages für ein OS zu pflegen, das vom Hersteller nicht mehr supportet wird?
Das mit Python ist mir auch schleierhaft, warum das unter Windows 7 nicht mehr funktionieren soll. Und daß Windows 7 nicht mehr unterstützt wird von Microsoft stimmt ja auch nur halb, es gibt noch regelmäßige Defender-Updates und den Edge Chromium haben sie (auch) als für Windows 7 empfohlene Variante des Edge Browsers entwickelt, und der wird regelmäßig upgedatet. Zu der Empfehlung KiCAD selber zu compilieren, ich glaube das übersteigt den Aufwand oder Wissensstand vieler Nutzer, denn oft ist bei OSS entweder ein exotischer Compiler oder Tools vonnöten um das zu machen. Und bei einem Paket von 1GB Installer-Größe dürfte ja auch einiges an Quelltext zusammenkommen. Naja vielleicht eine Chance für Horizon ;-)
Gerader Ast schrieb: > Na dann "schönen Dank" an die Entwickler, nur wegen der Scriptsprache > mein liebstes OS nicht mehr zu unterstützen. > Und der süffisante Satz ein up-to-date OS zu verwenden können sie sich > sonstwohin schieben. Wenn das etwas angepisst klingt, liegt das daran > daß ich angepisst bin. Weißt was Leute auch anpissen kann. Zu fordern Systeme zu unterstützen die nicht mal der Hersteller mehr unterstützt. KiCad supported Windows/Ubuntu/Debian/Mac so lange diese vom Hersteller supported werden, und danach hat man einfach das Nachsehen. Warum sollte man sich wegen Nachzügler bei der Entwicklung ausbremsen lassen. Als nächstest kommt wer mit Windows XP oder noch älter daher. Alte Systeme zu unterstützen ist Mehraufwand und bremst nur die Entwicklung aus. KiCad 5 (mit Python 2 das auch schon EOL ist) wird ja weiterhin laufen. Hört sich jetzt gemein an, aber wenn du unbedingt KiCad 5.99 auf Windows 7 möchtest muss du oder jemand anderer sich die Mühe machen es dafür zu Kompilieren. Deine Situation wird sich über die Zeit nur weiter verschlechtern, auch bei andere Software. Von fehlenden Sicherheitspatches ganz zu schweigen.
BrownCoat schrieb: > Jörg W. schrieb: > >> Das Einzige ist, dass du dir dann entweder jemanden suchen musst, der es >> dir compiliert oder es dir einfach selbst compilierst. > > Wieder einmal die Arroganz schlechthin! Wieso gibt es kein Prebuild? Ich > bezweifel dass Windows-Nutzer problemlos eine Umgebung aufsetzen können > um KiCad für Win7 zu compillieren... > > Und da schimpft noch einer auf Eagle oder Target... Ist es denn nicht auch ein bisschen bescheuert, eine flammaktuelle Software -- zumal: einen Nightly Build -- auf einem Betriebssystem nutzen zu wollen, das bereits seit über einem Jahr tot ist?
Gerader Ast schrieb: > Zu der Empfehlung KiCAD selber zu compilieren, ich glaube das übersteigt > den Aufwand oder Wissensstand vieler Nutzer, denn oft ist bei OSS > entweder ein exotischer Compiler oder Tools vonnöten um das zu machen. Im gleichen oben genannten Thread stand, dass sie von Msys auf MSVC umgestellt haben. Nein, das Argument „ich bin zu faul, andere sollen mir das mundgerecht hinlegen“ finde ich, ehrlich gesagt, zum K***. Andere machen sich schon ausgiebig Mühe, den ganzen Kram zusammenzutragen, Features einzubauen, Bugs zu reparieren, Doku zu schreiben. > Und bei einem Paket von 1GB Installer-Größe dürfte ja auch einiges an > Quelltext zusammenkommen. Du vergisst, dass der größte Teil dieser Datenmenge für die 3D-Modelle draufgeht. Die .tar.gz-Files mit dem Quelltext sind gerade mal reichlich 30 MB groß. > Naja vielleicht eine Chance für Horizon ;-) Glaub' ich nicht, da wurde doch schon gejammert, dass Lukas eine Minimalanforderung an die OpenGL-Version gesetzt hat, die von 15 Jahre alter Hardware nicht mehr erfüllt wird …
Jörg W. schrieb: > BrownCoat schrieb: >> Ich >> bezweifel dass Windows-Nutzer problemlos eine Umgebung aufsetzen können >> um KiCad für Win7 zu compillieren... > > Warum sollten Windows-Nutzer dööfer sein als Nutzer anderer > Betriebssysteme? Oder was genau wolltest du damit ausdrücken? Sie könnten natürlich in diesem "Windows Subsystem for Linux" (WSL) einfach das Paket "build-essential" installieren...
Sheeva P. schrieb: > Sie könnten natürlich in diesem "Windows Subsystem for Linux" (WSL) > einfach das Paket "build-essential" installieren... Und damit compilieren sie sich dann ein Windows-Binary? Glaub' ich nicht … (Davon abgesehen, finde den Fehler. :-) *) Wenn es aber jemandem so wichtig ist, das auch noch (und dann eben ohne Python) für Windows 7 zu haben, dann sollten sich doch allemal paar Engagierte finden können, die daraus ein Binary schnüren und das dann auf irgendeine öffentliche Plattform hochladen (und vielleicht hier die URL verlinken). Warum müssen immer „die anderen“ sowas für diejenigen tun, die das haben wollen? *) WSL ist Windows 10 ;-)
:
Bearbeitet durch Moderator
Thomas P. schrieb: > https://forum.kicad.info/t/windows-7-soon-to-be-no-longer-functional-for-6-0/27149 > > KiCad nutzt jetzt Python 3.8 für Windows, und das ist nicht länger > kompatibel mit Windows 7. Hm, merkwürdig - python.org sagt: „Note that Python 3.8.9 cannot be used on Windows XP or earlier.“ Erst für 3.9 gilt dann: „Note that Python 3.9.3 cannot be used on Windows 7 or earlier.“
Jörg W. schrieb: > Sheeva P. schrieb: >> Sie könnten natürlich in diesem "Windows Subsystem for Linux" (WSL) >> einfach das Paket "build-essential" installieren... > > Und damit compilieren sie sich dann ein Windows-Binary? Glaub' ich nicht > … Meines Wissens ist die GCC aus dem WSL2 tatsächlich -- genau wie die anderen Pakete -- das originale, unveränderte Ubuntu-Paket, und erzeugt ELF-Binaries, welche der Windows-Kernel ausführen kann. Ansonsten gibt es natürlich auch noch die Mingw- und Cygwin-Compiler, soweit ich weiß. (Ich selbst habe dazu jedoch keine eigenen Erfahrungen und muß mich da auf Aussagen von Kollegen verlassen, alldieweil es nicht genug Schmerzensgeld auf der Welt gibt, damit ich Windows anfassen würde.) > Warum müssen immer „die anderen“ sowas für diejenigen tun, die das haben > wollen? Weil es für die "ich will alles haben"-Woller viel einfacher ist als selbst mal einen Finger krumm zu machen. Jetzt mal ehrlich, Jörg, da hättest Du aber auch selbst drauf kommen können... ;-) > *) WSL ist Windows 10 ;-) Oh, ja, kann sein, irgendwo in meinem Hinterkopf meldet sich etwas...
Jörg W. schrieb: > Wenn es aber jemandem so wichtig ist, das auch noch (und dann eben ohne > Python) für Windows 7 zu haben, dann sollten sich doch allemal paar > Engagierte finden können, die daraus ein Binary schnüren und das dann > auf irgendeine öffentliche Plattform hochladen (und vielleicht hier die > URL verlinken). > > Warum müssen immer „die anderen“ sowas für diejenigen tun, die das haben > wollen? Erstmal danke, daß der Quelltext nicht so groß ist und auch mit Msvc zu compilieren ist weckt Hoffnung. Und zu deinem Argument, das sollen "die anderen" tun ich hatte halt mal wieder das Nightly gezogen um zu sehen ob sich was neues getan hat. Ich nutze KiCAD selber noch nicht aktiv, habe zwar vor es zu lernen mit dem Elektor-Buch aber die Zeit ist knapp ;-) Deshalb würde ich mich jetzt nicht als qualifiziert betrachten einen Back-Port für Windows 7 zu machen. Vielleicht probiere ich es ja trotzdem mal.
Gerader Ast schrieb: > Deshalb würde ich mich jetzt nicht als qualifiziert betrachten einen > Back-Port für Windows 7 zu machen. Es ist ja kein "Back-Port", sondern (so wie ich die Diskussion da im verlinkten Thread verstehe) lediglich, dass man beim Konfigurieren halt die Python-Unterstützung (die nur für externe Scripts nötig ist) abwählt und nicht mir rein compiliert.
Jörg W. schrieb: > Vielleicht ließe sich das ja auch mit irgendwelchen Abstrichen noch > unter Win7 compilieren und die Python-Maintainer haben auch nur keine > Lust, noch Packages für ein OS zu pflegen, das vom Hersteller nicht mehr > supportet wird? Insbesondere werden sie keine Lust haben Bugs zu fixen die mit selbstgebautem Python dann auf Win7 auftreten. Leider auch dann, wenn der Bug in anderen Konfigurationen auftritt aber nur mit der oben genannten Konfiguration reportet wurde. Oder meinst Du, dass die Maintainer entsprechende Cases dann selber auf W10 checken?^^ Am frustrierensten finde ich allerdings, dass das Ganze letztendlich Futter für die Anbieter komerzieller SW ist. Meine gekauften Tools, z.B. MatLab oder DipTrace, laufen in der aktuellsten Version problemlos mit Win7. AD auch, obwohl Altium sagt: " still supported, although not recommended". Auch Eagle läuft (lt. WebSite) in der aktuellen Version noch unter W7. Ich kann mir durchaus vorstellen, dass da verschiedene HW Entwickler lieber Eagle "mieten", mit allen Vor- & Nachteilen, statt auf W10 zu wechseln. Meist gibt es dafür ja auch Gründe, welche auch immer das im Einzelnen sein mögen. /regards
Als Win7-Nutzer hat mich die Ansage auch kalt erwischt. Schade, dass im Thread im Kicad-Forum so dogmatisch argumentiert wird (Botnetz...). Da geht es hier noch richtig sachlich zu... Jedenfalls hab ich das Gefühl, dass die Lebenszyklen und Abhängigkeiten immer straffer werden, insbesondere auch im OpenSource-Bereich. Was gerade der OpenSource schadet, da dann viel den Neuerungen in den Abhängigkeiten hinterherentwickelt werden muss, was erstmal keinen Zugewinn bringt. Naja, wie schon gesagt wurde, wenn man ein 10 Jahre altes OS verwendet, wird man wohl auch nicht die neueste Kicad-Version brauchen... Und dann hab ich noch ne Parallelinstallation mit Linux, wird also schon irgendwie gehen :-)
Maxe schrieb: > Und dann hab ich noch ne Parallelinstallation mit Linux, wird also schon > irgendwie gehen :-) Macht irgendwie Sinn, wenn man Open Source SW verwenden will.
Windows 7 in 2021 als Arbeitssystem? Wie besch*** ist denn das bitte? Ja ich hab noch XP und Win7 VMs als Archivsysteme mit Software die es für aktuelle Systeme nicht mehr gibt. Da wird aber keine neue Software installiert oder gar im Netzwerk produktiv damit gearbeitet. Wenn man sich mit Windows 10 nicht anfreunden möchte, dann ist das völlig okay. Dann bitte gewöhnt Euch an was anderes, Alternativen gibt es genug. Arbeite selbst seit 15 Jahren auf meinem Hauptsystem ohne Windows... Außerdem: Wenn die Anforderungen einer Software, die man verwenden möchte, Windows xx nicht mehr listet, dann ist das eben so und hat seinen Grund. <ironie> Es ist eine Frechheit dass AUDI für meinen 1998er A4 kein Kurbelwellenzahnrad mehr als Ersatzteil anbietet. Ist ne Frechheit, sollte man verklagen die Saubande </ironie>
Maxe schrieb: > Jedenfalls hab ich das Gefühl, dass die Lebenszyklen und Abhängigkeiten > immer straffer werden, insbesondere auch im OpenSource-Bereich. Was > gerade der OpenSource schadet, da dann viel den Neuerungen in den > Abhängigkeiten hinterherentwickelt werden muss, was erstmal keinen > Zugewinn bringt. Da höre ich raus, dass es dir lieber wäre, wenn im OpenSource-Bereich lieber die Zügel lockerer gelassen werden, damit es mehrere veraltete Versionen gibt, die dann auch noch alle gepflegt und zum Zusammenspiel gebracht werden müssen. Nein, da ist es mir schon lieber, dass man sich bemüht, auf aktuellem Stand zu bleiben.
Gerader Ast schrieb: > Na dann "schönen Dank" an die Entwickler, nur wegen der > Scriptsprache > mein liebstes OS nicht mehr zu unterstützen. > Und der süffisante Satz ein up-to-date OS zu verwenden können sie sich > sonstwohin schieben. Wenn das etwas angepisst klingt, liegt das daran > daß ich angepisst bin. Gut gesagt! Sollte man auch so sagen dürfen.
Beitrag #6648310 wurde von einem Moderator gelöscht.
BrownCoat schrieb: > Oder Jörg, findest du etwa das Win7-Nutzer doof sind? Doof vielleicht nicht, aber auf jeden Fall aus der Zeit gefallen. Demnächst beschwert sich noch einer warum Kicad nicht unter Windows 3.1 läuft.
Metpooli schrieb: > Gerader Ast schrieb: >> Na dann "schönen Dank" an die Entwickler, nur wegen der Scriptsprache >> mein liebstes OS nicht mehr zu unterstützen. >> Und der süffisante Satz ein up-to-date OS zu verwenden können sie sich >> sonstwohin schieben. Wenn das etwas angepisst klingt, liegt das daran >> daß ich angepisst bin. > > Gut gesagt! Sollte man auch so sagen dürfen. Natürlich darf man das so sagen. Aber man muß dann halt damit rechnen, von den Zuhörern nicht mehr ernst genommen zu werden.
Frank schrieb: > Doof vielleicht nicht, aber auf jeden Fall aus der Zeit gefallen. Solche Aussagen kommen meist entweder von Studenten oder von Konzernangestellten. Weil (fast) alle Leute die ihr Equipment selber bezahlen müssen da meist etwas zurückhaltender bei Neuerungen sind. Immerhin ist Win7 wohl noch auf 20% der aktuellen Desktoprechner, die mit Windows arbeiten, installiert (ref. https://www.heise.de/news/Windows-7-hat-immer-noch-20-Prozent-Marktanteil-5002089.html). Die Leute können aber auch nicht trivial wechseln, wenn sie z.B. Geräte benutzen die der Hersteller nicht mit aktualisierten Treibern für W10 versorgt oder versorgen kann. Manche Leute sehen aber auch einfach nicht warum sie ein an sich funktionierendes System wegschmeissen sollen. Was ist denn der Value der neuen Pythonvariante für KiCad User? > Demnächst beschwert sich noch einer warum Kicad nicht unter Windows 3.1 > läuft. Momentan beschweren sie sich eher darüber, dass durch eine schwer nachvollziehbare Designentscheidung im Python Projekt zukünftig kein supportetes KiCad unter Win7 mehr existieren wird. DAS ist aber etwas völlig Anderes. Werden vielleicht demnächst nur noch PCs mit RISC-V supported, weil die Python-Leute keine Intel und ARM Prozessoren mehr unterstützen? Deren Architektur ist ja auch schon so alt und überholt^^
Andreas H. schrieb: > Was ist denn der Value der neuen Pythonvariante für KiCad User? Soweit ich das da rausgelesen habe, haben sie damit einfach mal die nun schon lange komplett aufgegebene Python-Version 2.x abgelöst. > Manche Leute sehen aber auch einfach nicht warum sie ein an sich > funktionierendes System wegschmeissen sollen. Verlangt ja keiner, es wird ja auch noch ein Weilchen die 5.1.x geben, und auch wenn die nicht mehr gepflegt wird, kann man die noch genauso weiter benutzen, wie der/diejenige das Windows 7 eben weiter benutzt. Nur, wer auf die aktuelle Version upgraden möchte, kann das dann nicht mehr mit den Builds, die das Projekt selbst bereit stellt.
Andreas H. schrieb: > Weil (fast) alle Leute die ihr Equipment selber bezahlen müssen da meist > etwas zurückhaltender bei Neuerungen sind. Nö, weil sie sich der Knechtschaft eines Konzerns unterwerfen. > Die Leute können aber auch nicht trivial wechseln, wenn sie z.B. Geräte > benutzen die der Hersteller nicht mit aktualisierten Treibern für W10 > versorgt oder versorgen kann. QED
Sheeva P. schrieb: > Natürlich darf man das so sagen. Aber man muß dann halt damit rechnen, > von den Zuhörern nicht mehr ernst genommen zu werden. Wenn er damit rechnen muss, dass "die Zuhörer" ihn nicht mehr ernst nehmen, nur weil er - zugegebenermassen etwas unkonstruktiv - Kritik äussert, dann kann er aber auf diese "Zuhörer" auch verzichten, oder? /regards
Jörg W. schrieb: > Nur, wer auf die aktuelle Version upgraden möchte, kann das dann nicht > mehr mit den Builds, die das Projekt selbst bereit stellt. Es ist ja nicht einmal die aktuelle Version. Es ist der Nightly Build, also die allerneueste Entwicklungsversion... und hier beschweren sich Leute, weil diese Version nicht auf einer Betriebssystemversion läuft, die deren Hersteller schon vor geraumer Zeit für tot erklärt hat.
Jörg W. schrieb: > Andreas H. schrieb: >> Was ist denn der Value der neuen Pythonvariante für KiCad User? > > Soweit ich das da rausgelesen habe, haben sie damit einfach mal die nun > schon lange komplett aufgegebene Python-Version 2.x abgelöst. > Aber da hätte auch 3.x gereicht, was anscheinend noch unter W7 läuft. Entscheidend ist mMn aber eher die Entscheidung der Python Entwickler den Support für W7 einzustellen. Dadurch bringen sie ja nicht nur KiCad unter Zugzwang, sondern z.B. auch FreeCad. Die gehen ja auch zunehmend auf Python 3.x. >> Manche Leute sehen aber auch einfach nicht warum sie ein an sich >> funktionierendes System wegschmeissen sollen. > > Verlangt ja keiner, es wird ja auch noch ein Weilchen die 5.1.x geben, > und auch wenn die nicht mehr gepflegt wird, kann man die noch genauso > weiter benutzen, wie der/diejenige das Windows 7 eben weiter benutzt. > > Nur, wer auf die aktuelle Version upgraden möchte, kann das dann nicht > mehr mit den Builds, die das Projekt selbst bereit stellt. Was dann letztendlich auf unsupported, zumindest bei Bugs, hinausläuft, oder? /regards
Andreas B. schrieb: > Andreas H. schrieb: >> Weil (fast) alle Leute die ihr Equipment selber bezahlen müssen da meist >> etwas zurückhaltender bei Neuerungen sind. > Nö, weil sie sich der Knechtschaft eines Konzerns unterwerfen. > >> Die Leute können aber auch nicht trivial wechseln, wenn sie z.B. Geräte >> benutzen die der Hersteller nicht mit aktualisierten Treibern für W10 >> versorgt oder versorgen kann. > QED Sry. Kann Dir da leider nicht folgen. /regards
Andreas H. schrieb: > Was dann letztendlich auf unsupported, zumindest bei Bugs, hinausläuft, > oder? Da Win7 auch nicht mehr supported wird (seit einem Jahr übrigens), passt das doch.
Frank schrieb: > Demnächst beschwert sich noch einer warum Kicad nicht unter Windows 3.1 > läuft. Ein bischen sachlich bleiben könnte auch dir nicht schaden. Oder ist dir der Unterschied zwischen einem 16-Bit-Betriebssystem, das mit Hängen und Würgen 512MByte Arbeitsspeicher unterstützt und 64-Bit-Betriebssystemen, zum denen auch Windows7 gehört, nicht geläufig?
Andreas H. schrieb: > Sry. Kann Dir da leider nicht folgen. zu a) Man kann statt Win ein anderes BS verwenden. Linux ist frei und immer aktuell zu haben. zu b) Weil Du eben Win kaufst (vom großen o.g. Konzern) bist Du halt auch gezwungen dessen Spielchen mitzuspielen. Unter Linux läuft auch sehr alte HW. Irgendwann nach 20 Jahren werden dann allerdings auch bei Linux alte Zöpfe abgeschnitten.
Andreas H. schrieb: > Manche Leute sehen aber auch einfach nicht warum sie ein an sich > funktionierendes System wegschmeissen sollen. Dann sollen sie bei ihrem "funktionierenden System" bleiben, kein Problem. Sie müssen dann eben darauf verzichten, aktuellste Nightly Builds zu benutzen -- und irgendwann können sie auch die aktuelle Stable-Version nicht mehr installieren, wenn sie bis dahin nicht von ihrem Starrsinn abgerückt sind. >> Demnächst beschwert sich noch einer warum Kicad nicht unter Windows 3.1 >> läuft. > Momentan beschweren sie sich eher darüber, dass durch eine schwer > nachvollziehbare Designentscheidung im Python Projekt zukünftig kein > supportetes KiCad unter Win7 mehr existieren wird. Ich fürchte, Du verstehst da etwas nicht ganz richtig. Da schenkt man Dir eine Software, und Du hast nun nichts Besseres zu tun als hinter seinem Rücken über ihn und sein Geschenk zu lästern? Das ist undankbar, dreist, und unverschämt. OpenSource-Software ist ein Angebot, das Du -- gemäß ihrer Lizenz -- benutzen darfst, oder es lassen. Zudem ist sie in der Regel kostenlos, was bedeutet: die Entwickler schulden Dir überhaupt gar nichts, auch keine Erklärung für ihre Designentscheidungen. Wenn Du die verstehen willst, dann darfst Du freundlich nachfragen, und wenn Du Glück hast, bekommst Du vielleicht sogar eine Erklärung. Du hast aber keine Ansprüche auf irgendetwas. > Werden vielleicht demnächst nur noch PCs mit RISC-V supported, weil die > Python-Leute keine Intel und ARM Prozessoren mehr unterstützen? Deren > Architektur ist ja auch schon so alt und überholt^^ Ich weiß natürlich, daß das ein Witz sein sollte, aber Deine Anspruchshaltung kann ich als Entwickler von OpenSource-Software gar nicht witzig finden. Schau, wenn Du Erklärungen für bestimmte Designentscheidungen von OpenSource-Projekten haben, oder sogar Einfluß darauf nehmen willst, dann gibt es dazu ein probates Mittel: beteilige Dich an dem oder den Projekten und leiste Deinen Beitrag, und dann wird Deine Stimme auch in den Projekten -- zumindest -- angehört.
Andreas H. schrieb: > Sheeva P. schrieb: >> Natürlich darf man das so sagen. Aber man muß dann halt damit rechnen, >> von den Zuhörern nicht mehr ernst genommen zu werden. > > Wenn er damit rechnen muss, dass "die Zuhörer" ihn nicht mehr ernst > nehmen, nur weil er - zugegebenermassen etwas unkonstruktiv - Kritik > äussert, dann kann er aber auf diese "Zuhörer" auch verzichten, oder? Natürlich kann er. Aber dann ist ein öffentliches Internetforum sicherlich nicht ganz der richtige Ort für ihn, oder?
Andreas H. schrieb: > Aber da hätte auch 3.x gereicht, was anscheinend noch unter W7 läuft. > Entscheidend ist mMn aber eher die Entscheidung der Python Entwickler > den Support für W7 einzustellen. Das war und ist nicht die Entscheidung der Python-Entwickler. Das war und ist die Entscheidung des Herstellers von Windows 7. Dieser Hersteller heißt Microsoft, Du hast vielleicht schon einmal von dieser Firma gehört.
Ist es jetzt von einem nightly built auf den anderen passiert oder zieht sich das schon durch die gesamte 5.99.x-Historie durch? Ich hab zwar noch die älteren 5.99-er im Archiv, aber kein Win7 mehr, um es zu testen. Wenn es schon im gesamten 5.99-er Faden so ist, dann ist es konsequent, da man daraus dann ja irgendwann die offizielle Version 6.0 veröffentliochen wird und diese soll ja nur aktuelle Betriebssysteme / Hilfstools unterstützen. Wenn aber jetzt von einem Build auf den anderen die Funktion für Windows 7 / Python 3.7 wegfällt, dann ist das in meinen Augen ein Bug. Denn in einzelnen Builds und Zwischenrevisionen sollen nur Fehler behoben werden und nicht Features ein- oder ausgepflegt werden. [1] [1] https://de.wikipedia.org/wiki/Versionsnummer
OK, der Thread ist nun von den üblichen Verdächtigen gekapert worden, auf zur Kaffeepause.
Andreas B. schrieb: > Andreas H. schrieb: >> Was dann letztendlich auf unsupported, zumindest bei Bugs, hinausläuft, >> oder? > > Da Win7 auch nicht mehr supported wird (seit einem Jahr übrigens), passt > das doch. Naja, MatLab 2021a läuft hier unter W7, Diptrace 4.1.1.0 (Feb 2021) auch. (Nicht weil ich W10 Hasser bin, sondern einfach weil es auf der Kiste noch drauf ist). Es ist also anscheind nicht unbedingt notwendig das OS zu wechseln um aktuelle, supportete SW zu benutzen. /regards
Andreas B. schrieb: > Andreas H. schrieb: >> Sry. Kann Dir da leider nicht folgen. > > zu a) Man kann statt Win ein anderes BS verwenden. Linux ist frei und > immer aktuell zu haben. > Ach das meinst Du. Ja, stimmt. Allerdings haben nicht alle Leute die Option. Spätestens wenn Du mache Tools nur unter Windows bekommst. > zu b) Weil Du eben Win kaufst (vom großen o.g. Konzern) bist Du halt > auch gezwungen dessen Spielchen mitzuspielen. Unter Linux läuft auch > sehr alte HW. Irgendwann nach 20 Jahren werden dann allerdings auch bei > Linux alte Zöpfe abgeschnitten. Wenn man Linux benutzen kann, dann stellt sich mMn die Frage sowieso nicht mehr. Hier (privat) laufen auch mehr Kisten unter Debian wie unter Windows ;) /regards
Andreas H. schrieb: > Es ist also anscheind nicht unbedingt notwendig das OS zu wechseln um > aktuelle, supportete SW zu benutzen. Das nicht, aber man sollte eben auch nicht erwarten, daß aktuelle SW drauf läuft. Andreas H. schrieb: > Ach das meinst Du. Ja, stimmt. Allerdings haben nicht alle Leute die > Option. > Spätestens wenn Du mache Tools nur unter Windows bekommst. Dann nimmt man eben andere, die die gleiche Aufgabe erfüllen. Wenn es Dir um Tools geht, also um Programmierung dann findest Du unter Linux erheblich mehr als unter Windows. Abgesehen davon, daß die Installation solcher Tools unter Linux meist viel einfacher als unter Windows ist. Wenn es natürlich von der Fa so vorgegeben ist, dann muß die Fa eben auch mit Win zurechtkommen. Da habe ich kein Mitleid.
:
Bearbeitet durch User
Erwin D. schrieb: > Maxe schrieb: >> Jedenfalls hab ich das Gefühl, dass die Lebenszyklen und Abhängigkeiten >> immer straffer werden, insbesondere auch im OpenSource-Bereich. Was >> gerade der OpenSource schadet, da dann viel den Neuerungen in den >> Abhängigkeiten hinterherentwickelt werden muss, was erstmal keinen >> Zugewinn bringt. > Da höre ich raus, dass es dir lieber wäre, wenn im OpenSource-Bereich > lieber die Zügel lockerer gelassen werden, damit es mehrere veraltete > Versionen gibt, die dann auch noch alle gepflegt und zum Zusammenspiel > gebracht werden müssen. Nein, da ist es mir schon lieber, dass man sich > bemüht, auf aktuellem Stand zu bleiben. Natürlich nicht. Schau dir Linux an. Änderungen im Fenstermanager ziehen einen ganzen Rattenschwanz nach sich. Programme verlieren die Kompatibilität, Frameworks müssen den Änderungen nachgezogen werden usw. GTK2 war lange aktuell und die Nachfolgeversionen sollen laut Ankündigungen jeweils schnell obsolet werden. Für die GTK-Entwickler ist das schön, keine Legacies. Die OpenSource-Entwickler, die Linuxanwendungen entwickeln, haben das nachsehen. Klar, ist alles ein tolles Geschenk, um bei Sheeva zu bleiben. Bei einem CAD-System hängt natürlich weniger dran. Ärgerlich sind halt so Argumentationen, dass man einem ja noch was Gutes täte, wenn man ein abgekündigtes OS nicht mehr unterstützt.
Sheeva P. schrieb: >> Nur, wer auf die aktuelle Version upgraden möchte, kann das dann nicht >> mehr mit den Builds, die das Projekt selbst bereit stellt. > > Es ist ja nicht einmal die aktuelle Version. Auf die dann (später mal) aktuelle Version. Andreas H. schrieb: >> Nur, wer auf die aktuelle Version upgraden möchte, kann das dann nicht >> mehr mit den Builds, die das Projekt selbst bereit stellt. > > Was dann letztendlich auf unsupported, zumindest bei Bugs, hinausläuft, > oder? Das dürfte ja aber jemanden, der unbedingt noch Windows 7 benutzen möchte, nun nicht so sehr interessieren, oder?
Sheeva, ich hab hier massiv abgekürzt wg. EOL (End-of-Lunchtime), sry :) Sheeva P. schrieb: > Ich fürchte, Du verstehst da etwas nicht ganz richtig. Ich denke ich sehe das genau richtig. Ja, OSS ist ein Angebot das man nutzen kann aber nicht muss. Trivial^^ Wenn OSS aber eine echte Alternative sein will, dann sollte es auch die gleiche "Brauchbarkeit" wie kommerzielle SW anbieten können. Sonst kann sich kaum ein Unternehmen dieses Risiko leisten. Das ist keine Frage von Sheeva P. schrieb: > undankbar, > dreist, und unverschämt sondern oft eine Frage ob man nicht mit kommerzieller SW wirtschaftlicher arbeitet. Es gibt genug Beispiele wo OSS gewerblich eingesetzt wird und Firmen auch die Entwickler, zb. für Weiterentwicklung, spezielle Features oder Bugfixes, bezahlen. Allerdings fällt mir keine gewerbliche Nutzung von OSS ein, wo der "Kunde" Sheeva P. schrieb: > freundlich nachfragen, und wenn Du Glück hast, > bekommst Du vielleicht sogar eine Erklärung. Du hast aber keine > Ansprüche auf irgendetwas. aktzeptiert. Denn der "Kunde" muss am Ende des Monats Gehälter bezahlen. /regards
Sheeva P. schrieb: > Das war und ist nicht die Entscheidung der Python-Entwickler. Das war > und ist die Entscheidung des Herstellers von Windows 7. Nö. MicroSoft hat entschieden den Support von Windows 7 einzustellen. Das war hinreichend lang angekündigt und nachvollziehbar. Python dürfte MicroSoft relativ egal sein. Obwohl es sie sicher freuen wird, dass Python seine User nun bei Windows auch zu Version 10 drängt.
Andreas H. schrieb: > Andreas B. schrieb: >> Andreas H. schrieb: >>> Was dann letztendlich auf unsupported, zumindest bei Bugs, hinausläuft, >>> oder? >> >> Da Win7 auch nicht mehr supported wird (seit einem Jahr übrigens), passt >> das doch. > > Naja, MatLab 2021a läuft hier unter W7, Diptrace 4.1.1.0 (Feb 2021) > auch. Die Nightly Builds?
Andreas H. schrieb: > Wenn OSS aber eine echte Alternative sein will, dann sollte es auch die > gleiche "Brauchbarkeit" wie kommerzielle SW anbieten können. Sonst kann > sich kaum ein Unternehmen dieses Risiko leisten. Es steht Dir frei, eine Firma mit den Support dieser OSS zu beauftragen. Die compilieren Dir dann dann jede kommende Version von KICAD auch für ältere Systeme. (und passen ggf. auch an) Kostet dann halt was. Es ist halt auch die Frage, ob sich ein Unternehmen die Upgradepolitik des besagten Konzerns leisten will. Da haben sie nämlich keine Wahl. Irgendwelche Sourcen bekommen sie da nämlich nicht, wenn besagter Konzern mal eben EOL ankündigt. Also wo ist jetzt das größere Risiko?
Andreas H. schrieb: > Andreas B. schrieb: >> zu a) Man kann statt Win ein anderes BS verwenden. Linux ist frei und >> immer aktuell zu haben. > > Ach das meinst Du. Ja, stimmt. Allerdings haben nicht alle Leute die > Option. > Spätestens wenn Du mache Tools nur unter Windows bekommst. Dual-Boot existiert. Windows kann man in einer VM betreiben, Linux ebenso.
Jörg W. schrieb: > Das dürfte ja aber jemanden, der unbedingt noch Windows 7 benutzen > möchte, nun nicht so sehr interessieren, oder? Doch. Denn bei vielen anderen Tools gehts ja auch. Das ist doch das Ärgerliche was einem auch immer wieder um die Ohren gehauen wird, wenn man versucht OSS in die Firmen zu kriegen: - kein Support - kann <xyz> nicht - können unsere Leute nicht - <infinite list of other excutions> Dazu jetzt neu *trommelwirbel*: - Aber mit Eagle/Altium/DipTrace/Orcad/<your commercial pcb tool> würde es ja klappen... Ich gebs langsam auf. Kaufen wir uns halt alle zwei Jahre neue PCs, weil das dann installierte OS sein Verfallsdatum überschritten hat und der Hersteller von SW diese nicht mehr supporten. Weil OS ja abgekündigt^^ Fast so toll wie eingeklebte Handyakkus :/
Andreas H. schrieb: > Jörg W. schrieb: >> Das dürfte ja aber jemanden, der unbedingt noch Windows 7 benutzen >> möchte, nun nicht so sehr interessieren, oder? > > Doch. Denn bei vielen anderen Tools gehts ja auch. Wenn das OS selbst keinen Bugfix mehr bekommt, ist es für eine "gut abgehangene" Software wie KiCad 5.1.x dann plötzlich sauwichtig, dass man dafür noch für weitere Jahre Bugfixes bekommt? Das geht mir nicht in die Birne, sorry. Ist ja nun auch nicht so, dass diese Version unbenutzbar wäre oder alle nasenlang abstürzen würde. Deren Stabilität dürfte besser sein als die von Windows 7 selbst. > Kaufen wir uns halt alle zwei Jahre neue PCs, weil das dann installierte > OS sein Verfallsdatum überschritten hat Nicht jede Übertreibung erfüllt ihren Zweck. Ich jammere doch hier auch nicht rum, dass ich auf meinem 10+ Jahre alten Laptop mit nur noch Ubuntu 16.04 nun auch nicht mehr jede neueste Software bekommen kann. OS-Upgrade auf der alten Kiste hat keinen Sinn, weil die Grafikkarte zu alt ist und die alten Treiber allmählich Späne machen. Auch Grafikhersteller wollen halt nicht mehr ewig Support leisten. Was ich für die Kiste nicht vor-paketiert bekommen kann, kann ich mir dann entweder selbst compilieren, oder aber ich sehe mich dann doch mal nach was Neuem um. Gefällt mir allerdings bei der derzeitigen Preislage der Laptops nicht, so dringend brauche ich den auch nicht. Aber nichts mit "aller zwei Jahre", absolut nicht. Nach 10 Jahren dürfte sogar für konservative deutsche Finanzbeamte der moralische Verschleiß gut erreicht sein.
:
Bearbeitet durch Moderator
Andreas H. schrieb: > Doch. Denn bei vielen anderen Tools gehts ja auch. Und bei anderen eben nicht. Auch bei kommerziellen. Wir können festhalten daß sich OSS und kommerzielle SW da nicht wesentlich unterscheiden. Wer Support haben will, muß auch ab und zu mal sein OS upgraden.
Maxe schrieb: > Natürlich nicht. Schau dir Linux an. Änderungen im Fenstermanager ziehen > einen ganzen Rattenschwanz nach sich. Programme verlieren die > Kompatibilität, Frameworks müssen den Änderungen nachgezogen werden usw. Bitte entschuldige, aber von welchem Linux und welchem Window Manager sprichst Du denn da gerade? ich frage das deswegen, weil ich unter verschiedenen Linuxen sehr unterschiedliche Window Manager benutze (kwin, xfwm4, openbox, matchbox) und kann mich gar nicht daran erinnern, daß es notwendig gewesen wäre, fremde oder eigene Software an einen dieser Window Manager anpassen zu müssen.
Andreas B. schrieb: > Es steht Dir frei, eine Firma mit den Support dieser OSS zu beauftragen. Haben wir schon gemacht für einen Bugfix in einer OSS. Aber das ist was Anderes als permanent den Support für einen parallelen Trunk zu bezahlen. > Es ist halt auch die Frage, ob sich ein Unternehmen die Upgradepolitik > des besagten Konzerns leisten will. Da haben sie nämlich keine Wahl. > Irgendwelche Sourcen bekommen sie da nämlich nicht, wenn besagter > Konzern mal eben EOL ankündigt. > Also wo ist jetzt das größere Risiko? EOL von Win7 war, iirc, bereits 2015 angekündigt. Und endgültiges Supportende (ESU) 2023, oder? Das halte ich für durchaus hinreichend lange um sich drauf einzustellen^^ /regards
Andreas H. schrieb: > Das halte ich für durchaus hinreichend lange um sich drauf > einzustellen^^ Ja, und warum hast Du dann nicht upgegradet wenn Du doch Wert auf aktuelle SW legst?
Andreas H. schrieb: > Sheeva, ich hab hier massiv abgekürzt wg. EOL (End-of-Lunchtime), sry :) Alles gut, wünsche einen guten Appetit gehabt zu haben. ;-) > Ja, OSS ist ein Angebot das man nutzen kann aber nicht muss. Trivial^^ Manchmal muß man leider auch auf solche Trivialitäten hinweisen. "\(".)/" > Wenn OSS aber eine echte Alternative sein will, dann sollte es auch die > gleiche "Brauchbarkeit" wie kommerzielle SW anbieten können. Sonst kann > sich kaum ein Unternehmen dieses Risiko leisten. Auf die Gefahr hin, mich zu wiederholen, möchte ich noch einmal daran erinnern, daß wir hier über einen "Nightly Build" reden. Das ist das, was aus einem (meist nachts stattfindenden, daher der Name) Build der Software herausfällt. An solche Nightly Builds kommt man bei kommerzieller Software aber gar nicht heran. > Es gibt genug Beispiele wo OSS gewerblich eingesetzt wird und Firmen > auch die Entwickler, zb. für Weiterentwicklung, spezielle Features oder > Bugfixes, bezahlen. Das ist mir durchaus bekannt, und gibt es im Übrigen auch bei kommerzieller Software. Aber hier ist ja ganz offensichtlich nicht so, oder? Ich habe auch nichts davon gelesen, daß der TO und seine Unterstützer etwas bezahlen wollen, damit der Nightly Build von KiCAD auch unter Windows 7 unterstützt wird. > Allerdings fällt mir keine gewerbliche Nutzung von OSS ein, wo der > "Kunde" > > Sheeva P. schrieb: >> freundlich nachfragen, und wenn Du Glück hast, >> bekommst Du vielleicht sogar eine Erklärung. Du hast aber keine >> Ansprüche auf irgendetwas. > > aktzeptiert. Denn der "Kunde" muss am Ende des Monats Gehälter bezahlen. Oh, ich kenne ein sehr aktuelles Beispiel einer niederländischen Großbank, die seit mindestens einem Jahr händeringend darauf wartet, daß Microsoft seine Windows-Portierung des Redis-Servers endlich auf eine aktuelle Version bringt, obwohl die Bänker ein großer Kunde sind und sogar mit Geld winken.
Jörg W. schrieb: > Wenn das OS selbst keinen Bugfix mehr bekommt, ist es für eine "gut > abgehangene" Software wie KiCad 5.1.x dann plötzlich sauwichtig, dass > man dafür noch für weitere Jahre Bugfixes bekommt? Nö. Es geht um Gerader Ast schrieb: > Hallo wie der Betreff schon sagt. Aktuellen Nightly gezogen, > Installer sagt Minimum Windows 8.1. > Gibt es irgendeinen Workaround, oder kann mir jemand einen triftigen > Grund sagen warum Windows 7 nicht mehr supported ist. > Das Nightly von Februar 2021 ging problemlos.
Andreas B. schrieb: > Andreas H. schrieb: >> Das halte ich für durchaus hinreichend lange um sich drauf >> einzustellen^^ > Ja, und warum hast Du dann nicht upgegradet wenn Du doch Wert auf > aktuelle SW legst? Liest Du meine Mails nicht? Meine SW, auch auf der W7 Kiste, IST aktuell. Und wir reden hier ja nur von W7 ;) /regards
Andreas H. schrieb: > Jörg W. schrieb: >> Wenn das OS selbst keinen Bugfix mehr bekommt, ist es für eine "gut >> abgehangene" Software wie KiCad 5.1.x dann plötzlich sauwichtig, dass >> man dafür noch für weitere Jahre Bugfixes bekommt? > > Nö. Es geht um Ja, ich verstehe das nicht. Es ist nicht wichtig, das OS zu aktualisieren, aber es ist sauwichtig, dass alle Apps unter dem nicht mehr aktuellen OS noch aktualisierbar sind. Für mich ist das ein Widerspruch in sich.
Andreas H. schrieb: > Meine SW, auch auf der W7 Kiste, IST aktuell. W7 ist nicht aktuell und wird seit über einem Jahr nicht mehr supported. Und KiCAD 5.99 läuft darauf nicht. Darum geht es hier in diesem Thread.
Sheeva P. schrieb: > Auf die Gefahr hin, mich zu wiederholen, möchte ich noch einmal daran > erinnern, daß wir hier über einen "Nightly Build" reden. Oh, dann reden wir aneiander vorbei. Ich habe immer im Hinterkopf, dass auch in den zukünftigen Releases Python dafür sorgen wird, dass keine aktuellen KiCadvarianten mehr unter Win7 laufen werden. Der Nightly Build an sich, der wäre mir da egal. /regards
Jörg W. schrieb: > Andreas H. schrieb: >> Jörg W. schrieb: >>> Das dürfte ja aber jemanden, der unbedingt noch Windows 7 benutzen >>> möchte, nun nicht so sehr interessieren, oder? >> >> Doch. Denn bei vielen anderen Tools gehts ja auch. > > Wenn das OS selbst keinen Bugfix mehr bekommt, ist es für eine "gut > abgehangene" Software wie KiCad 5.1.x dann plötzlich sauwichtig, dass > man dafür noch für weitere Jahre Bugfixes bekommt? Zumal das nichtmal ausgeschlossen ist. Nur weil KiCad 6 irgendwann (vermutlich dieses Jahr) kommt, können ja trotzdem wichtige Bugfixes auch in 5.1.x Einzug finden. Und dass niemand KiCad 6 (dann ohne Python) für Windows 7 baut, ist auch nicht gesagt, nur weil das bei den Nightlies nicht passiert. Aber Eagle ist ja so viel besser, weil man da die Nightlies gar nicht erst zu sehen bekommt. Letztlich haben wir Diskussionen dieser Art aber oft genug geführt und es läuft immer auf "Friss, mach, oder stirb" vs. "Friss und zahl, oder stirb" hinaus. MfG, Arno
Andreas H. schrieb: > Jörg W. schrieb: >> Das dürfte ja aber jemanden, der unbedingt noch Windows 7 benutzen >> möchte, nun nicht so sehr interessieren, oder? > > Doch. Denn bei vielen anderen Tools gehts ja auch. Dann bilde ich mir die endlosen Threads von Menschen, deren Hard- und / oder Software von aktuellen Betriebssystemversionen nicht mehr unterstützt wird, anscheinend nur ein? > Das ist doch das Ärgerliche was einem auch immer wieder um die Ohren > gehauen wird, wenn man versucht OSS in die Firmen zu kriegen: > > - kein Support > - kann <xyz> nicht > - können unsere Leute nicht > - <infinite list of other excutions> Entschuldige bitte, aber all diese Probleme kann man bewältigen. Entweder selbst, oder mit ein bisschen Kleingeld für einen Dienstleister. > Dazu jetzt neu *trommelwirbel*: > - Aber mit Eagle/Altium/DipTrace/Orcad/<your commercial pcb tool> > würde es ja klappen... Von <your commercial tool here> werden allerdings keine brandaktuellen Nightly Builds verwendet, sondern nicht selten... sagen wir es positiv: gut abgehangene und bekannt stabile Versionen. Nicht selten ist dieses "gut abgehangen und bekannt stabil" allerdings nur ein Euphemismus für "wir hatten leider gerade nicht das Budget für eine aktuelle Version". Und die aktuelle Version von KiCAD läuft tatsächlich auch noch unter Windows 7, genau wie bei <please insert your commercial tool here>. > Ich gebs langsam auf. > Kaufen wir uns halt alle zwei Jahre neue PCs, weil das dann installierte > OS sein Verfallsdatum überschritten hat und der Hersteller von SW diese > nicht mehr supporten. Weil OS ja abgekündigt^^ > > Fast so toll wie eingeklebte Handyakkus :/ Lustigerweise habe ich erst vor vier oder fünf Wochen meinen uralten Rechner (Intel Q9650, > 10 Jahre alt) ausgemustert und durch eine aktuelle Maschine ersetzt. Auch auf dem alten Rechner -- der ursprünglich einmal mit Kubuntu 8.04 aufgesetzt worden war -- lief allerdings ein aktuelles Kubuntu 18.04 LTS und ich habe keinen Zweifel, daß auch ein Upgrade auf 20.04 LTS noch möglich gewesen wäre. Allein dieses Beispiel beweist, daß der Vergleich mit den eingeklebten Verschleißteilen oder dem periodischen Kauf neuer Computer sehr hinkt. Da sind wir dann leider wieder bei der Abhängigkeit von einem kommerziellen Hersteller, der sich dazu entschieden -- und es über Jahre hinweg immer wieder kommuniziert -- hat, eine bestimmte Version seiner Software ab einem gewissen Datum (hier: dem 14.1.2020) nicht mehr zu unterstützen. Das haben nicht die KiCAD- oder Python-Entwickler entschieden. Die sehen einfach nur, daß sie auf aktuellen Betriebssystemversionen laufen müssen -- und zwar zwingend! -- während die Unterstützung veralteter und vom Hersteller abgekündigter Systemversionen wertvolle Ressourcen für eine schwindende Menge von Anwendern binden würde. Lustigerweise möchte unser TO zwar eine veraltete Betriebssystemversion behalten, erwartet aber gleichzeitig, daß seine OpenSource-Sklaven^WLeute bitteschön immer neue Fähigkeiten ihn ihre Software einbauen. Deswegen benutzt er ja den Nightly Build -- obwohl er die Software tatsächlich noch gar nicht benutzt -- nämlich seiner eigenen Aussage zufolge um zu sehen, wie sich KiCAD weiterentwickelt und welche neuen Funktionen es hat. Aber selbst etwas dafür tun -- also: sich einen Compiler installieren und die Software selbst übersetzen -- will er auch nicht, das sollen gefälligst diese OpenSourceler für ihn machen. Aber pronto!
Arno schrieb: > immer auf "Friss, mach, oder stirb" vs. "Friss und zahl, oder > stirb" hinaus. "Friss, zahl und stirb" hast Du vergessen. ;-)
Andreas H. schrieb: > Sheeva P. schrieb: >> Auf die Gefahr hin, mich zu wiederholen, möchte ich noch einmal daran >> erinnern, daß wir hier über einen "Nightly Build" reden. > > Oh, dann reden wir aneiander vorbei. > Ich habe immer im Hinterkopf, dass auch in den zukünftigen Releases > Python dafür sorgen wird, dass keine aktuellen KiCadvarianten mehr unter > Win7 laufen werden. Der Nightly Build an sich, der wäre mir da egal. Das wird zweifellos früher oder später so kommen, bedeutet aber nicht, daß die aktuelle stabile Version -- IIRC 5.1.9 -- dann auch nicht mehr unter Windows 7 funktioniert. Die wird natürlich weiterhin funktionieren. Aber wer aktuelle Anwendungen nutzen will, der muß eben dafür sorgen, daß sein Betriebssystem angemessen aktuell ist. Das gilt im Übrigen nicht nur für OSS, sondern tatsächlich auch für kommerzielle Software. Die Microsoft Office-Suite, beispielsweise, läuft in ihrer aktuellen Version nur und ausschließlich mit der aktuellen Betriebssystemversion Windows 10.
Andreas B. schrieb: > Und KiCAD 5.99 läuft darauf nicht. Darum geht es hier in diesem Thread. Nein. Der Nightly build geht nicht mehr wg. dem "Pythonproblem". Davor ging 5.99 auch unter W7 (selbst vor paar Wochen getestet). /regards
Andreas B. schrieb: > Arno schrieb: >> immer auf "Friss, mach, oder stirb" vs. "Friss und zahl, oder >> stirb" hinaus. > "Friss, zahl und stirb" hast Du vergessen. ;-) Stimmt - ich nutze kein Windows, da lag das jetzt nicht so nahe ;) MfG, Arno
Arno schrieb: > Zumal das nichtmal ausgeschlossen ist. Nur weil KiCad 6 irgendwann > (vermutlich dieses Jahr) kommt, können ja trotzdem wichtige Bugfixes > auch in 5.1.x Einzug finden. > Um 5.1.x hab ich mir nie Sorgen gemacht. > Und dass niemand KiCad 6 (dann ohne Python) für Windows 7 baut, ist auch > nicht gesagt, nur weil das bei den Nightlies nicht passiert. > Das ist allerdings ein guter Punkt. Die Features von 5.99 fand ich bis jetzt nämlich schon nice :) > Aber Eagle ist ja so viel besser, weil man da die Nightlies gar nicht > erst zu sehen bekommt. > Eagle? Die Geschmäcker sind ja verschieden^^ > Letztlich haben wir Diskussionen dieser Art aber oft genug geführt und > es läuft immer auf "Friss, mach, oder stirb" vs. "Friss und zahl, oder > stirb" hinaus. Ja, leider. Wobei ich die Argumentation bei Python wirklich nicht verstehe. Und das ist nicht zynisch gemeint. Jetzt wo Python zunehmend in diversen (meist OSS) Tools benutzt wird hauen sie den Win7 Port einfach weg wärend diverse Andere ihre Sachen immer noch auf Win7 lauffähig halten. Wie gesagt, dass ist nicht zickig gemeint. Ich verstehe es nur einfach nicht. /regards
Andreas H. schrieb: > Davor ging 5.99 auch unter W7 (selbst vor paar Wochen getestet) Na ok, aber der nightly build von gestern ist eben nicht aktuell. Ich würde auch davon ausgehen, daß dies bei der kommenden Version 6.0 genauso sein wird. (betr. Nutzung von Python 3.7) Arno schrieb: > Stimmt - ich nutze kein Windows, da lag das jetzt nicht so nahe ;) Ich auch nicht, aber man liest halt viel von den Problemen der Win User. ;-)
Jörg W. schrieb: > Vielleicht ließe sich das ja auch mit irgendwelchen Abstrichen noch > unter Win7 compilieren und die Python-Maintainer haben auch nur keine > Lust, noch Packages für ein OS zu pflegen, das vom Hersteller nicht mehr > supportet wird? Windows 7 wird noch bis 2023 supported: "..., today we are announcing that we will offer paid Windows 7 Extended Security Updates (ESU) through *January 2023*" https://www.microsoft.com/en-us/microsoft-365/blog/2018/09/06/helping-customers-shift-to-a-modern-desktop/
Andreas H. schrieb: > Wie gesagt, dass ist nicht zickig gemeint. Ich verstehe es nur einfach > nicht. Ist eigentlich ganz einfach: Man muß mehrere Versionen aktuell halten. Da die Ressourcen der OS Programmierer aber nun mal begrenzt sind, unterstützt man eben die aktuelle BS Version anstatt der alten. Das hatte Sheeva aber schon erwähnt. Du kannst ja eigentlich froh sein, daß Win überhaupt unterstützt wird.
Eumel schrieb: > today we are announcing that we will offer paid Windows 7 Extended > Security Updates (ESU) through January 2023" Das Pendant bei KiCad dazu wäre jetzt, dass dir jemand bezahlten Support für die 5.1.x bis 2023 anbietet. Achso, nein, sorry, bezahlte Security-Updates. Also nicht einmal Bugfixes allgemeiner Art.
:
Bearbeitet durch Moderator
Sheeva P. schrieb: > Dann bilde ich mir die endlosen Threads von Menschen, deren Hard- und / > oder Software von aktuellen Betriebssystemversionen nicht mehr > unterstützt wird, anscheinend nur ein? <irony> Ja, bildest Du Dir nur ein. Darum muss man ja Win7 als target auch nicht mehr supporten hust. Beweisidee: Nimm Python^^ </irony> Im Ernst: Viele SW Hersteller unterstützen (vermutlich) Win7 immer noch, weil es immer noch stark benutzt wird (20% Marktanteil aktuell glaube ich). Das war das was ich oben sagen wollte. Und darum ist mir nicht klar, warum gerade Python das nicht mehr tun kann. > Entschuldige bitte, aber all diese Probleme kann man bewältigen. > Entweder selbst, oder mit ein bisschen Kleingeld für einen > Dienstleister. Da sagt mir unsere GL immer dass man für das "bisschen Kleingeld" aber auch eine kommerzielle SW, inkl. Wartungsvertrag, kriegen können. Und bei den Tagessätzen die ich kenne stimmt das auch oft. > Nicht selten ist dieses > "gut abgehangen und bekannt stabil" allerdings nur ein Euphemismus für > "wir hatten leider gerade nicht das Budget für eine aktuelle Version". Seit einiger Zeit ist es besonders "schick", die SW nicht zu kaufen sondern zu mieten (siehe z.B. AutoDesk). Da hast Du immer die aktuellste Version. Ob das technisch sinnvoll ist sei mal dahingestellt. > Die sehen einfach nur, daß sie auf aktuellen > Betriebssystemversionen laufen müssen -- und zwar zwingend! -- während > die Unterstützung veralteter und vom Hersteller abgekündigter > Systemversionen wertvolle Ressourcen für eine schwindende Menge von > Anwendern binden würde. Und da landen wir langsam beim eigentlichen Problem, oder? KiCad würde (vermutlich) auch relativ gut mit Python 3.x (x<8) hinkommen. Aber wird dieses Python zukünftig noch supported? D.h. Bug- & Securityfixes. Bei Linux u.a. klappt das doch meist ganz gut. Debian 9 wird zB noch bis 2022 supported. Und da reden wir vom kompletten OS. > > Lustigerweise möchte unser TO zwar eine veraltete Betriebssystemversion > behalten, erwartet aber gleichzeitig, daß seine > OpenSource-Sklaven^WLeute bitteschön immer neue Fähigkeiten ihn ihre > Software einbauen. Deswegen benutzt er ja den Nightly Build -- obwohl er > die Software tatsächlich noch gar nicht benutzt -- nämlich seiner > eigenen Aussage zufolge um zu sehen, wie sich KiCAD weiterentwickelt und > welche neuen Funktionen es hat. Ich benutze (nicht bei KiCad) die Nightlies eher um zu probieren ob alles noch klappt und ggf. einen Bugreport zu filen. Ich dachte dafür sind die da^^ /regards
Andreas H. schrieb: > Jetzt wo Python zunehmend in diversen (meist OSS) Tools benutzt wird > hauen sie den Win7 Port einfach weg wärend diverse Andere ihre Sachen > immer noch auf Win7 lauffähig halten. > Wie gesagt, dass ist nicht zickig gemeint. Ich verstehe es nur einfach > nicht. Im oben zitierten thread https://forum.kicad.info/t/windows-7-soon-to-be-no-longer-functional-for-6-0/27149 wird das ausgiebig diskutiert und um aus https://bugs.python.org/issue32592 zu zitieren: > If we had a dedicated maintainer who was supporting Win7 and making releases for it, then we (i.e. they) could support it. But then, there's nothing to stop someone doing that already, and even to stop them charging money for it if they want (which they wouldn't be able to do under the auspices of python-dev). So I suspect nobody is really that motivated ;) Freiwillige vor...
Wie wärs einfach mal eine stable Version zu nehmen, statt nigthly builds? Auserdem ist das Kostenlose Software, und wenn Du die nicht unterstützt => gaaanz ruhig sein.
Jens B. schrieb: > Wie wärs einfach mal eine stable Version zu nehmen, statt nigthly > builds? Naja, es geht ja eher darum, dass dann auch KiCad 6.x kein Windows 7 mehr unterstützen wird. Die Nightly Builds sind ja dafür nur die Vorwarnung.
Andreas B. schrieb: > Ich > würde auch davon ausgehen, daß dies bei der kommenden Version 6.0 > genauso sein wird. (betr. Nutzung von Python 3.7) Wenn KiCad 6.0 Python 3.7 benutzen würde, dann wäre es ja auch wieder unter Win7 benutzbar. MMn extrem sinnvoll. /regards
Ach, diesmal gibt es Ärger bei Kicad... tss tss tss.. Jörg W. schrieb: > Warum müssen immer „die anderen“ sowas für diejenigen tun, die das haben > wollen? Das kann ich dir erklären: 1. Es steht die Frage, ob besagte neue Version von Python überhaupt notwendig ist für das ganze Programm, oder ob es lediglich eine Laune der Entwickler ist, zu sagen "hey, da gibt's ne neue Version von, laßt sie uns einbauen, ist ja schließlich ne neue Version - und was scheren uns die Benutzer." 2. Es ist ganz gewiß nur irgend eine Kleinigkeit so in der Art #define python 2.8 oder # include "python28.xyz" was programmtechnisch da den Unterschied macht - aber dieses steckt vielleicht an 1003 verschiedenen Stellen irgendwo in den Bergen von Quellen, verteilt in tiefe Schluchten von unter-unter-unterordnern. Eigentlich leicht, aber vom Außenstehenden, also der Zielgruppe für das Produkt nicht zu handhaben. 3. Diejenigen, bei denen besagte nächtliche Builds ablaufen, haben das alles auf ihren Rechnern eingerichtet. Die Benutzer "die das haben wollen", haben keinerlei Einrichtung dafür, die müßten sich das alles mühsam einrichten und zwar wie üblich ohne ausreichende Dokumentation, auf einem anderen System als dem, wofür die herunterladbaren Daten gemacht sind, kurzum es würde einen Riesenaufwand geben, bloß weil bei den Entwicklern eine ziemliche Ignoranz und Hochnäsigkeit herrscht. DARUM. W.S.
physicist schrieb: > If we had a dedicated maintainer who was supporting Win7 and making > releases for > it, then we (i.e. they) could support it. But then, there's nothing to > stop > someone doing that already, and even to stop them charging money for it > if they > want (which they wouldn't be able to do under the auspices of > python-dev). So I > suspect nobody is really that motivated ;) Ach so. Das scheitert nur am fehlenden Maintainer? Und ich dachte, die Python Community ist so riesig. Danke für die Aufklärung :) /regards
W.S. schrieb: > Es ist ganz gewiß nur irgend eine Kleinigkeit Ganz gewiss. Die machen das nur, um die armen Windows-7-Nutzer zu ärgern.
alles vom Bill Gates gesteuert, weiss man doch :)
W.S. schrieb: > Jörg W. schrieb: >> Warum müssen immer „die anderen“ sowas für diejenigen tun, die das haben >> wollen? > > Das kann ich dir erklären: > (text omitted) > DARUM. Danke. Das war mal nötig ;) /regards
Jens B. schrieb: > Wie wärs einfach mal eine stable Version zu nehmen, statt nigthly > builds? Und wie wird die stabil ohne Tester?
Andreas H. schrieb: > Wenn KiCad 6.0 Python 3.7 benutzen würde Ja, sorry, ich meinte natürlich 3.8. Zurück gehen die bestimmt nicht mehr. ;-)
Andreas H. schrieb: > Jens B. schrieb: >> Wie wärs einfach mal eine stable Version zu nehmen, statt nigthly >> builds? > > Und wie wird die stabil ohne Tester? Gute Frage, Gegenfrage: Was bringt das ganze, wenn die Tester hier rumheulen, manchmal auch Fragen, statt bei den KiCadleuten?
Andreas H. schrieb: > Und wie wird die stabil ohne Tester? Indem die Damen und Herren der Entwicklung MAL SELBER ihr Produkt benutzen. Und ich meine tatsächlich benutzen, also echte Arbeit in der Anwendung leisten und nicht bloß ne Demo angucken, ob die immer noch so aussieht wie letztes Jahr. Das würde diesen Leuten auch erleichtern, ihr Produkt mal aus der Perspektive der Anwender zu sehen. W.S.
Jens B. schrieb: > Gute Frage, Gegenfrage: Was bringt das ganze, wenn die Tester hier > rumheulen, manchmal auch Fragen, statt bei den KiCadleuten? KA. Frag mal den TO. Mich hatte nur erschreckt das da anscheinend kein Win7 mehr supported werden soll. Wenn das durch Python kommt, dann fallen da ja demnächst noch einige Anwendungen unter Win7 weg.
W.S. schrieb: > Indem die Damen und Herren der Entwicklung MAL SELBER ihr Produkt > benutzen. Was Du alles für lau haben willst ist schon faszinierend. KiCAD ist eine super SW und Respekt vor den Entwicklern daß die das so gut hinbekommen haben. Als Eagle Umsteiger vermisse ich Eagle überhaupt nicht. NULL, auch wenn Du Dir das nicht vorstellen kannst.
Andreas H. schrieb: > Jens B. schrieb: >> Wie wärs einfach mal eine stable Version zu nehmen, statt nigthly >> builds? > > Und wie wird die stabil ohne Tester? Indem die Tester nicht die sind, die partout noch ein Windows 7 benutzen müssen? Klar, je mehr Tester, um so besser, aber nur, weil sie die Nightlys nun nicht mehr für Windows 7 bauen heißte das doch nicht ganz automatisch, es gäbe gleich keine Tester mehr. Selbst, wenn du die (hier sicher nicht kleine) Linux-Nutzergemeinde mal außen vor lässt, warst du es nicht selbst, der oben festgestellt hat, dass Windows 7 noch 20 % der Installationen ausmacht? Das hieße dann im Gegenzug, dass 80 % der Windows-Installationen kein Windows 7 sind. Der Verlust an „Testpersonal“ dürfte folglich nicht allzu groß ausfallen. W.S. schrieb: > Indem die Damen und Herren der Entwicklung MAL SELBER ihr Produkt > benutzen. Weil das immer so prima funktioniert, dass man das natürlich in jeder Software-Entwicklung als absoluten Vorzug hat, nicht wahr? Schließlich kennen die Entwickler ihre Bugs sowieso am besten … Ach nee, ich vergaß, Kicad-Entwickler entwickeln natürlich den ganzen Tag lang nur. Ohne W.S.' Hinweis kämen die niemals nimmer auf die Idee, das Programm dann auch mal zu starten. ;-)
W.S. schrieb: > Indem die Damen und Herren der Entwicklung MAL SELBER ihr Produkt > benutzen. Und ich meine tatsächlich benutzen, also echte Arbeit in der > Anwendung leisten und nicht bloß ne Demo angucken, ob die immer noch so > aussieht wie letztes Jahr. Das würde diesen Leuten auch erleichtern, ihr > Produkt mal aus der Perspektive der Anwender zu sehen. Autsch. Das ist, sry 4 this, nicht fair. Jeder SW-Dev wird Dir versichern, dass man sehr schnell eine gewisse "Betriebsblindheit" bei der eigenen SW entwickelt: "Natürlich muss man erst <X> machen, bevor <Y> funktioniert. Ist doch logisch^^" Meine Frau hat da eine wunderschöne Cartoon-Postkarte am Kühlschrank kleben mit dem Text "In Deinem Kopf mag das ja alles ganz klar sein. Ich bin aber leider hier draussen" Ausserdem ist das auch eine riesige Resourcensenke. Und da gerade im OSS viele Enwickler hauptberuflich was anderes machen ist Zeit wirklich knapp. Und testen können die Benutzer meist relativ schnell indem sie ihre aktuellen Schematics/pcbs da einfach mal reinwerfen und eine halbe Stunde mit spielen. Finally muss man sich nur mal die Buglisten/Featurerequests verschiedener OSS Projektte ansehen. Natürlich werden die Devs irgendwann grantelig wenn der 9692387469 Bug gefiled wird, wie immer ohne nachvollziehbares Beispiel, weil der User zu faul war ein entsprechendes Beispiel mitzuschicken und statt dessen erst mal über "diese Sch**!$ -SW" zu meckern. Rauszukriegen wie der Bug entsteht ist nämlich oft extrem Zeitaufwendig. Während also der User gemütlich vor dem Fernseher sitzt, sitzt der Dev da und versucht den Bug nachzustellen. /regards
Jörg W. schrieb: > Andreas H. schrieb: >> Jens B. schrieb: >>> Wie wärs einfach mal eine stable Version zu nehmen, statt nigthly >>> builds? >> >> Und wie wird die stabil ohne Tester? > > Indem die Tester nicht die sind, die partout noch ein Windows 7 benutzen > müssen? > > Klar, je mehr Tester, um so besser, aber nur, weil sie die Nightlys nun > nicht mehr für Windows 7 bauen heißte das doch nicht ganz automatisch, > es gäbe gleich keine Tester mehr. Selbst, wenn du die (hier sicher nicht > kleine) Linux-Nutzergemeinde mal außen vor lässt, warst du es nicht > selbst, der oben festgestellt hat, dass Windows 7 noch 20 % der > Installationen ausmacht? Ne, war ich nicht, aber es ist schon nicht leicht in der OSS Welt. Erst recht mit erfolgreichen Projekten. Vor allem, wenn ne Menge Abhängigkeiten drin sind, wo auf einmal etwas out of order ist.
Andreas H. schrieb: > Wobei ich die Argumentation bei Python wirklich nicht verstehe. Und das > ist nicht zynisch gemeint. Ach, weißt Du, wenn ich [1] richtig sehe und mich nicht verzählt habe, wird Python für über 40 Kombinationen aus Betriebssystem, Compiler etc. gepflegt. Dabei hat das Python-Projekt mit PEP11 schon seit 2002 (!) klare Policies, was den Support für ausgelaugene Betriebssysteme angeht. > Jetzt wo Python zunehmend in diversen (meist OSS) Tools benutzt wird > hauen sie den Win7 Port einfach weg wärend diverse Andere ihre Sachen > immer noch auf Win7 lauffähig halten. Welche "diversen anderen" denn? Sktiptsprachen oder eCAD-Systeme? Warum sollte Python das genauso halten wie "diverse andere"? > Wie gesagt, dass ist nicht zickig gemeint. Ich verstehe es nur einfach > nicht. Wie gesagt: PEP11. Zudem hat Windows 7 laut GlobalStats statscounter unter den Windows-Versionen weltweit einen Marktanteil von 16,2 Prozent, es ist anscheinend noch in China, Turkmenistan, und Venezuela weit verbreitet. Laut derselben Quelle beträgt der Marktanteil von Windows 7 in Deutschland noch 7.5 Prozent der Windows-Desktops, siehe dazu die Statistiken unter [3] und [4]. Wie viele dieser Windows-User nutzen wohl Python oder gar KiCAD -- und gar einen Nightly Build von KiCAD? Zumal viele Windows-User mit Altium, OrCAD, Eagle und anderer Software sehr zufrieden zu sein scheinen, und KiCAD unter Windows da wohl eher unter "ferner liefen" zu finden ist. Echt mal: ich habe schon nur sehr wenig bis kein Verständnis dafür, daß jemand unbedingt mit einem veralteten Betriebssystem arbeiten will (wohlgemerkt: will, nicht muß -- manchmal steckt man halt nicht 'drin). Aber warum es auf diesem veralteten System dann unbedingt die allerneueste Software sein muß, versteh ich mit Sicherheit noch weniger als Du die Policies und Entscheidungen der Python- und KiCAD-Entwickler. Manche Menschen scheinen mit ihrer Betriebssystemversion stärker verbandelt zu sein als mit ihren Partnernden, ok, das war zynisch. ;-) Wofür mir dann schon im Ansatz jedwedes Verständnis abgeht, ist, warum solche Menschen sich ihren Kram dann nicht einfach selbst bauen können, fordern, daß andere das (gefälligst!) für sie tun sollen, und sich "angepißt" nicht etwa an das betreffende Projekt, sondern an ein Forum wie dieses wenden, um ihrem Unmut Luft zu machen. Ich mein, immerhin reden wir hier ja von technisch orientierten Menschen, die Leiterplatten entwerfen und Mikrocontroller programmieren wollen, mithin also durchaus wissen (sollten), sie man Software (etwa einen Compiler) installiert und bedient. Wenn nicht, kann man das lernen, sofern mal will. Es scheint aber einfacher oder womöglich sinnvoller zu sein, hier über KiCAD und Python zu schimpfen (anstelle des Herstellers seines Betriebssystems, versteht sich) und einer Lösung des Problems dabei keinen Millimeter näher zu kommen... und natürlich ist keiner der Verständnislosen auch nur auf die Idee gekommen zu sagen "ich bezahle dafür, das zu machen, wer mag sich daran beteiligen"? So bleibt bei mir so ein kleiner, fader Nachgeschmack, und deswegen äußere ich hier mal genau dasselbe, was ich hier auch schon bei ähnlichen Gelegenheiten geäußert habe: OpenSource-Software ist eine feine Sache, und sie lebt von den Mitmachern, statt von den Abgreifern, Meckerern, und Anspruchstellern. [1] https://buildbot.python.org/all/#/grid?branch=master&tag=stable [2] https://www.python.org/dev/peps/pep-0011/ [3] https://gs.statcounter.com/windows-version-market-share/desktop/worldwide/#monthly-201803-202101 [4] https://gs.statcounter.com/windows-version-market-share/desktop/germany#monthly-201803-202101
Andreas H. schrieb: > Mich hatte nur erschreckt das da anscheinend kein Win7 mehr supported > werden soll. Wenn das durch Python kommt, dann fallen da ja demnächst > noch einige Anwendungen unter Win7 weg. Ja, das macht Unwohlsein. Welche Alternative zum stabilen Win7 gibt es denn wirklich für ein Produktivsystem auf dem auch verschiedene unverzichtbare WIN-Software (CAD, CAM, SPS-Prog.) laufen muß. Im Kleinbetrieb, ohne fulltime-IT-Droiden. WIN10? Ernsthaft? Dual Boot, Virtuelle Maschinen? Nee, wirklich. Ich bin da verwöhnt. In einem anderen Thread wird über die Software-Mietmodelle geschimpft, aber ausgerechnet ein Betriebssystem "as a service" welches sich aus Werbeeinnahmen finanzieren soll ist okay? Ernsthaft? Uwe
Andreas H. schrieb: > Sheeva P. schrieb: >> Dann bilde ich mir die endlosen Threads von Menschen, deren Hard- und / >> oder Software von aktuellen Betriebssystemversionen nicht mehr >> unterstützt wird, anscheinend nur ein? > > <irony> > Ja, bildest Du Dir nur ein. Darum muss man ja Win7 als target auch nicht > mehr supporten hust. > > Beweisidee: Nimm Python^^ > </irony> Mache ich ja, seit deutlich über zehn Jahren fast täglich -- buchstäblich. Nur bestehe ich nicht darauf, eine brandaktuelle Python-Version auf einem längst verstorbenen Betriebssystem zu benutzen... ;-) > Und darum ist mir nicht klar, warum gerade Python das nicht mehr tun > kann. Nicht kann. Will. Warum auch? Windows 7 ist tot, mausetot, seit über einem Jahr. Das Python es irgendwann nicht mehr unterstützen würde, wußte jeder seit den ersten Ankündigungen von Microsoft, den Support für Windows 7 einzustellen. >> Entschuldige bitte, aber all diese Probleme kann man bewältigen. >> Entweder selbst, oder mit ein bisschen Kleingeld für einen >> Dienstleister. > > Da sagt mir unsere GL immer dass man für das "bisschen Kleingeld" aber > auch eine kommerzielle SW, inkl. Wartungsvertrag, kriegen können. > Und bei den Tagessätzen die ich kenne stimmt das auch oft. Dann sollen sie diese kommerzielle Software doch bitte nehmen, alles gut. Sorry, aber wir scheinen hier gerade an einander vorbei zu reden... > Seit einiger Zeit ist es besonders "schick", die SW nicht zu kaufen > sondern zu mieten (siehe z.B. AutoDesk). Da hast Du immer die aktuellste > Version. > Ob das technisch sinnvoll ist sei mal dahingestellt. Ökonomisch betrachtet, ist das für beide Seiten zunächst sinnvoll: beide Seiten haben stabile und kalkulierbare Kosten und Umsätze. Zunächst. Denn natürlich ist es durchaus möglich, daß der Anbieter nach einer gewissen Zeit die Preise erhöht -- Benutzer von Atlassian-Software wie Confluence, Jira und Co. wissen, worüber ich rede -- und sich darüber hinaus eines bei Herstellern sehr beliebten Tricks bedient, um seine Kunden bei der Stange zu halten: einem Trick, den Juristen als "Einsperrung" bezeichnen. Dabei werden die Daten des Kunden in ein proprietäres Datenformat gepackt, aus dem der Kunde sie ohne Verluste oder den teuren Support des Herstellers kaum mehr herausbekommen kann... Ich ganz persönlich habe zu solchen Praktiken einige Anmerkungen, die den Rahmen dieses Threads sprengen würden und daher ein andermal erzählt werden sollen. Ich möchte daher an dieser Stelle nur daran erinnern, daß es für das Unternehmen hohe und womöglich sogar existenzbedrohliche ökonomische und unternehmerische Risken darstellen kann, nicht mehr Herr über die eigenen Daten und sich den Abomodellen und der wirtschaftlichen Situation des Herstellers samit auf Gedeih und Verderb auszuliefern... und ja, Geschäftsleitungen neigen leider manchmal dazu, derlei Risiken zu unterschätzen oder gar zu ignorieren. >> Die sehen einfach nur, daß sie auf aktuellen >> Betriebssystemversionen laufen müssen -- und zwar zwingend! -- während >> die Unterstützung veralteter und vom Hersteller abgekündigter >> Systemversionen wertvolle Ressourcen für eine schwindende Menge von >> Anwendern binden würde. > > Und da landen wir langsam beim eigentlichen Problem, oder? Ja, natürlich. Oder auch nicht. Das eigentliche primäre Problem ist aus meiner Sicht nämlich, daß einige wenige Menschen tote Software wie Windows 7 benutzen wollen. Das sekundäre Problem ist, daß sie da gleichzeitig einen tagesaktuellen Nightly Build einer Software benutzen wollen, die schnell weiterentwickelt wird. Das tertiäre Problem ist, daß diese seltsamen Menschen dann aber nicht gewillt sind, selbst etwas zu tun. Ich sehe dann noch einige weitere Probleme, aber wir wollen das hier mal nicht ausufern lassen... > KiCad würde (vermutlich) auch relativ gut mit Python 3.x (x<8) > hinkommen. Also eine Vermutung von Dir... und im Moment trifft sie vielleicht sogar noch zu. Aber tut sie das morgen auch noch? Auch Python entwickelt sich weiter, weißt Du, alleine 3.9 hat viele neue Features: einen neuen PEG-Parser statt des bisherigen LL-Parsers, demzufolge natürlich auch Änderungen im Abstract Syntax Tree, dazu kommen Erweiterungen in Modulen wie concurrent.futures, asyncio, multiprocessing und xml, obendrein neue Module wie graphlib (für Graphen, Überraschung) sowie zoneinfo für IANA-Zeitzonen. > Aber wird dieses Python zukünftig noch supported? D.h. Bug- & > Securityfixes. Ja. Python sichert 5 Jahre Support ab dem ersten Release zu, aber diese Zeit kann vom Release-Manager des betreffenden Release verlängert werden. Das ist etwa bei Python 2.7 passiert, dessen Support auf (fast) zehn Jahre erweitert wurde: erstes Release war am 3.7.2010, der Support ist am 1.1.2020 ausgelaufen. > Bei Linux u.a. klappt das doch meist ganz gut. Debian 9 wird zB noch bis > 2022 supported. Und da reden wir vom kompletten OS. Eine Programmiersprache ist aber kein Betriebssystem, fürchte ich... ;-) > Ich benutze (nicht bei KiCad) die Nightlies eher um zu probieren ob > alles noch klappt und ggf. einen Bugreport zu filen. Ich dachte dafür > sind die da^^ Das finde ich gut, und ja, (auch) dafür sind sie da. Aber die Idee kann nicht sein, daß die Weiterentwicklung einer Software aufgehalten wird, nur weil ein paar wenige Anwender sich zeitweise weigern, eine aktuelle und unterstützte Systemumgebung zu benutzen... Früher oder später müssen sie ja eh wechseln, sollen sich Softwareprojekte davon aufhalten lassen?
Uwe B. schrieb: > Virtuelle Maschinen? Warum nicht? Ich habe beispielsweise seit Jahren @work Altium in einer VM laufen (auf einem Linux-Host). Die läuft mittlerweile auch auf Win10, aber 99,9 % der Zeit ohne Netzwerkzugriff (host-only network). Das Netzwerk wird nur explizit freigeschaltet, wenn es aus irgendeinem Grund unbedingt nötig ist (bspw. während der Altium-Installation). Das funktioniert alles zusammen wunderbar. Vielleicht ein µ langsamer als direkt (habe ich keinen rechten Vergleich), aber allemal ausreichend schnell, als dass man damit gut arbeiten kann. Wenn man das Windows 10 nicht für Browser und all den Firlefanz benutzen muss, dann muss man ja auch nicht aller drei Tage einen Update einspielen. Wenn das Ding eh kein Netz hat, dann ist es ja auch nicht gefährdet. Und wenn man mal Windows-Updates einspielt, "Schalten Sie den Computer nicht aus" – dann wird auf einen anderen Bildschirm gewechselt und weiter gearbeitet, soll das Windows sich rebooten sooft es will.
Andreas H. schrieb: > Ach so. Das scheitert nur am fehlenden Maintainer? > Und ich dachte, die Python Community ist so riesig. Ist sie, aber hier geht es um die KiCAD-Entwickler-Community. > Danke für die Aufklärung :) Danke daß Du Dich als Maintainer gemeldet hast.. ach nee... ;-)
Andreas H. schrieb: > Jens B. schrieb: >> Wie wärs einfach mal eine stable Version zu nehmen, statt nigthly >> builds? > > Und wie wird die stabil ohne Tester? Es gibt sicherlich genug Tester. Nur keine, die unbedingt an ihrem verstorbenen Betriebssystem festhalten wollen... ;-)
W.S. schrieb: > Indem die Damen und Herren der Entwicklung MAL SELBER ihr Produkt > benutzen. Und ich meine tatsächlich benutzen, also echte Arbeit in der > Anwendung leisten und nicht bloß ne Demo angucken, ob die immer noch so > aussieht wie letztes Jahr. Das würde diesen Leuten auch erleichtern, ihr > Produkt mal aus der Perspektive der Anwender zu sehen. Wie kommst Du zu der böswilligen Unterstellung, daß die KiCAD-Entwickler ihr Produkt nicht benutzen würden?
Macht es nicht so kompliziert. Wenn der TO die aktuellste KiCad nightly installiert, dann muss er auch gefälligst die frischeste Win10 Entwicklerversion installieren. Alles andere macht keinen Sinn.
Sheeva P. schrieb: > Dabei hat das Python-Projekt mit PEP11 schon seit 2002 (!) > klare Policies, was den Support für ausgelaugene Betriebssysteme angeht. Naja, noch einen zum Feierabend :) PEP11 zitiere ich mal aus https://www.python.org/dev/peps/pep-0011/#microsoft-windows "CPython's Windows support now follows this lifecycle. A new feature release X.Y.0 will support all Windows releases whose **extended support phase is not yet expired**. Subsequent bug fix releases will support the same Windows releases as the original feature release (even if the extended support phase has ended)." Dazu noch Windows 7 (Professional, Enterprise) ESU-Enddatum Jahr 3: 10. Januar **2023** (ref. https://docs.microsoft.com/de-de/lifecycle/faq/extended-security-updates) /regards Edit: Die "**" sollten eigentlich **bold** werden. Klappt aber irgendwie nicht, sry ;)
:
Bearbeitet durch User
Gerader Ast schrieb: > Na dann "schönen Dank" an die Entwickler, nur wegen der > Scriptsprache > mein liebstes OS nicht mehr zu unterstützen. > Und der süffisante Satz ein up-to-date OS zu verwenden können sie sich > sonstwohin schieben. Wenn das etwas angepisst klingt, liegt das daran > daß ich angepisst bin. Lol, ein uralt OS benutzen aber die Nightly von KiCad 😂 Dann benutz doch das letzte Nightly, das noch funktioniert, für die restliche Lebenszeit deines Windows 7 ;-)
Uwe B. schrieb: > Welche Alternative zum stabilen Win7 gibt es denn wirklich für ein > Produktivsystem auf dem auch verschiedene unverzichtbare WIN-Software > (CAD, CAM, SPS-Prog.) laufen muß. Im Kleinbetrieb, ohne > fulltime-IT-Droiden. WIN10? Ernsthaft? Dual Boot, Virtuelle Maschinen? > Nee, wirklich. Ich bin da verwöhnt. Ja, Win 10. Du bekommst Win7 auf aktueller Hardware mangels Treibern gar nicht mehr richtig installiert. Fast immer fehlt der passende Grafiktreiber, inzwischen auch USB (aktuelle Boards haben nur noch XHCI, und das kennt Win7 bei der Installation noch nicht), dann die diversen Anpassungen des Schedulers an moderne CPUs, etc etc. Ist halt so. fchk
Uwe B. schrieb: > Welche Alternative zum stabilen Win7 gibt es denn wirklich für ein > Produktivsystem auf dem auch verschiedene unverzichtbare WIN-Software > (CAD, CAM, SPS-Prog.) laufen muß. Für solch proprietäre SW einen rostigen PC hinstellen und für aktuelle SW einen aktuellen PC mit aktuellem OS benutzen. Oder halt eine VM, aber das willst Du ja nicht. Ich persönlich halte ein altes Netbook mit XP und eine virtuelle Maschine mit 64-bit Win7 bereit wenn ich mal mit einer Win SW arbeiten muß.
Jörg W. schrieb: > Uwe B. schrieb: >> Virtuelle Maschinen? > > Warum nicht? Ich habe beispielsweise seit Jahren @work Altium in einer > VM laufen Ich stelle mir gerade vor wie Kicad unter Win10 auf einer virtuellen Maschine auf einem Win7-Host läuft :-( > auf einem Linux-Host Bin ich ja sonst auch Fan von, Server, ERP (Kivitendo), Bürorechner, Telefonanlage, alles Linux. Nur auf dem Platz wo ich entwickele passt das nicht weil einiges an Winonly-Software gebraucht wird. Und auf den Servicelaptops. Einer noch unter XP, weil tut einfach. Uwe
Uwe B. schrieb: > Ich stelle mir gerade vor wie Kicad unter Win10 auf einer virtuellen > Maschine auf einem Win7-Host läuft :-( Die Nightly läuft bei mir auf einem Win10 Host in einer Lubuntu VM. Auf einem alten I5 T420 mit HD3000 Graphics. Performance ist okay. Besser als Mentor PADS auf einem brandneuen I7. Der Sinn des ganzen ist, das die HD3000 nicht mehr vollständig unter WIN10 unterstützt wird. Kicad 5.1.9 hat kein Problem damit und nutzt openGL. Die Nightly kann aber nur noch unbeschleunigten Modus, keine 3D Ansicht und meckert OpenGL 2.1 stünde nicht zur Verfügung. Unter Lubuntu gehts aber super. Gerader Ast schrieb: > Installer sagt Minimum Windows 8.1. > Gibt es irgendeinen Workaround, Ja, machs wie ich ;-)
Uwe B. schrieb: >> Warum nicht? Ich habe beispielsweise seit Jahren @work Altium in einer >> VM laufen > > Ich stelle mir gerade vor wie Kicad unter Win10 auf einer virtuellen > Maschine auf einem Win7-Host läuft :-( Dann kannst du in der VM auch gleich ein Linux installieren. Ansonsten: warum soll die Performance schlechter sein als anders herum? Es gibt ja (abgesehen von irgendwelchen Virenchecker-Performance-Bremsen) keinen technischen Grund. >> auf einem Linux-Host > > Bin ich ja sonst auch Fan von, Server, ERP (Kivitendo), Bürorechner, > Telefonanlage, alles Linux. Nur auf dem Platz wo ich entwickele passt > das nicht weil einiges an Winonly-Software gebraucht wird. Naja, wie geschrieben: verbanne selbigen Kram in die VM. Virtualisierung ist heutzutage wirklich keine nennenswerte Performancebremse mehr. Selbst der 3D-Kram im Altium läuft flüssig.
Mampf F. schrieb: > Lol, ein uralt OS benutzen aber die Nightly von KiCad Ist doch logisch. Das Windows7 ist bereits ausgereift, Kicad ist dies eben noch lange nicht. Da hofft offensichtlich so mancher Kicad-Benutzer auf Verbesserungen und Beseitigung alter Bugs. Und nun so ein vermutlich völlig unnötiger Affront gegen Leute, die Windows 7 in Benutzung haben. Um das mal recht zu sehen: Wenn irgendwas wirklich vonnöten ist, dann versteht man das ja auch. Aber wenn es bloß irgendein Schmankerl ist, dann ist es ein Ärgernis. Nebenbei: Kann man Kicad denn auch gänzlich ohne Python benutzen? Und all das Getöse mit "uralt", "mausetot", "gestorben" und dergleichen ist eine dämliche Polemik. Wenn man die Verbreitung von Win7 mal anschaut und mit Win8 oder 8.1 oder gar mit Linux vergleicht, dann sind diese drei und insbesondere Linux noch viel "mausetöter" als Win7. W.S.
W.S. schrieb: > Das Windows7 ist bereits ausgereift, Kicad ist dies eben noch lange > nicht.Das Windows7 ist bereits ausgereift, Kicad ist dies eben noch lange nicht. Nur für dich nicht. Für viele andere ist das mindestens genauso ausgereift wie Windows 7. > Nebenbei: Kann man Kicad denn auch gänzlich ohne Python benutzen? Selbstverfreilich. Das ist nur für Scripting + Plugins da.
W.S., kannst du "Walk the Talk", wie es bei uns in der Firma gerne propagiert und umgesetzt wird? Das ist es was OSS im Grunde ausmacht. Klugscheißen kann jeder, mach ich auch gerne, aber was am Ende zählt ist die Umsetzung. Wer beim Reden stecken bleibt muss sich damit zufrieden geben was andere, die auch den "Walk" beherrschen dir am ende servieren. Manche scheinen zu glauben dass OSS versuchen muss jeden Nutzer auf biegen und brechen zu halten wie es Firmen teilweise tun. Aber wer keinen Code oder Dokumentation schreibt, im Forum produktiv mithilfe oder zumindest etwas spendet ist im Grunde ein Beifahrer dessen fehlen niemanden auffallen wird, außer er beschwert sich lauthals, und dann ist es eher anstrengend. Und dann gibt es die Spezialisten die dir sagen wenn du das und das machst steig ich bei dir ein. Und ich denke mir, dass kostet am ende nur Nerven und bringt mir persönlich eigentlich gar nix, außer Stress. Im Grunde ist es mir als Entwickler egal ob du jetzt meine Software oder irgendeine andere nutzt.
Andreas H. schrieb: > Sheeva P. schrieb: >> Dabei hat das Python-Projekt mit PEP11 schon seit 2002 (!) >> klare Policies, was den Support für ausgelaugene Betriebssysteme angeht. > > Naja, noch einen zum Feierabend :) Ja, zum Feierabend ist man ja oft ein bisschen schlapp... ;-) > PEP11 zitiere ich mal aus > https://www.python.org/dev/peps/pep-0011/#microsoft-windows > > "CPython's Windows support now follows this lifecycle. A new feature > release X.Y.0 will support all Windows releases whose **extended support > phase is not yet expired**. Subsequent bug fix releases will support the > same Windows releases as the original feature release (even if the > extended support phase has ended)." > > Dazu noch Windows 7 (Professional, Enterprise) ESU-Enddatum Jahr 3: 10. > Januar **2023** > > (ref. > https://docs.microsoft.com/de-de/lifecycle/faq/extended-security-updates) Das bezieht sich auf die "Extended Security Updates". Die sind etwas anderes als die "Extended Support Phase", welche für Windows 7 am 14. Januar 2020 geendet hat. Klar, das kann man mal verwechseln, Microsofts Terminologie ist leider wieder einmal ein bisschen... undeutlich und verwirrend.
W.S. schrieb: > Und all das Getöse mit "uralt", "mausetot", "gestorben" und dergleichen > ist eine dämliche Polemik. > > Wenn man die Verbreitung von Win7 mal anschaut und mit Win8 oder 8.1 > oder gar mit Linux vergleicht, dann sind diese drei und insbesondere > Linux noch viel "mausetöter" als Win7. Man sieht, daß Du Dich mit "dämlicher Polemik" am Besten auskennst. Könnte einer der geschätzten Moderatoren diesen... "Herrn" bitte endlich mal entsorgen?
Hallo W.S. W.S. schrieb: > Ist doch logisch. Das Windows7 ist bereits ausgereift, Reif, Überreif, Faul und schimmelig. ;O) > Kicad ist dies > eben noch lange nicht. Da hofft offensichtlich so mancher Kicad-Benutzer > auf Verbesserungen und Beseitigung alter Bugs. Und nun so ein vermutlich > völlig unnötiger Affront gegen Leute, die Windows 7 in Benutzung haben. Vermutlich haben diese Leute noch Windows 7 in Benutzung, weil ihre Uralt Eagle Version von vor den Mietversionen auf nix anderem mehr läuft? Nimm den abgelegten Zocker-PC von Deinen Enkeln und installiere ein aktuelles Linux und KiCad und gut ist. Den alten Windows 7 Rechner kannst Du ja immer noch gelegentlich mal einschalten. Nur damit ins Internet solltest Du Dir verkneifen. Wer kein OpenSource mag weil ihm zu unheimlich, der mag garantiert auch nicht Teil eines Bot-Netztes werden. ;O) > Nebenbei: Kann man Kicad denn auch gänzlich ohne Python benutzen? Ist nur für Skripting und Plugins. Es könnte aber sein, dass Du gerne ein Plugin zur BOM erstellen hättest. Das eingebaute ist etwas spartanisch.... Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Wenn lediglich ...windows/nightly aufgerufen wird gelangt man zu den Versionen die MSVC verwenden und dadurch wird der Level auf Windows 8.1 und + gesetzt. >von Gerader Ast (Gast) >Gibt es irgendeinen Workaround Ja gibt es, einen Mausklick ! investieren, oben im Verzeichnis auf "msys2" klicken.KiCAD wird zumindest, Stand 9.April 2021, wie bisher ohne MSVC und mit Phyton 2.7, zusätzlich compiliert. Getested habe ich die kicadr22050..i686-lite Version. https://kicad-downloads.s3.cern.ch/index.html?prefix=windows/nightly/msys2/ Versionsinfo Application: KiCad-Schaltplan-Editor Version: (5.99.0-10192-g8d0191151d), release build Libraries: wxWidgets 3.0.5 libcurl/7.71.0 OpenSSL/1.1.1g (Schannel) zlib/1.2.11 brotli/1.0.7 libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.41.0 Platform: Windows 7 (build 7601, Service Pack 1), 32 bit, Little endian, wxMSW Build Info: Date: Apr 9 2021 10:10:18 wxWidgets: 3.0.5 (wchar_t,wx containers,compatible with 2.8) Boost: 1.73.0 OCE: 6.9.1 Curl: 7.71.0 ngspice: 34 Compiler: GCC 10.2.0 with C++ ABI 1014 Build settings: KICAD_SCRIPTING=ON KICAD_SCRIPTING_MODULES=ON KICAD_SCRIPTING_PYTHON3=OFF KICAD_SCRIPTING_WXPYTHON=ON KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF KICAD_SCRIPTING_ACTION_MENU=ON KICAD_USE_OCE=ON KICAD_SPICE=ON Also ein Danke schön an die Entwickler. Von der Hardware her gibt es sicher nach unten hin irgendwo Grenzen, der 3D-Betrachter von 5.99 erfordert etwa eine höhere OpenGL Version ( 2.1 ) laut Angabe. Ach so, die verwendete "Windows-Version" war hier wine-4.0-rc7....
Dieter P. schrieb: > und mit Phyton 2.7 Da diese Version bereits seit geraumer Zeit obsolet ist (etwas länger schon als Windows 7), würde ich mich darauf jedoch nicht verlassen. Der entsprechende Build könnte von heute auf morgen verschwinden.
Jörg W. schrieb: >> Nebenbei: Kann man Kicad denn auch gänzlich ohne Python benutzen? > > Selbstverfreilich. Das ist nur für Scripting + Plugins da. Wenn das so ist, dann ist doch dieser gesamte Thread hinfällig und die ganze Diskussion hier über Win7 kann ersatzlos entfallen. Naja, wenigstens ein klares Wort von dir unter all diesem aufgeregten Gegacker. Danke für diese Klarstellung. W.S.
Thomas P. schrieb: > Manche scheinen zu glauben dass OSS versuchen muss jeden Nutzer auf > biegen und brechen zu halten wie es Firmen teilweise tun. Aber wer > keinen Code oder Dokumentation schreibt, im Forum produktiv mithilfe > oder zumindest etwas spendet ist im Grunde ein Beifahrer dessen fehlen > niemanden auffallen wird, außer er beschwert sich lauthals, und dann ist > es eher anstrengend. Und dann gibt es die Spezialisten die dir sagen > wenn du das und das machst steig ich bei dir ein. Und ich denke mir, > dass kostet am ende nur Nerven und bringt mir persönlich eigentlich gar > nix, außer Stress. Im Grunde ist es mir als Entwickler egal ob du jetzt > meine Software oder irgendeine andere nutzt. Dann behalte doch einfach deine Software für dich! Programmiere das Zeugs im stillen Kämmerchen, und schmeisse es dann ins /dev/null... Das freut insbesondere die Leute, deren Arbeitsplätze von Closed Source abhängen, die können dann ihre Familien durchfüttern, und haben keinen Stress. OSS ist nur allzuoft eine moderne Form der Arbeitsausbeutung, wobei die Programmierer durch mentale Kondition von kleinauf an nicht mal mehr merken, was da abgeht... In früheren Jahrhunderten wurden solche Leute von ihren Standesgenossen geterrt und gefedert. Google freuts, die verdienen mit der Arbeit der OSS Leute Milliarden.
Thomas P. schrieb: > W.S., kannst du "Walk the Talk", wie es bei uns in der Firma gerne > propagiert und umgesetzt wird? Nö. Ich kann dafür noch etwas Latein - und du? Kannst du Latein? > Das ist es was OSS im Grunde ausmacht. Wenn das tatsächlich so sein sollte und all die OSS-Schreiber es nur tun, um sich damit brüsten zu können, dann ist das ganze ein Schuß in den Ofen. Nein, ich bin davon überzeugt, daß ein Großteil der Leute, die freie Software schreiben, es darum tun, der Welt ein Gutes zu tun. Sowas nennt man "sich GEGENSEITIG helfen" oder auch das Gemeinwohl. Der eine kann programmieren, der andere kann Geräte konstruieren, der nächste kann Elektronik oder höhere Mathematik und so weiter. Erwarte also nicht, daß der Mathematiker oder der Elektroniker das Programmieren anfängt, bloß um beim Schreiben von OSS mitzuschreiben. So herum geht das nämlich nicht. Aber der Konstrukteur kann dem Programmierer sagen, was er an dessen Programm gut oder mies findet. > Klugscheißen kann jeder, mach ich auch gerne.. Ja, das sehe ich. Aber erwarte nicht vom Anwender, daß er der bessere Programmierer ist. Der Programmierer ist nämlich auch nicht der bessere Anwender. > Im Grunde ist es mir als Entwickler egal ob du jetzt > meine Software oder irgendeine andere nutzt. Nochmal: Werde nicht persönlich, sondern bleibe auf der sachlichen Ebene. Allerdings sehe ich aus deiner Äußerung, daß du im Grunde die Anwender verachtest. Deshalb sortiere ich dich ein als einen eitlen Geck. W.S.
Frank K. schrieb: > . Du bekommst Win7 auf aktueller Hardware mangels Treibern gar > nicht mehr richtig installiert. Quatsch. Eine kleine Änderung am System und Win-7 hört sogar das lügen auf.
Ach und nur so nebenbei. Bei mir müsste ich eine Menge an Hardware neu kaufen und unnötigen Elektroschrott produzieren weil es genau umgekehrt ein Problem ist. Die Hardware (Dia-Scanner etc) läuft nämlich nicht mehr unter Win-10.
Jörg W. schrieb: > aber ich kann auch nicht verstehen, warum unterstellt wird, dass > Windows-Nutzer zu blöd seien, einen Compiler zu installieren Vielleicht weil viele Windows-Nutzer nicht mit dem PC ins Bett gehen? Weil sich vielleicht viele Windows-Nutzer als reine Anwender verstehen? Bin seit Win3.11 dabei und kann keinen Compiler installieren, geschweige denn bedienen. Was ist los mit mir, bin ich krank?
Bertram. R schrieb: > Jörg W. schrieb: >> aber ich kann auch nicht verstehen, warum unterstellt wird, dass >> Windows-Nutzer zu blöd seien, einen Compiler zu installieren > > Vielleicht weil viele Windows-Nutzer nicht mit dem PC ins Bett gehen? Was soll die darin enthaltene dümmliche Unterstellung? > Weil sich vielleicht viele Windows-Nutzer als reine Anwender verstehen? Ja, und? Auch als reiner Anwender darf man in der Lage sein, einen Compiler einzuschalten. Das heißt ja noch lange nicht, dass man auch selbst Code schreiben muss.
Bertram. R schrieb: > Jörg W. schrieb: >> aber ich kann auch nicht verstehen, warum unterstellt wird, dass >> Windows-Nutzer zu blöd seien, einen Compiler zu installieren Installieren ist was anders, als eine Software die man nicht selbst geschrieben hat, damit zu compilieren. Ich weiß zwar nicht wie das bei den Kicad ist, aber wenn ich auch nur ein Klick in meiner Projekt-Datei falsch habe, läuft meine Software nicht. Und das war schon unter DOS so. JEDER Compiler den ich bisher gestartet habe, brauchte Parameter ohne Ende damit er wusste was er mit den Quellcode anfangen kann. Aber ich sage es mal so. Wenn es so einfach, bzw. nicht zu schwer ist, ist es auch nicht wirklich schwer eine passende SETUP.EXE zu bekommen die unter Windows 7 läuft. Ist es aber zu schwer, wird es besagte SETUP.EXE nicht geben. Von daher ist die Diskussion in meinen Augen überflüssig. KICAD hat genug Fans die Win-7 nutzen und wenn es irgend wie möglich + Legal ist, eine SETUP.EXE für Win-7 ins Netz stellen. Und je nach dem welcher Lüge man glaubt, liegt der Marktanteil von Win-7 bei 8-25%. Hab das mal gegoogelt. Womit das Thema EXOT schon mal vom Tisch ist. Win-7 ist halt zu beliebt deshalb hat MS die "Kostenlosen Upgrades" auch noch nicht geblockt ;)
Irgendwas ist mit der Bewertungsfunktion schief. Immer wenn ich jemanden Hochvoten will, ist er danach negativ :/ Nur falls sich jemand wundert^^
Jörg W. schrieb: > Auch als reiner Anwender darf man in der Lage sein, einen > Compiler einzuschalten. Das heißt ja noch lange nicht, dass man auch > selbst Code schreiben muss. Autsch, Jörg. Das ist so wie: Auch als reiner Autofahrer darf man in der Lage sein, ein Auto zu reparieren. Das heißt ja noch lange nicht, dass man auch selbst Autos konstruieren muss. Es gibt auch durchaus Leute, die Elektronik machen und keine Ahnung vom Programmieren haben. Schlaumaier schrieb: > Aber ich sage es mal so. Wenn es so einfach, bzw. nicht zu schwer ist, > ist es auch nicht wirklich schwer eine passende SETUP.EXE zu bekommen > die unter Windows 7 läuft. > > Ist es aber zu schwer, wird es besagte SETUP.EXE nicht geben. Von daher > ist die Diskussion in meinen Augen überflüssig. > Schlaumaier schrieb: > Und je nach dem welcher Lüge man glaubt, liegt der Marktanteil von Win-7 > bei 8-25%. Hab das mal gegoogelt. Womit das Thema EXOT schon mal vom > Tisch ist. Win-7 ist halt zu beliebt deshalb hat MS die "Kostenlosen > Upgrades" auch noch nicht geblockt ;) I owe you a beer /regards
Andreas H. schrieb: > Auch als reiner Autofahrer darf man in der Lage sein, ein > Auto zu reparieren. Das heißt ja noch lange nicht, dass man auch > selbst Autos konstruieren muss. Nicht reparieren (das beinhaltet die Fehlersuche), sondern zusammenschrauben (nach Anleitung). Wenn das Zusammenschrauben eines Autos so einfach wäre wie das Installieren und Benutzen eines Compilers, würde es sicher auch mehr geben, die das tun. ;-) (OK, der Vergleich hinkt natürlich dahingehend, dass bei Auto das ganze Thema Verkehrssicherheit danach kommt. Wenn dein selbst compiliertes Binary nicht funktioniert, fügst du niemandem anders potenziell Schaden zu.) > I owe you a beer Für die Bestätigung, dass Windows 7 deutlich marginal in der Anwenderzahl ist? Hmm. Wenn irgendwelche Linux-Statistiken ähnliche Anwenderzahlen präsentieren, heißt es doch immer: "Ist überhaupt nicht relevant, zu kleiner Marktanteil." ;-)
Jörg W. schrieb: >> I owe you a beer > > Für die Bestätigung, dass Windows 7 deutlich marginal in der > Anwenderzahl ist? Nö. Hauptsächlich für seine Ansichten zum Thema Compilieren & Setup.exe. > Wenn irgendwelche Linux-Statistiken ähnliche Anwenderzahlen > präsentieren, heißt es doch immer: "Ist überhaupt nicht relevant, zu > kleiner Marktanteil." ;-) Wenn Linux im Serverbereich NUR 10-20% hätte, dann würde mich das sehr erschrecken. Wenn Linux im Officbereich 10-20% hätte, dann würde mich das sehr freuen. Aber wenn man sich den Markanteil von Z/OS betrachtet ... /regards
:
Bearbeitet durch User
W.S. schrieb: > Da hofft offensichtlich so mancher Kicad-Benutzer > auf Verbesserungen und Beseitigung alter Bugs. Tja, da kannst Du dann ja Altium für 6K kaufen + einen fett honorierten Wartungsvertrag und trotzdem bekommst Du keine Bugfixes. Oder Du kauft Dir alle Hauptversionen ein neues Target in der Hoffnung die Bugs wären raus. Oder Eagle, Pulsonix, Zuken etc. pp. Ist schon eine echte Unverschämtheit das Kicad für Lau unters Volk gebracht wird und dann kommt noch nicht mal jemand vorbei, kocht Dir einen Kakao, streicht Dir übers Haar und behebt Deine Probleme. Ich nutze Kicad Produktiv und bin soweit zufrieden. Ich nutze NICHT Eagle, Protel99SE oder Mentor, obwohl ich das könnte. Mentor ist ohnehin ein Pulverfass. Der Lizenzserver steht bei beim Kunden und das ist immer sehr spaßig, wenn man morgens den Rechner startet und Mentor mal wieder seine Lizenzen nicht findet, weil ein Update kam, es regnet, in Peking ein Sack Reis umgefallen ist oder gerade eine Internetstörung vorliegt. Dann kann ich so lange was anderes machen bis die Kunden IT Zeit hat mit dem Siemens Support zu sprechen, wann der Zeit hat... So lange geht GARNICHTS bei Mentor. Nicht mal das Projekt kann man ansehen und einen lizenzlosen Viewer gibts auch nicht. Ich werde auf garkeinen Fall irgendetwas einsetzen bei dem irgendeine nicht lokale Lizenz benötigt wird oder ich zwingend Internet brauche. Kicad hat seine Schwächen wie JEDE andere Software auch, aber Dein permanentes beklagen über Kicad, das Du doch offensichtlich überhaupt nicht verwendest und es auch nicht vorhast, geht nicht nur mir einfach auf den Sender. Bekomm den Hintern hoch und lerne damit umzugehen und die Stärken zu entdecken oder halt einfach mal den Schnabel wenn es um Kicad geht.
Jörg W. schrieb: > Installieren und Benutzen eines Compilers, würde es sicher auch mehr > geben, die das tun. ;-) Ahja really? :rolling-eyes: Installier dir doch mal zB npm und kompilier eine x-beliebige Electron-Anwendung ... Das wirst du nie und nimmer hinbekommen 😂 Das schaffen schon Linux-versierte Programmierer kaum ;-)
mkn schrieb: > Kicad hat seine Schwächen wie JEDE andere Software auch, aber Dein > permanentes beklagen über Kicad, das Du doch offensichtlich überhaupt > nicht verwendest und es auch nicht vorhast, geht nicht nur mir einfach > auf den Sender. Ist ja sonnenklar: Alle Fanboys kriegen sofort schlechte Laune, wenn irgend jemand ihren Liebling nicht in den höchsten Tönen lobt - und wenn jemand gar eine Kritik äußert, dann kommt ihnen der Zorn hoch. Aus meiner Sicht ist das hier ein Treppenwitz. W.S.
W.S. schrieb: > Aus meiner Sicht ist das hier ein Treppenwitz. Kritik ist kein Problem – im Gegenteil. Der Treppenwitz sind Leute, die wild rumranten, als hätten sie die Entwicklung komplett selbst bezahlt, und daher irgendwelche Ansprüche – dabei haben sie oft nicht mal einen noch so kleinen Beitrag geleistet, sondern eher noch durch ihr Gehabe Ressourcen gebunden, die woanders sinnvoller genutzt worden sein könnten. Wer KiCAD nicht mag, geht halt hin und gibt irgendwem Geld, und nutzt dafür dessen Software. Dann kann er dessen Support entsprechend volllabern, wenn was nicht wie erwartet funktioniert. Oder er schreibt sich selbst was – wenn man die betreffenden Leute so liest, ist das ja alles gaaanz einfach, und die Leute, welche die Software entwickeln, sind halt nur Idioten.
Mampf F. schrieb: > Installier dir doch mal zB npm Es ging aber um Kicad und MSVC. Nicht alles, was hinkt, ist ein Vergleich …
Solange die nicht das Datenformat der Bauteile ändern ist mir die Version völlig egal. Und wenn sie es machen gibt es vermutlich ein Konverter der die auf das alte Format runter rechnet. Und das diese "Ich mache immer was neues" angeht. Programmierer müssen auch leben oder sich bestätigt wissen.
Schlaumaier schrieb: > Und wenn sie es machen gibt es vermutlich ein > Konverter der die auf das alte Format runter rechnet Du meintest das wohl umgekehrt. ;-) Das alte Format will dann niemand mehr haben. > Und das diese "Ich mache immer was neues" angeht. Programmierer müssen > auch leben oder sich bestätigt wissen. Nö, die programmieren nur für die "Ich will immer das Neueste haben" Fraktion. Der TO ist ja das beste Beispiel dafür.
W.S. schrieb: > Ist ja sonnenklar: Alle Fanboys kriegen sofort schlechte Laune, wenn > irgend jemand ihren Liebling nicht in den höchsten Tönen lobt - und wenn > jemand gar eine Kritik äußert, dann kommt ihnen der Zorn hoch. Hast Du überhaupt schon mal irgendwas anderes als Eagle benutzt? Du produzierst doch nur heiße Luft. WENN ich ein Fanboy bin, nachdem ich mit Protel, Altium, Eagle, Orcad, Target und Mentor gearbeitet habe, wirft das ja kein so schlechtes Licht auf Kicad, oder? Anfangs mochte ich Kicad garnicht und natürlich gibt es heute auch noch einiges das mich daran stört. Aber ich bin es einfach leid Software für immer absurdere Preise zu kaufen, die dann buggy und zugedongelt sind. Jahrelanges warten mit Wartungsvertrag (deswegen heißt der wohl so...) ohne das mal die Probleme gelöst werden. Kannst ja mal zu Siemens gehen und Dir ein Angebot für Mentor machen lassen. Oder Du fragst mal Altium wann denn eigentlich die Funktionen an Protel99SE funktionieren, die die uns vor 22 Jahren verkauft haben und die bis heute vollmundig in dem Handbuch beworben werden. Oder Du versuchst von Autodesk eine Preis. und Funktionsgarantie für deren Mietadler zu bekommen. Wie war das gleich mit dem kostenlosen Fusion 3D? Ein Jahr anfixen und dann Zahlemann und Söhne! Ich möchte mich nicht irgendwann mal in der Position wiederfinden, das mir die Lizenz entzogen wird weil US technologie nicht an Staaten geliefert werden darf die es wagen z.B. Erdgas vom Klassenfeind zu kaufen. Ich habe mich dann irgendwann rangesetzt an Kicad, habe mit dem meckern aufgehört und angefangen reale Projekte damit bis zum Ende durchzuziehen. Heute umschiffe ich die Schwachstellen und erfreue mich an den genialen Funktionen die oft genug durch exteren Plugins bereitgestellt werden. Z.B. die 3D Unterstützung mit Freecad ist genial. Die interactive HTML BOM ist bei der Prototypenbestückung eine derart brutal gute Unterstützung das alleine das so einige Dinge vergessen lässt bei der Kicad sich nicht mit Ruhm bekleckert. Ich freue mich schon auf Kicad 6. Die nightly sieht schon mal ganz aufgeräumt aus aber für den Produktiveinsatz ist mir das noch zu heiß. Von welcher Software kannst Du das behaupten, das Du permanent bugfixes und neue Versionen bekommst ohne auch nur einen Cent dafür zu zahlen? Da grinst Dir kein Vertriebsknecht ins Ohr und erzählt Di süffisant das Du leider eine neue Vollversion bezahlen musst damit die Funktion die Du bereits gekauft hast auch mal geht, weil Du leider nicht bereit warst >1K/Jahr für einen völlig nutzlosen Wartungsvertrag auszugeben. Du meckerst aber immer nur weil Dir irgendwelche reichlich theoretischen Hintergründe an Kicad nicht passen und vergleichst immer nur mit dem einzigen das Du kennst. Wer ist hier also Fanboy, der ausflippt wenn jemand sein persönliches Schätzchen nicht zu würdigen weiß? Erzähl doch mal irgendwas sinnvolles und stell hier die Software vor die alles das leistet was Kicad bereits kann, ohne uns in Knechtschaft und Armut zu halten. Immer nur den bockigen alten Mann zu geben der ein Haar in der Suppe findet ohne irgendeine bessere Alternative benennen zu können ist einfach nur ödes rumgenerve. Für ein konstruktive Auseinandersetzung bin ich immer zu haben, aber die sehe ich bei Dir nicht.
Jörg W. schrieb: >> Nebenbei: Kann man Kicad denn auch gänzlich ohne Python benutzen? > > Selbstverfreilich. Das ist nur für Scripting + Plugins da. Geht hier nicht. Getested mit KiCAD 5.0.2.1 und kicad-r22066.176fcd43d8-i686-lite.exe . Wenn das Verzeichnis "python2.7" schlicht umbenannt wird, geht der Aufruf von KiCAD und Eeschema. Pcbnew aufrufen, führt hier zum sofortigen Absturz von KiCAD, bei beiden erwähnten Versionen. Die verwendete Windows-Version dürfte dabei auch ziemlich egal sein. Auch wenn ich mich wiederhole, KiCAD nightly ( ohne MSVC ) wird derzeit teils 2 x täglich neu gebaut.Ob der Grund dafür ist, sonst von MS bei der MSVC-Runtime abhängigig zu sein? Nachdem MS das CERN zu einem kommerziellen Unternehmen umgestuft hat, mit entsprechenden Lizenzkosten, macht man sich dort über diesen Laden ( MS ) sicher so seine Gedanken. (JavaScript ein) https://kicad-downloads.s3.cern.ch/index.html?prefix=windows/nightly/msys2/ Betriebssystemversion einfach ausprobieren. W7 .. W10, älteres mit Einschränkungen? Wine unter Linux, 32Bit, für Profis eher nicht. Nachdem ja erwähnt wird, das KiCAD V6 nur ab W8.1 laufen soll ( die MSVC-Versionen ), wäre eine Abschätzung zur Zukunft von "/msys2/" sicher hilfreich. Die Installation im Menü ist unter KiCad 5.99 und sollte parallel zu 5.x testbar sein.Ob es Probleme mit Dateipfaden gibt, kann ich nicht beurteilen.
Dieter P. schrieb: >>> Nebenbei: Kann man Kicad denn auch gänzlich ohne Python benutzen? >> >> Selbstverfreilich. Das ist nur für Scripting + Plugins da. > > Geht hier nicht. > Getested mit KiCAD 5.0.2.1 und kicad-r22066.176fcd43d8-i686-lite.exe . Ja klar, das ist eine compile time option. Du kannst dann nicht einfach dem compilierten Binary sein Python entziehen. Auszug aus CMakeLists.txt
1 | option( KICAD_SCRIPTING |
2 | "Build the Python scripting support inside KiCad binaries (default ON)." |
3 | ON ) |
4 | |
5 | option( KICAD_SCRIPTING_MODULES |
6 | "Build native portion of the pcbnew Python module: _pcbnew.{pyd,so} for OS command line use of Python."
|
7 | ON ) |
8 | |
9 | option( KICAD_SCRIPTING_PYTHON3 |
10 | "Build for Python 3 instead of 2 (default OFF)." |
11 | OFF ) |
12 | |
13 | option( KICAD_SCRIPTING_WXPYTHON |
14 | "Build wxPython implementation for wx interface building in Python and py.shell (default ON)." |
15 | ON ) |
16 | |
17 | option( KICAD_SCRIPTING_WXPYTHON_PHOENIX |
18 | "Use new wxPython binding (default OFF)." |
19 | OFF ) |
20 | |
21 | option( KICAD_SCRIPTING_ACTION_MENU |
22 | "Build a tools menu with registered python plugins: actions plugins (default ON)." |
23 | ON ) |
(Das ist noch etwas älter als die hier diskutierte Version. Vermutlich ist jetzt KICAD_SCRIPTING_PYTHON3 standardmäßig angeschaltet oder sogar gar keine Option mehr.)
Danke, so tief bin ich da nicht drin.Wenn man Python-Scripte verwenden möchte, muss es also schon beim Compiler eingeschaltet sein.Es war halt ein Gedanke, ob wirklich die ca 3000 Files unter Python27 sein müssen, nur eine eigene Version "bauen" um zu spielen, ist hier nicht möglich. Die Settings, da kann man sich dann austoben, je nach Bedarf. Application: KiCad Version: (5.99.0-10208-g176fcd43d8), release build Build Info: Date: Apr 10 2021 10:13:28 wxWidgets: 3.0.5 (wchar_t,wx containers,compatible with 2.8) Compiler: GCC 10.2.0 with C++ ABI 1014 Build settings: KICAD_SCRIPTING=ON KICAD_SCRIPTING_MODULES=ON KICAD_SCRIPTING_PYTHON3=OFF KICAD_SCRIPTING_WXPYTHON=ON KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF KICAD_SCRIPTING_ACTION_MENU=ON KICAD_USE_OCE=ON KICAD_SPICE=ON
Auch wenn das Topic schon älter ist: Ich denke es gibt eine weitere Lösung für das Problem: Kicad hält für alle externen Libs eine Kopie im eigenen Repository vor. Zum einen hat man dadurch eine bessere Kontrolle über die verwendeten Versionen und zum anderen können eigene Patche eingespielt werden. Und wenn man sich dann mal das Python Repo ansieht: https://gitlab.com/kicad/packaging/vcpkg/-/tree/kicad/ports/python3 dann sieht man das die Kicad-Entwickler selber einen Patch bereit stellen um Python 3.9 wieder zu Windows 7 kompatibel zu machen. Der Patch wird per Default nicht verwendet, aber man kann ihn via Featureflag aktivieren. Kicad selber zu bauen ist zwar zeitaufwändig, aber nicht ewig kompliziert und hier erklärt: https://dev-docs.kicad.org/en/build/ Mit dieser Vorgehensweise funktioniert Kicad6 auch unter Windows7 ohne Einschränkungen. Wenn man obigen Patch einspielt, dann bekommt man bei jedem Start allerdings einen Nag-Screen. Den kann man in dieser Funktion abschalten: https://gitlab.com/kicad/code/kicad/-/blob/master/libs/kiplatform/msw/app.cpp#L47 Weihnachtliche Grüsse
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.