KiCAD nightly Install geht nicht mehr unter Windows 7

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.

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ß. ;-)

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.

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?

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?

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 ;-)

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...

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

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.

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.

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.

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.

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

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

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. 
;-)

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.

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

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

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.

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?

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?

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 ;)

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:

>> 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.

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.

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.

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.

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

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 ;-)

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 …

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.

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