Liebe Forenden, angeregt durch diesen [1] Thread, habe ich das aktuelle Kicad samt Libraries in Docker eingepackt und ein kleines Makefile zum Bau eines Image und Start eines Containers mit Kicad gebastelt. Voraussetzungen =============== Voraussetzung ist, daß lokal Docker, make und envsubst (Paket gettext-base) installiert sind. (Ansonsten ist das keine Raketenwissenschaft, und erfahrene Nutzer können sich die entsprechenden Dateien und Befehle natürlich problemlos aus der Veranstaltung herauspicken.) Vorsicht: da alle Kicad-Libraries installiert werden, ist das Image am Ende wenig über 6 GB groß. Genug freier Diskspace ist also zwingend notwendig! Verwendung ========== Wenn diese Voraussetzungen erfüllt sind, kann in dem entpackten Verzeichnis aus dem Zip-Archiv einfach der Befehl "make" aufgerufen werden. Funktion ======== Das Makefile erzeugt mit envsubst aus dem Dockerfile.template ein Dockerfile und ersetzt dabei die Platzhalter aus dem Template mit dem Benutzernamen und der Benutzer-ID des lokalen Benutzers. Hernach wird ein Docker-Image mit dem originellen Namen "kicad" und dem Standard-Tag "latest" gebaut -- das dauert eine Weile -- und startet dann daraus Container mit dem keineswegs weniger originellen Namen "kicad". Wenn der Container einmal erzeugt wurde, ist es ausreichend, nurmehr "docker start kicad" einzugeben. Durch die Konfiguration des Benutzers im Dockerfile (und mittels envsubst) startet das Kicad im Container mit dem Benutzernamen, der Benutzer-ID, und durch den Mountpoint /home auch im Home-Verzeichnis des Benutzers. Wer das anders haben möchte, kann es natürlich gerne anders konfigurieren. ACHTUNG: vor dem Starten des Containers gebe ich den X-Server für Zugriffe von außen frei und sperre ihn nach dem Stoppen wieder. Das sollte auf den meisten Einzelplatzsystemen kein größeres Sicherheitsrisiko darstellen, es gefällt mir aber trotzdem nicht. Leider habe ich (noch?) nicht herausgefunden, wie ich das weiter einschränken kann, und ich habe auch schon lange nichts mehr mit xauth gemacht. Wer Ideen dazu hat, ist mir immer herzlich willkommen. Viel Spaß, Glück und Erfolg! [1] Beitrag "Installation KiCAD 9 unter Linux schlägt fehl"
Angehängte Dateien:
-
kicad_docker.webp
72 KB
:
Verschoben durch Moderator
Welchen Sinn macht es eigentlich, ein simples Programm, was auf dem Systemn vermutlich ohnehin nur als Single-Instanz läuft, in einen Docker-Container einzusperren?
Warum nicht das existierende Dockerfile nehmen? https://gitlab.com/kicad/packaging/kicad-cli-docker/-/blob/main/Dockerfile.9.0-stable?ref_type=heads Dann wäre es auch die brandaktuelle Version. Jens G. schrieb: > Welchen Sinn macht es eigentlich, ein simples Programm So simpel ist es nicht, es hat sehr viele Abhängigkeiten und ist groß. Wenn man das z.B. auf einem CI-Server laufen lassen will, hat der Container Vorteile. Auf manchen CI-Systemen wie den gitlab.com -Runnern muss man es in einem Container haben
Niklas G. schrieb: > Jens G. schrieb: >> Welchen Sinn macht es eigentlich, ein simples Programm > > So simpel ist es nicht, es hat sehr viele Abhängigkeiten und ist groß. Mit simpel meinte ich nicht dessen technischen Ansprüche, sondern dessen simplen Anwendungs-Kontext. Also was macht es bei KiCad "notwendig", das in einen Container packen zu wollen?
:
Bearbeitet durch User
Jens G. schrieb: > Also was macht es bei KiCad "notwendig", das in einen Container packen > zu wollen? Es auf einem System zu installieren, auf das sich der Wust von Abhängigkeiten nicht so leicht einrichten lässt. Das ist ja sowieso der Haupt-Usecase von Containern.
Jens G. schrieb: > Welchen Sinn macht es eigentlich, ein simples Programm, was auf dem > Systemn vermutlich ohnehin nur als Single-Instanz läuft, in einen > Docker-Container einzusperren? Ein Aspekt ist die Isolation des Programms vom übrigen System. Dadurch kann die Software auf demselben System in mehreren Versionen unter verschiedenen Distributionen verwendet werden: so kann ich ein gut abgehangenes, stabiles Kikad Version 5 unter Debian 10 "Buster" neben dem aktuellen Nightly Build unter Kubuntu 24.04 LTS nutzen, und das alles auf einem Host mit, sagen wir mal, Linux Mint -- ohne daß sich dabei irgend etwas in die Quere kommt oder jemand das mit mit Skripten und LD_LIBRARY_PATH manuell hinfummeln muß. Ein anderer Punkt ist die Reproduzierbarkeit dank der Automatisierung: wenn die Kicad-Leute morgen eine neue Version releasen, wird einfach noch einmal dieses Makefile angestoßen und ein neues Image damit bauen. Dann erzeugst Du damit einen neuen Container -- und wenn der nicht richtig funktioniert, dann stellst Du einfach die vorherige Version aus dem alten Image wieder her (und schickst dem Projekt natürlich einen Bug Report). Drittens ist es für Leute, die gerne mit den Nightly Builds herum spielen, sinnvoll, die Auswirkungen möglicher Fehlfunktionen abzumildern, indem der Zugriff auf die Ressourcen des Hosts eingeschränkt wird. Und für Applikationen, die (denk zum Beispiel an Google Chrome) nach Hause telefonieren oder denen man eine spezielle Konfiguration etwa fürs Netzwerk unterjubeln möchte, ist so ein Docker-Container ebenfalls eine feine Sache.
Niklas G. schrieb: > Warum nicht das existierende Dockerfile nehmen? > > https://gitlab.com/kicad/packaging/kicad-cli-docker/-/blob/main/Dockerfile.9.0-stable?ref_type=heads Bitte Feinheiten beachten: da geht es um die CLI von Kicad, deswegen auch das "kicad-cli" in Deinem Link. So wie ich das verstanden habe, sind das nicht die Desktop-Programme von Kicad wie in meinem Image.
Ein T. schrieb: > Bitte Feinheiten beachten: da geht es um die CLI von Kicad, deswegen > auch das "kicad-cli" in Deinem Link Das ist nur der Name des Repositories, weil das der primäre Use-Case ist. IIRC enthält das Docker-Image auch die GUI. Die macht sowieso nur einen kleinen Teil des Speicherplatz-Verbrauchs aus.
Jens G. schrieb: > Also was macht es bei KiCad "notwendig", das > in einen Container packen zu wollen? Ein feiner Use-Case dafür: Wenn man sein KiCad-Projekt auf GitLab hostet, kann man darin eine Datei ".gitlab-ci.yml" anlegen mit:
1 | kicad-exports: |
2 | image: kicad/kicad:9.0.3 |
3 | script: |
4 | - mkdir Exports |
5 | - kicad-cli jobset run -f "Exports.kicad_jobset" "Projekt.kicad_pro" |
6 | artifacts: |
7 | paths: |
8 | - Exports |
Wenn das Jobset zuvor so angelegt wurde dass alles in den Unterordner "Exports" geht, werden dann die entsprechenden Exports vollautomatisch erstellt und nach GitLab als Artefakte hochgeladen. Dank des Containers muss man keinen Server aufsetzen und pflegen, sich nicht um die Installation kümmern, nichtmal ein "apt-get" Kommando angeben... Die Angabe des Container-Images namens "kicad/kicad:9.0.3" reicht. Die gesamte dafür nötige "Cloud-Infrastruktur" steckt in diesem kleinen Codeschnippsel, der Rest geht vollautomatisch.
Niklas G. schrieb: > Ein feiner Use-Case dafür: Wenn man sein KiCad-Projekt auf GitLab > hostet, kann man darin eine Datei ".gitlab-ci.yml" anlegen mit: > [...] > Wenn das Jobset zuvor so angelegt wurde dass alles in den Unterordner > "Exports" geht, werden dann die entsprechenden Exports vollautomatisch > erstellt und nach GitLab als Artefakte hochgeladen. hüstel Also das kann man zwar so machen, ist aber nicht der angedachte Anwendungsfall für CI/CD. Ich halte das eher für einen Mißbrauch. :-) > Dank des Containers muss man keinen Server aufsetzen und pflegen, sich > nicht um die Installation kümmern, nichtmal ein "apt-get" Kommando > angeben... Die Angabe des Container-Images namens "kicad/kicad:9.0.3" > reicht. Die gesamte dafür nötige "Cloud-Infrastruktur" steckt in diesem > kleinen Codeschnippsel, der Rest geht vollautomatisch. Naja, Dein Mißbrauch basiert ja im Wesentlichen darauf, daß Du bereits a) ein fertig eingerichtetes CI/CD-System und b) ein fertig gebautes Docker-Image in einer Docker-Registry hast. Ausgerechnet eine mißbräuchliche Nische mit so eng gefaßten Voraussetzungen als besonderen Vorzug oder gar als Paradebeispiel für die Vorzüge von Docker zu benennen, erscheint mir dann doch eher irreführend.
Ein T. schrieb: > hüstel Also das kann man zwar so machen, ist aber nicht der angedachte > Anwendungsfall für CI/CD. Warum nicht? Was ist denn der primäre Anwendungsfall für die GitLab hosted CI, die ausschließlich in Docker Containern arbeitet? Ein T. schrieb: > daß Du bereits a) ein fertig eingerichtetes CI/CD-System und b) ein > fertig gebautes Docker-Image in einer Docker-Registry hast. Das ist ja auch der Standardfall. Man nimmt einen fertig laufenden Cloud-Dienst ("SaaS") und lässt einen von Zigtausenden fertigen Containern drauf laufen. Nur bei Sonderwünschen muss man selbst basteln. Sogar GitLab selbst wird als Container installiert...
Beitrag #7921803 wurde von einem Moderator gelöscht.
Niklas G. schrieb: > Ein T. schrieb: >> hüstel Also das kann man zwar so machen, ist aber nicht der angedachte >> Anwendungsfall für CI/CD. > > Warum nicht? Was ist denn der primäre Anwendungsfall für die GitLab > hosted CI, die ausschließlich in Docker Containern arbeitet? "CI" ist die Abkürzung von "Continuous Integration", "CD" die von "Continuous Deployment". Da geht es um das automatisierte, kontinuierliche Bauen, Testen und Deployen von Software, um neue Versionen so schnell wie möglich in den produktiven Betrieb zu bekommen. Anders gesagt geht es darum, den klassischen Software Development Life Cycle (SDLC) mit fixen Releases zu überwinden. Eine produktive Datenverarbeitung ist dabei zwar möglich, aber nicht die Idee. So ziemlich alle mir bekannten CI/CD-Lösungen arbeiten mit Containern. Das hat einen sehr einfachen Grund, nämlich die Isolation vom Host. Wie bereits oben erwähnt, ist Isolation der ganze Grund für Container (nicht nur Docker) und deren mit Abstand wichtigster Anwendungsfall. > Sogar GitLab selbst wird als Container installiert... Genau, wegen der Isolation.
Beitrag #7921805 wurde von einem Moderator gelöscht.
Niklas G. schrieb: > Ein T. schrieb: >> Bitte Feinheiten beachten: da geht es um die CLI von Kicad, deswegen >> auch das "kicad-cli" in Deinem Link > > Das ist nur der Name des Repositories, weil das der primäre Use-Case > ist. IIRC enthält das Docker-Image auch die GUI. Die macht sowieso nur > einen kleinen Teil des Speicherplatz-Verbrauchs aus. Auf [1] lese ich: "These docker images are intended primarily for being able to use kicad-cli in CI applications", das hatte mich vermuten lassen, daß da keine GUI drin sei. Habs jetzt mal ausprobiert: hast Recht, ist drin. [1] https://hub.docker.com/r/kicad/kicad
Beitrag #7921807 wurde von einem Moderator gelöscht.
Ein T. schrieb: > Da geht es um das automatisierte, kontinuierliche Bauen, Testen und > Deployen Ja, aber das beantwortet meine Frage nicht. Das Bauen, Testen etc. lässt sich ganz wunderbar in einem Container machen, und genau das ist die Voraussetzung für CI auf GitLab.com . Und genau das macht mein Beispiel, es wird halt nur kein C++ Code in eine .exe kompiliert sondern ein KiCad-Projekt wird nach Gerber etc. exportiert. Ich sehe nicht was da wo "missbraucht" wird. Vanye R. schrieb im Beitrag #7921807: > Ich hoffe das Auto von solchen Entwicklern arbeitet mit solcher > Software. Fast alle Software heutzutage wird so entwickelt. Öfter in einer standardisierten Umgebung (der Container) bauen und testen ist der Zuverlässigkeit enorm zuträglich. Hab mal bei einem früheren Job ein CI System eingerichtet und Unittests eingeführt und prompt einen Bug in der wichtigsten Funktion der (sicherheitskritischen) Firmware gefunden.
Niklas G. schrieb: > Das Bauen, Testen etc. lässt > sich ganz wunderbar in einem Container machen, und genau das ist die > Voraussetzung für CI auf GitLab.com. Und genau das macht mein Beispiel, > es wird halt nur kein C++ Code in eine .exe kompiliert sondern ein > KiCad-Projekt wird nach Gerber etc. exportiert. Ich sehe nicht was da wo > "missbraucht" wird. Daß etwas in einem Container stattfindet, macht es aber noch nicht zu einem CI/CD-Workflow. Die Umwandlung von Dateiformaten ist Datenverarbeitung. > Vanye R. schrieb im Beitrag #7921807: >> [Unsinn] > > Fast [...] Bitte den Troll nicht füttern, Danke.
Ein T. schrieb: > Daß etwas in einem Container stattfindet, macht es aber noch nicht zu > einem CI/CD-Workflow. Nein, aber es in die .gitlab-ci.yml einzutragen schon.
Beitrag #7921878 wurde von einem Moderator gelöscht.
Ich glaube, ihr habt meine Frage im falschen Kontext verstanden. Meine Frage bezog sich auf die Sicht eines normalen KiCad-Anwenders. Dass hier (offensichtlich) KiCad-Entwickler im Forum unterwegs sind, die meine Frage aus Sicht eines KiCad-Entwicklers zu verstehen scheinen, und deswegen unbedingt das Ding in einen Container einsperren wollen, konnte man ja nicht ahnen ... Oder wollte man hier nur mal wieder zeigen, was man so drauf hat?
:
Bearbeitet durch User
Jens G. schrieb: > Meine > Frage bezog sich auf die Sicht eines normalen KiCad-Anwenders. Auch ein normale Anwender könnte Probleme haben, eine brandaktuelle KiCad-Version z.B. unter Linux zu installieren, wenn die Distribution nicht die aktuellen Version der KiCad-Abhängigkeiten mitliefert. Da könnte man sich mit Docker behelfen.
> Oder wollte man hier nur mal wieder zeigen, was man so drauf hat? Denke ich nicht. Ich halte nicht viel von Docker und den anderen Visualisierern weil sie das Problem nicht loesen sondern nur ueberdecken. BTW: Linus hat vor >10Jahren mal ein Interview gegeben wo er gesagt hat das er Linux nicht unbedingt auf dem Desktop bei jederman sieht und das genau wegen den komplexen Library Problemen! Ich selbst nutze Linux seit >30Jahren als mein Desktopbetriebssystem und kann ihm da nur zustimmen. Frueher war es normal beliebige Software vom Source zu installieren. Das konnten auch etwas begabtere Anfaenger, aber die Zeiten sind so ab den 2000ern vorbei. Die allgemein empfohlene Vorgehensweise ist eigentlich das du nur Software aus dem Repository deiner Distribution installierst. Das Problem ist nur das die sehr veraltet sein kann. Und Kicad ist ein Beispiel fuer ein Programm wo sie andauernd neue Versionen raushauen die immer mal fiese Bugs enthalten. Und dann wird man dir erzaehlen, installier doch einfach die neue Version. Das ist aber fuer Anfaenger wegen der Komplexizitaet etwas Sarkasmus. Daher kann Docker fuer dich wirklich die beste Loesung sein! Einfach weil sie dein Problem loesst. Unabhaengig davon ob mir diese Loesung gefaellt. .-) Die optimale Loesung waere eigentlich das sich jemand findet der die Maintainer der Distributionen solange in den Hintern tritt bis die alle einen identischen Satz Libraries mitliefern und halbwegs gleichzeitig auf neue Versionsstaende gehen. Und wenn dann ein Projekt meint unbedingt eine Library zu brauchen die da nicht drin ist dann muss es die in seinem Projekt mitliefern! Das wuerde dann auch das Deployment von neuer Software sehr erleichtern. Die Realitaet ist aber eher das jeder der glaubt zuviel Langeweile zu haben liebe eine neue Distribution von etwas bestehendem abzuleiten um sich selbst zu verwirklichen. Vanye
Vanye R. schrieb: > Und wenn dann ein Projekt meint unbedingt eine Library zu brauchen die > da nicht drin ist dann muss es die in seinem Projekt mitliefern Tut Kicad doch. Im Docker Container.
Niklas G. schrieb: > Tut Kicad doch. Im Docker Container. Ein Docker-Container gehört nicht zur KiCad-Software. Also nein, tut es nicht ...
Jens G. schrieb: > Ein Docker-Container gehört nicht zur KiCad-Software. Gehört ein .deb Paket oder ein .zip Archiv dazu? Oder nur das was in der ausführbaren Programmdatei /usr/bin/kicad steckt? Wie bekommt man da alle Abhängigkeiten hinein?
:
Bearbeitet durch User
Natürlich kann man alle Abhängigkeiten im Debian Package unterbringen, wenn man will oder muss. Docker kommt mir in dem Umfeld fehlplatziert vor.
Nemopuk schrieb: > Natürlich kann man alle Abhängigkeiten im Debian Package unterbringen, > wenn man will oder muss. Der Unterschied zum Docker Image ist dann aber eher marginal.
Jens G. schrieb: > Ich glaube, ihr habt meine Frage im falschen Kontext verstanden. Meine > Frage bezog sich auf die Sicht eines normalen KiCad-Anwenders. Dass hier > (offensichtlich) KiCad-Entwickler im Forum unterwegs sind, die meine > Frage aus Sicht eines KiCad-Entwicklers zu verstehen scheinen, und > deswegen unbedingt das Ding in einen Container einsperren wollen, konnte > man ja nicht ahnen ... Ich bin kein Kicad-Entwickler. Um ganz genau zu sein, bin ich nicht einmal ein Kicad-Benutzer -- meine Schaltpläne mache ich mit gschem aus der GEDA-Suite. Aber ich habe bemerkt, daß hier immer wieder Leute aufschlagen, die Probleme bei der Installation von Kicad haben. Denen wollte ich helfen und ihnen die Angelegenheit vereinfachen, mehr nicht. Stattdessen kommen nur Pöbeleien und als Frage getarnte Unterstellungen wie... > Oder wollte man hier nur mal wieder zeigen, was man so drauf hat? Ja, nee, is klaa. Die passende Gegenfrage wäre: bist Du neidisch? :-)
Vanye R. schrieb: > Denke ich nicht. Ich halte nicht viel von Docker und den anderen > Visualisierern Niemand zwingt Dich zur Teilnahme an diesem Thread, und wenn ich mich richtig erinnere, hatte der TO (ich) Dich sogar deutlich dazu aufgefordert, von einer weiteren Teilnahme abzusehen und diesen Thread nicht voll zu müllen.
Nemopuk schrieb: > Natürlich kann man alle Abhängigkeiten im Debian Package unterbringen, > wenn man will oder muss. Docker kommt mir in dem Umfeld fehlplatziert > vor. Natürlich, das kann man. Und wenn man dann noch ein paar weitere Programme in so einem Format hat, hat man am Ende drölfundzwanzig Versionen von libarsch auf der Disk -- immerhin vom Paketmanager verwaltet, das ist ja schon was. Als Nächstes kommen dann die Kollegen mit ihrem RedHat, CentOS, Fedora oder SuSE Linux und wollen RPM-Pakete. Okay, machen wir die auch noch... bis die Arch-Leute kommen und Pakete für Pacman, die Gentoo-User wollen Portage und danach die Alpine-User, die nach APKs schreien. Spätestens dann -- eigentlich schon viel früher -- stellt sich heraus, daß die ganze Paketierung signifikante Ressourcen bei den Entwicklern frißt, die darum zu wenig Zeit haben, sich um das Beheben von Fehlern, das Testen der Software, und die Entwicklern neuer Features zu kümmern. Immerhin behebt das das Problem eines besonders "klugen" Menschen in diesem Thread, daß das Projekt für seinen Geschmack zu häufig neue Softwareversionen herausgibt. Natürlich könnte man alternative Paketformate wählen. Okay, Snap ist wohl nur im Ubuntu-Umfeld verbreitet und auch dort nicht sonderlich beliebt, aber man könnte ja Flatpack- oder AppImage-Pakete schnüren. Dumm nur, daß dann wieder neuer Aufwand entsteht, die nächsten krähen "aber ich mag Flatpack | Docker | AppImage nicht" und andere sind damit überfordert, die Supportaufwand steigt, und die Leute, die Debian-, RPM-, Portage-, Pacman- und APK-Pakete fordern, sind natürlich immer noch nicht zufrieden. Yay. Aber egal: Flatpack und AppImage sind Versuche, das Abhängigkeitsproblem zu lösen. Es gibt sie schon lange, aber davon, sich durchzusetzen, sind sie bis dato noch weit entfernt. In jüngerer Zeit hat dann Ubuntu mit Snap noch eine ähnliche Lösung präsentiert, auch das stößt auf massive Widerstände. Scheint so, als seien das entweder nicht die richtigen Lösungen oder -- meine eigene Vermutung -- als sei das Problem nicht groß genug, damit sich genügend Leute dafür interessieren, so daß sich diese Lösungen durchsetzen können. Denn wir wollen die Kirche ja mal im Dorf lassen: die allermeisten Anwender sind damit zufrieden, was ihnen der Distributor anbietet. Aber es gibt noch eine andere Lösung für das Abhängigkeitsproblem, die sich breiter Akzeptanz erfreut: Docker. Da poppen dann natürlich auch wieder ein paar Spitzenhirne auf "aber ich mag Docker nicht", aber das ist deren ganz eigenes Problem. Die einzige richtige Antwort auf solche Leute ist: benutz' das einfach nicht, halt die Klappe und verschwinde. Allerdings sehen wir ja auch wieder hier im Thread, daß solche Menschen ein geradezu unstillbares Mitteilungsbedürfnis haben... ok, das sagt mehr über sie als über sonstwas. Einen anderen Weg zur Lösung der Abhängigkeitsthemen verfolgt die Sprache Go(lang), die standardmäßig einfach statische Binaries baut. Das geht leider nicht immer, und manchmal muß man die Angelegenheit ein bisschen massieren, aber im Großen und Ganzen funktioniert das erstaunlich gut. Trotzdem kann es natürlich nicht die Idee sein, alle Software jetzt nach Go zu portieren... zumal das Ziel ja war, eine Software mit möglichst geringen Aufwänden aus der Türe zu bekommen und sich ansonsten auf deren Entwicklung zu konzentrieren. Naja, wie dem auch sei: wie man es macht, macht man es flashc. Irgendwelche Klugscheißer haben immer was zu meckern und schrecken dabei auch nicht vor unfaßbar dummen Aussagen zurück. Das intellektuell Unterirdischste ist noch "da muß doch mal einer auf den Tisch hauen" in Kombination mit "Linus hat das ja schon vor Jahren gesagt": ja, genau, da hat Linux genau das mit dem "auf den Tisch hauen" ausprobiert, und was hat's geholfen? Genau: nichts, Du Nixmerker. Genauso "klug" ist die durch die Blume vorgetragene Anregung, die Entwickler sollten doch auf Libraries verzichten und am Besten alles selbst schreiben. Richtig "klug", da können wir uns auf das Jahr 4297 freuen, dann kommt die nächste Version von Kicad... aber das wird ja ohnehin zu schnell entwickelt, wer soll denn da noch hinterherkommen, bei den ganzen Releases? So funktioniert OpenSource nicht. Ihr mögt Docker nicht? Kein Problem, dann setzt Euch doch einfach auf Euren Hintern und macht was Besseres. Aber das bekommt Ihr offenbar nicht hin. So funktioniert OpenSource nicht. Ihr mögt Docker nicht? Kein Problem, dann setzt Euch doch einfach auf Euren Arsch und macht was Besseres. OpenSource lebt vom Mitmachen! (Louis De Funes: ah, c'est vrai? Zut alors! Dabei ein Chor im Hintergrund: oooohhhhhh!) Fakt ist: Docker funktioniert. Effizient, einfach (zumindest für die User), stabil und zuverlässig. Docker löst Probleme. Gemoser nicht.
Jens G. schrieb: > Niklas G. schrieb: >> Tut Kicad doch. Im Docker Container. > > Ein Docker-Container gehört nicht zur KiCad-Software. Also nein, tut es > nicht ... Doch, das Kicad-Projekt veröffentlicht ein eigenes Docker-Image: [1]. Die Paketierung ist inhärenter Bestandteil einer Softwareentwicklung. [1] https://hub.docker.com/r/kicad/kicad
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.