habe vor Kurzem KiCAD instaliert, habe angefangen damit zu arbeiten. Zwei Tage später gab es plötzlich paar Dutzend neue Updates in meiner Aktualisierungsverwaltung (Linux). Habe natürlich ausgeführt, mein Monitor hat sich fünf mal aus- und angeschaltet (je ca. 1 Sekunde aus), wärend des ganzen. Dannach war KiCAD weg, so etwas hatte ich noch nie, als hätte das System sich auf Zustand von vor einer Woche zurück gesetzt (gespeicherte Dateien sind erhalten).
Fragen:
Ist KiCAD auf Lunux fehleranfällig? (Jemand Erfahrung?)
Wenn man mit KiCAD arbeitet, ist das möglich dass der Hersteller jeder Zeit remote auf Projekte der Nutzer Einsicht hat?
Bestimmte Bauteilkombinationen problematisch?
/ Hersteller wird benachrichtigt
/ Das System friert ein (ein mal passiert)
An sich habe ich kaum etwas gemacht, nur paar aktuelle Projekte versucht auf KiCAD zu übertragen. Und ich kann mich an ähnliche spooky 3D-Drucker Sachen erinnern, am Ende hatte ich einen kaputten Drucker.
Ich weiß das klingt alles zu weit hergeholt aber ich bin ein wenig angefressen. Hat jemand auf seinem PC etwas ähnliches gehabt?
Sie können entfernte Pakete auch auflisten, indem Sie Protokolle lesen, indem Sie „install“ durch „remove“ ersetzen, wie in der Abbildung unten gezeigt.
Fragen 2 und 3: Nein! Wie kommst du auf sowas? WaffG §52?
Evtl. ist ja dein ganzes System korrumpiert. Keine Angst,
wenn "sie" dich ernst nehmen würden, hätten "sie" das unauffälliger gemacht.
zu 1.: Kicad läuft unter Linux normalerweise stabil.
Deine Deinstallation hat aber nichts mit "laufen" zu tun. Und das Programm kann sich nicht selbst deinstallieren, dafür hat es nicht die nötigen Zugriffsrechte (es sei denn du führst es als root User aus, was sehr seltsam wäre). Für die Deinstallation sind apt und dpkg zuständig.
So unerklärliche Fehler hatte ich, als ich vor über ’nem Vierteljahrhundert mit Linux angefangen hatte: Da sind ab und zu mal Dateien verschwunden oder kaputtgegangen, installierte Sachen nicht mehr auffindbar gewesen und so. Mussten Fehler im System sein, denn ich war mir keiner Schuld bewusst. Interessanterweise wurde das in dem Maß weniger, in dem ich mit dem System umzugehen lernte – entsprechend ist das auch hier mein Rat: Lerne die Basics.
Natürlich kann sowas dann immer noch passieren, aber einerseits ist die Wahrscheinlichkeit deutlich geringer, und wenn es tatsächlich passieren sollte, dass bei einem Update ein Programm deinstalliert wird, dann ist die Ursache deutlich einfacher und schneller zu finden: In der Regel steht sie nämlich schon in der Ausgabe des Paketmanagers bzw. des genutzten Frontends. Außerdem ist man dann in der Lage, einen Eingangsbeitrag mit dem Mindestmaß an benötigten Informationen zu verfassen …
That said: Wie war es installiert? Soweit ich in Erfahrung bringen konnte, gibt es bei Mint regulär Flatpak neben dem traditionellen Paketmanagement auf Basis von apt. Und: Was heißt „weg“ an dieser Stelle genau? Ist das Programm tatsächlich komplett deinstalliert worden, oder kann es sein, dass dir lediglich der Eintrag in deinem Anwendungsmenü/Launcher/wasauchimmerdunutzt fehlt? Was passiert, wenn du in einer Shell einfach mal kicad eingibst und Enter drückst?
Ist KiCAD auf Lunux fehleranfällig? (Jemand Erfahrung?)
Das ist kein Problem von Linux sondern eher von Kicad. Meine Erfahrung war auch das es immer irgendwelche Bugs gibt. Kuckst du dann nach, erfaehrst du das deine Version schon 3Monate alt ist, damit bereits krass veraltet und du unbedingt aktualisieren sollst. Dann ist das Problem behoben, dafuer hast du dann irgend welche neuen Bugs.
Zwischendurch, wie ein guter Jahrgang bei Wein, gibt es dann mal was brauchbares. Man ist geneigt dabei zu bleiben, aber dann gibt es ploetzlich einen anderen Grund wieso du updaten musst. Z.b weil die Libaries deines Systems auf Links gedreht wurden und dann springst du erneut in die Hoelle.
Problem dabei das an diesen fetten Programmen immer viele Leute irgendwie in ihrer Freizeit arbeiten. Das ist keine Firma wo es einen Projektleiter mit Peitsche gibt. Das hat leider auch Nachteile. (Wobei mir die Vorteile durchaus bewusst sind)
Ein weiteres Problem ist dann leider Linux spezifisch. Du bist irgendwann auf dem Level wo du den Source selber uebersetzen musst wenn du uptodate bleiben willst. Das wird aber problematisch wenn du eine andere Distribution nimmst wie die Entwickler deines Programms (z.B Kicad). Ich benutze z.B Alma10.2. Man sagt dir dann gerne, aber du musst doch Schrumbeldub23 (oder was gerade bei Kiddys cool ist) nutzen. Ist aber keine Hilfe weil du noch fuenf andere dicke Projekte nutzt die dann wiederum jeweils ihre eigene Lieblingsfrontdistribution haben wollen weil das im Kindergarten gerade angesagt war.
Weil den Programmierern selber schon aufgefallen ist das dies kacke ist haben sie Container erfunden. Aber natuerlich nicht einen! Nein nein, warum ein Standard wenn es viele geben kann. Also flatpack, snap, docker (nochwas?) Oder appimages.
Das sorgt dann ganz nebenbei dafuer das Programme die vorher in 0.1s gestartet sind in 3-5s starten. (z.B bei gimp)
Deshalb bin ich bei Eagle 5.6 geblieben, dass bei mir native als 32Bit direkt in Alma10.2 laeuft. Alles geht wie immer, alles ist maximal krass schnell.
Ich bin Linuxuser seit Anfang der 90er (0.95er Kernel, noch vor SLS) und damit meine ich als Hauptbetriebsystem! Kein DOS, Winbloed, OS2, WinXP, Win10,11,12 nebenbei! Aber ich muss leider sagen die immer groesser werdende Diversifikation der Distributionen und ihre Treiber und Versionshoelle macht es immer schwieriger sowas ernsthaft zu nutzen.
LEIDER!
Linux ist in fast allen belangen VIEL besser wie alles was Microsoft jemals geschaffen hat, vielleicht mit Ausnahme ihrer Maus, aber dieser eine Mangel ist fuer viele Menschen die nicht auf Gurulevel sind sehr abtoernend. Das ist uebrigens nicht nur meine Meinung, Linus hat dies selber vor ein paar Jahren mal in einem Interview gesagt.
Zwischendurch, wie ein guter Jahrgang bei Wein, gibt es dann mal was
brauchbares. Man ist geneigt dabei zu bleiben, aber dann gibt es
ploetzlich einen anderen Grund wieso du updaten musst. Z.b weil die
Libaries deines Systems auf Links gedreht wurden und dann springst du
erneut in die Hoelle.
Deswegen benutze ich ganz bewusst nicht die gerade neueste Version, sondern das stable Release von Debian mit den darin enthalten Programmen. Diese sind erfahrungsgemäß "gut abgehangen", also stabil.
Nur ganz ganz selten installiere ich mal an der Distribution vorbei eine neuere Version von einem Programm. Und das auch nur dann, wenn ich einen wirklich guten Grund dazu habe. "Sieht schöner aus" wäre kein Grund.
sondern das stable Release von Debian mit den darin enthalten Programmen.
Kannst du machen und kann auch eine kluge Strategie sein, aber wenn man Linux als Hauptsystem nutzt und nicht als Spielzeug nebenbei, dann hat man noch so 50andere Programme neben Kicad die man auch noch benutzen will und wovon dann vielleicht ein paar nicht fuer Debian verfuegbar sind. (und umgekehrt bei anderen Systemen)
Wie schon gesagt, die starke Diversifikation ist das Problem, nicht ein einzelnes Programm wie Kicad.
Ausserdem, irgendwann schlaegst du dann hier im Forum, oder anderswo auf, mit der Frage, ich moechte XYZ in Kicad nutzen wie geht das? Und dann sagt man dir; Du hast noch Kikad n.n, du musst unbedingt n+x installieren weil da ist alles besser!
Vanye
p.s: Hab am Wochenende Qt mit Unterstuetzung fuer Android erfolgreich installiert, ich weiss wie heiss die Hoelle gerade ist. :-D
vielleicht ein paar nicht fuer Debian verfuegbar sind.
Klar, die installiert man natürlich zwangsläufig an Debian vorbei. Und ja, das klappt auch bei mir nicht immer reibungslos. Egal ob im snap, flatpak, deb oder zip Format. Perfekt ist nichts davon.
Deswegen bin ich den Leuten die so eine Distribution zusammen Stellen und pflegen sehr dankbar. Wegen ihnen habe ich die Gewissheit, dass alles was in Debian "drin" ist auch zusammen passt.
Hab am Wochenende Qt mit Unterstuetzung fuer Android erfolgreich installiert
Das klappt ausnahmsweise mit dem Download von der Qt Homepage besser, als mit den Debian Paketen.
sondern das stable Release von Debian mit den darin enthalten
Programmen. Diese sind erfahrungsgemäß "gut abgehangen", also stabil.
Je nun. Für einen produktiven Server ist das sicherlich eine gute Strategie, für einen Desktop mit genutzten Anwendungen ist „gut abgehangen“ doch komplett sinnlos.
für einen Desktop mit genutzten Anwendungen ist „gut abgehangen“ doch
komplett sinnlos.
Mir sind zuverlässige Programme ohne Überraschungen wichtiger. Ich brauche zum Arbeiten nicht die neuesten Programmversionen. Es ist schon nervig genug, dass ich jede Woche mit dem Upgrade von Bibliotheken in meinen Produkten* beschäftigt bin - ist dort allerdings aus Sicherheitsgründen sehr viel notwendiger, als auf meinem Desktop.
Mir sind zuverlässige Programme ohne Überraschungen wichtiger.
Ich brauche zum Arbeiten nicht die neuesten Programmversionen.
Da bin ich zu 101% bei dir. Aber da schliesst sich natuerlich gerade im Zusammenhang mit Kicad wieder der Kreis, wie ich oben ja schon beschrieben habe.
Und wenn du jetzt nicht nur mit Linux spielst sondern es dein Hauptsystem ist, dann hast du viele solcher Problemzonen. Ich hab z.B lange eine aeltere Version von Darktable genutzt, aber dann konnte die nicht mehr das RAW Format einer neu gekauften Kamera verstehen, also updaten. Das ging aber nicht ohne xyz abzudaten, das hat dann aber abc gestoert. Weil es da keinen einheitlichen Standard gibt hechelt man als Nutzer immer hinterher und deshalb gibt nur sehr wenig Leute die Linux als Hauptsystem einsetzen.
darktable: völlig separat im /opt Verzeichnis luminance-hdr: völlig separat im /opt Verzeichnis rawtherapee: völlig separat im /opt Verzeichnis
samt Versionshysterie ;-) und zusätzlich auch noch einige andere Applikationen.
Note an self: Gelegentlich mal aufräumen.
Jedenfalls wird Debian Stable auf diese Art und Weise auch weiterhin seinem Namen gerecht, ist und bleibt zuverlässig wie ein alter Weggefährte.
sondern das stable Release von Debian mit den darin enthalten
Programmen. Diese sind erfahrungsgemäß "gut abgehangen", also stabil.
Je nun. Für einen produktiven Server ist das sicherlich eine gute
Strategie, für einen Desktop mit genutzten Anwendungen ist „gut
abgehangen“ doch komplett sinnlos.
Oliver
Neben Debian stable gibt es auch noch debian testing (und debian unstable). Ich nutze auch auf dem Desktop Debian stable. Bei Debian kann man in drei Stufen zwischen "gut abgehangen" und "frisch geschlachtet" wählen. :-)
Nur bedeutet älter halt bei Anwendungen meistens einfach nur veraltet
Wenn ich ein Programm nutze, und die aktuellste Version mir keinen Vorteil bietet, die von mir genutzte ältere Version dennoch die aktuellen Sicherheitspatches bekommt – wo genau liegt dann das Problem mit der älteren Anwendungsversion?
Vorteile wären jedenfalls beispielhaft: Ich muss mich nur alle paar Jahre mal umgewöhnen, Dateiformate ändern sich nicht zwischendurch, ich muss die Config nicht regelmäßig geradeziehen, Doku und ein reichhaltiger Fundus an Problemlösungen, Tipps und Tricks stehen zur Verfügung, etc.
Ich selbst nutze eine „rollende“ Distribution, btw. – ich hab daher immer den neusten Scheiß. Wenn da Probleme auftreten, kann ich die allerdings auch fix lösen – aber „nur Anwender“? Für die ist Konsistenz meist wichtiger, als das neuste Feature, das man dann doch häufig nur mal probiert und dann kaum wieder braucht.
Aber mancher steckt halt lieber in der Steinzeit fest.
Damals hatten Menschen noch mehr Hirn.
Fossile Funde zeigen, dass das durchschnittliche Volumen des menschlichen Gehirns in den letzten 10.000 bis 20.000 Jahren um etwa zehn Prozent geschrumpft ist – von rund 1.500 auf etwa 1.350 Kubikzentimeter.
Sehr oft bedeutet es: Kann alles was ich will, macht alles was ich brauche. Danke!
Das denken sogar die meisten Kunden. Das ist naemlich der Grund wieso die ganzen Softwarefirmen so heiss darauf sind den Kunden nichts mehr zu verkaufen sondern zu vermieten. (vgl: Eagle!) Die wollen dauerhafte Opfer und keine Kunden die zufrieden sind und dann 10Jahre nichts mehr kaufen. Wo kommen wir denn hin wenn Programmierer fertige Produkte verkaufen wie in allen anderen Berufszweigen? Das geht doch nicht!
Es gibt natuerlich Ausnahmen, eine habe ich oben im Zusammenhang mit Darktable erwaehnt.
Wer neue Funktionalitaet will muss dafuer selbstverstaendlich bezahlen. Bei Microsoft mit Geld, bei Linux mit Schweiss.
Aber gerade bei einem Programm um Platinen herzustellen ist das in der Regel, zumindest im Privatbereich, eher nicht so. Wenn man darueber nachdenkt eigentlich erstaunlich. Wie kann es sein das wir immer noch Gerber von Annoschlagmichtod verwenden. Da haette doch laengst einer den neuesten heissen scheiss in XML implementieren muessen. Hat wohl noch keiner geschafft. Ist aehnlich wie STEP bei den Mechanikern. SOOOOO gerne wuerde jede Firma da ihr eigenes Format durchdruecken, aber keiner traut sich. :-D
Damals hatten Menschen noch mehr Hirn.
Fossile Funde zeigen, dass das durchschnittliche Volumen des
menschlichen Gehirns in den letzten 10.000 bis 20.000 Jahren um etwa
zehn Prozent geschrumpft ist – von rund 1.500 auf etwa 1.350
Kubikzentimeter.
Erst irgendeinen Exotenkrams benutzen und sich dann über mangelnde Kompatibilität beschweren, janeeisklaar.
Man sagt dir dann gerne, aber du musst
doch Schrumbeldub23 (oder was gerade bei Kiddys cool ist) nutzen. Ist
aber keine Hilfe weil du noch fuenf andere dicke Projekte nutzt die dann
wiederum jeweils ihre eigene Lieblingsfrontdistribution haben wollen
weil das im Kindergarten gerade angesagt war.
Die allermeisten Linux-Pakete laufen auf allen verbreiteten Distributionen, entweder weil sie sich dort bereits in den Paketrepositories befinden, oder weil deren Entwickler selbst entsprechende Pakete bereitstellen. Wenn Du eine Exotendistribution benutzt oder ständig den allerneuesten Scheiß haben mußt, dann bist Du selbst das Kiddy. Niemand sonst.
Das ist naemlich der Grund wieso die ganzen Softwarefirmen so heiss
darauf sind den Kunden nichts mehr zu verkaufen sondern zu vermieten.
(vgl: Eagle!) Die wollen dauerhafte Opfer und keine Kunden die zufrieden
sind und dann 10Jahre nichts mehr kaufen.
Die exorbitant triviale und weit verbreitete Lösung ist der Wartungsvertrag.
Die SW Firma verkauft mir die SW und wir machen einen Wartungsvertrag für den ich regelmässig bezahle, dafür Updates & Support bekomme.
Damit bin ich auf der sicheren Seite, selbst wenn der Laden das Produkt einstellt oder pleite geht. Und der Laden kriegt regelmäßig Geld.
Habe ich hier privat für mehrere Programme und klappt prima.
Firmen die sowas nicht anbieten sind dann im Ordner "Ex-Lieferanten" und durch Andere ersetzt. Auch das klappt prima^^
Erst irgendeinen Exotenkrams benutzen und sich dann über mangelnde
Kompatibilität beschweren, janeeisklaar.
Du weisst nicht was das ist oder?
Doch, natürlich, das ist ein neuer Abklatsch von RHEL, ähnlich wie Rocky Linux. Die sind entstanden, nachdem RedHat ihren Vorgänger CentOS aus Gier eingedampft hatte. Irgendwie muß IBM ja die 34 Mrd. US-Dollar zurückbekommen, die RedHat gekostet hat.
Dann ist ja gut, man koennte jetzt fragen wieso du der Meinung bis das RHEL Exotenkram ist. Aber der entscheidende Punkt ist etwas anderes. Ich hab doch oben ausgefuehrt das es ein Problem von Linux ist das es soviele unterschiedliche Distributionen gibt. Und das es fuer jemanden der Kicad unter Linux nutzt auch ein Problem sein wird das man ihm dann sagt, wieso benutzt du ABC, du musst doch DEF nutzen! Oder anders gesagt, jemand wie du ist ein Teil des Problems!
Ich habe gute Gruende fuer Alma, die stehen hier nicht zur Diskussion, es kann nicht Teil der Problemloesung sein jemanden seine Distribution vorzuwerfen. Die Probleme liegen woanders und sollten auch da geloest werden!
Dann ist ja gut, man koennte jetzt fragen wieso du der Meinung bis das
RHEL Exotenkram ist.
Nicht RedHat, sondern Alma. Das ist zwar ABI-kompatibel, aber eben nicht RHEL.
Erschwerend kommt hinzu, daß ich in der OSS-Community mittlerweile viele Stimmen höre, die ihre Unterstützung für RHEL zunehmend oft und zunehmend laut in Frage stellen. Besonders, seitdem RedHat den Zugang zu seinen Paketquellen auf zahlende Benutzer beschränkt hat. Da fragen sich Leute in den Projekten, warum sie Zeit und Aufwand in die Unterstützung einer Distribution investieren sollten, die ihre Software dann teuer verkauft, während sie den Entwicklern den Zugang dazu einschränken, und die sich in der Vergangenheit oft in einer Weise betätigt hat, die viele als spalterisch und unfreundlich empfunden haben. Etwa mit dem GCC 2.96, Gnome, GlusterFS, Podman, Mono und JBoss, um nur einige der prominentesten Beispiele zu nennen. Oder beim früheren RedHat Linux (ohne Enterprise), CentOS, ... wenn Du länger in der Linuxwelt unterwegs bist, fallen Dir sicher weitere Beispiele ein.
Insofern sehe ich viele Projekte, die RedHat und sein RHEL immer weniger und oft nurmehr etwas stiefmütterlich unterstützen. In den USA ist RedHat immer noch sehr stark, aber in anderen Teilen der Welt und der Community sehe ich RedHats Einfluß schwinden, mal mehr, mal weniger schnell, aber dafür jedenfalls sehr nachhaltig. Deswegen könnte RHEL künftig zumindest außerhalb der USA zunehmend zum Exoten werden.
Aber der entscheidende Punkt ist etwas anderes. Ich
hab doch oben ausgefuehrt das es ein Problem von Linux ist das es
soviele unterschiedliche Distributionen gibt.
Das ist nur dann ein Problem, wenn Unerfahrene an solche Exoten geraten. Es gibt sie ja, die einsteigerfreundlichen, weit verbreiteten, hervorragend dokumentierten und von einer großen, starken Community unterstützten Distributionen, wie [KXL]Ubuntu, Linux Mint, und natürlich Debian. Wer damit zurecht kommt, hat dann auch die Erfahrung und die Kenntnisse, um a) eine qualifizierte Entscheidung für einen Exoten zu treffen, und dann b) auch damit vernünftig zurande zu kommen. Eigentlich simpel, man setzt ja auch keine Fahranfänger in Formel1-Renner oder in Doppelstöcker zur Hauptverkehrszeit am Picadilly Circus.
Und das es fuer jemanden
der Kicad unter Linux nutzt auch ein Problem sein wird das man ihm dann
sagt, wieso benutzt du ABC, du musst doch DEF nutzen! Oder anders
gesagt, jemand wie du ist ein Teil des Problems!
Nein, bin ich nicht, im Gegenteil: ich empfehle eine weit verbreitete, gut dokumentierte und von der Entwickler- und Usercommunity gut unterstützte Distribution, egal ob Ubuntu, Debian oder Mint. Damit kommen Einsteiger meistens prima zurecht und finden allenthalben Unterstützung, wenn etwas nicht wie erwartet funktioniert.
An dieser Stelle muß allerdings leider auch erwähnt werden, daß die RPM-basierten hier mittlerweile etwas abgehängt sind, was sicherlich von den Entscheidungen von Novell und RedHat beeinflußt ist, ihre Distributionen zu kommerzialisieren. Das ist schade, gerade weil insbesondere SuSE Linux einmal einen großen Marktanteil im deutschsprachigen Raum innehatte, und für viele heutige Linux-Nutzer der Einstieg in die Linux-Welt war. Aber Linux-Nutzer und -Entwickler sind nunmal ein sensibles Völkchen und reagieren auf solche Versuche der Vereinnahmung mit starker Ablehnung -- und eine andere Distribution ist ja immer nur ein paar Mausklicks weit entfernt.
Ich habe gute Gruende fuer Alma, die stehen hier nicht zur Diskussion,
es kann nicht Teil der Problemloesung sein jemanden seine Distribution
vorzuwerfen. Die Probleme liegen woanders und sollten auch da geloest
werden!
Meine Kritik hat allerdings nichts mit Deiner Entscheidung für Alma Linux zu tun, da bin ich vollkommen leidenschaftslos. Ich habe nichts gegen Alma (oder ein anderes) Linux und gehe davon aus, daß Du Deine Gründe für Deine Wahl hast.
Meine Kritik ist, daß Du Deine Kompatibilitätsprobleme mit einer Exotendistribution als typisch darstellst. Dabei beißt sich Deine Argumentation, die Vielfalt von Distributionen stelle ein Problem dar, auch noch in den eigenen Schwanz. Denn die ganze Existenz Deines Alma Linux ist Ergebnis einer Spaltung, die von ausgerechnet jenem Distributor initiiert worden ist, den Du mit Deiner Wahl von Alma indirekt selbst unterstützt.
Du könntest Dir stattdessen einfach eine RHEL-Subskription kaufen, wenn es wirklich ernst meinen würdest und dann auch noch konsequent wärst. Aber (verständlicherweise) sparst Du Dir das KLeingeld lieber und nimmst Deine Kompatibilitätsprobleme dadurch aber natürlich sehenden Auges selbst in Kauf.
Nebenbei bemerkt schreiben wir heute das Jahr 2026, und das heißt: es gibt sehr viele Möglichkeiten, solche Kompatibilitätsprobleme zu lösen. Klar, Flatpack und AppImages, meinetwegen auch noch Snap, aber natürlich auch Docker. Das ist zwar mittlerweile sehr bekannt und weit verbreitet im Betrieb von Serversoftware. Etwas weniger bekannt dürfte jedoch sein, daß man auch GUI-Software in Docker betreiben kann. Und zwar gänzlich ohne Krücken wie VNC oder Ähnliche: einfach die entsprechenden Devicefiles in den Container mounten, läuft. Und zwar sauber isoliert, bei Bedarf mit eingeschränkten Ressourcen und ausgefuchsten AppArmor-, Seccomp- und SELinux-Sicherheitsprofilen, mit einer flexiblen Netzwerk- und Storagekonfiguration, und mit jeder binärkompatiblen Distribution Deiner Wahl, ohne spürbare Einbußen bei Funktionalität, Performance, oder Bedienbarkeit. Klar, nichts für Anfänger. Aber für Fortgeschrittene ist das eine prima Sache. :-)
Nebenbei bemerkt schreiben wir heute das Jahr 2026, und das heißt:
es gibt sehr viele Möglichkeiten, solche Kompatibilitätsprobleme zu lösen.
Einer der Gruende fuer Alma, abgesehen davon das ich von Centos komme, war das ich so 32Bit nachinstallieren konnte. Welches Distribution kann das sonst noch? .-)
Klar, nichts für Anfänger. Aber für Fortgeschrittene ist das eine prima Sache. :-)
Hat REdhat/Alma fuer Flatpack auch alles. Oh..und fuer Wine jetzt auch. Ich glaube allerdings ich hab laenger gebraucht um LT-Spice mit Bottles ans laufen zu bekommen wie frueher mit der Kommandozeile. Garnicht davon zu reden das ich mich immer frage was die Programmierer heute so Rauchen bevor sie sich ein Namen fuer ihre Schoepfung ausdenken.
Das Problem ist nur du stehst dann halt ziemlich bloed davor wenn etwas nicht geht. Ich hab z.B ein Creality K1, Die Software von Creality ist ein Appimage. Die neueren Versionen laufen nicht weil die darin Treiber vergessen haben. Die aelteren funktionieren aber. Erstaunlich oder? DA finde ich es schon besser wenn ich einfach selber Hand anlegen kann.
Die Kritik an Redhat kann ich durchaus mitgehen. Um so wichtiger das jemand die Muehe auf sich nimmt und es nach compiliert und das Bootlogo austauscht!
Einer der Gruende fuer Alma, abgesehen davon das ich von Centos komme,
war das ich so 32Bit nachinstallieren konnte. Welches Distribution kann
das sonst noch? .-)
Einer der Gruende fuer Alma, abgesehen davon das ich von Centos komme,
war das ich so 32Bit nachinstallieren konnte. Welches Distribution kann
das sonst noch? .-)
Ich vermute, dass das 32/64 auf einem Missverständnis beruht.
Debian 12 (Bookworm) ist das letzte auf einem reinen 32Bit System installierbare OS.
Debian 13 (Trixie) verlangt eine amd64 Architektur.
Aber … auch bei Debian 13 kann/könnte man später mittels dpkg --add-architecture i386 Komponenten hinzufügen.
Wenn man's allerdings - wie in meinem Falle - nur für LTspice bräuchte, ist so etwas nicht nötig.
Die 64Bit Komponenten laufen nachweislich völlig ohne i386 Architektur. Bis auf den Win-Installer, der ist noch ein Überbleibsel aus der (ur-ur)alten Windows-Welt.
Ich hatte das Problem so ähnlich auch mal gehabt auf XUbuntu. Sogar mit kicad.
Ich schloss meinem apt upgrade entweder ein autoremove an, oder es hatte selber einige Pakete mitentfernt. Genau weiß ich das nicht mehr. Jedenfalls war dann auch kicad weg.
Nebenbei bemerkt schreiben wir heute das Jahr 2026, und das heißt:
es gibt sehr viele Möglichkeiten, solche Kompatibilitätsprobleme zu lösen.
Einer der Gruende fuer Alma, abgesehen davon das ich von Centos komme,
war das ich so 32Bit nachinstallieren konnte. Welches Distribution kann
das sonst noch? .-)
Nach dem Einschalten der gewünschten Architektur ("dpkg --add-architecture i386") klappt das unter Debian, Kubuntu und zweifellos auch unter Linux Mint wunderbar. Für Docker gibt es sogar ein i386-Image von Debian [1], letztes Update vor 14 Tagen. Das läuft problemlos auf meinem Kubuntu 26.04 LTS -- und ich habe keine Zweifel, daß das auch auf einem Debian und einem Linux Mint genauso problemlos funktionieren wird. Weitere Informationen für die Nutzung von 32Bit-Paketen findest Du in Debians Multiarch-HOWTO: [2].
Das Problem ist nur du stehst dann halt ziemlich bloed davor wenn etwas
nicht geht. Ich hab z.B ein Creality K1, Die Software von Creality ist
ein Appimage. Die neueren Versionen laufen nicht weil die darin Treiber
vergessen haben. Die aelteren funktionieren aber. Erstaunlich oder? DA
finde ich es schon besser wenn ich einfach selber Hand anlegen kann.
Mir ist nicht ganz klar, inwieweit die Auswahl einer bestimmten Distribution einen Einfluß darauf hat, ob die Appimages von Creality vollständig sind.
Außerdem kannst Du natürlich jederzeit und mit jeder beliebigen Distribution Hand anlegen. Denn genau wie andere Paket- und Imageformate lassen sich auch Appimages entpacken, unter jeder beliebigen Linux-Distribution. Ebenso lassen sich Pakete und Images neu packen, mit -- Du ahnst es -- jeder beliebigen Linux-Distribution. Man kann sie sogar in ein anderes Format verpacken, also beispielsweise aus einem Appimage ein Docker-Image erzeugen, sowas könnte für Deinen Anwendungsfall sogar die eleganteste Lösung sein.
Im Endeffekt ist die Auswahl einer bestimmten Linux-Distribution keine Frage technischer Bedürfnisse oder Notwendigkeiten, sondern nur eine Frage des persönlichen Geschmacks. Die Unterschiede zwischen den Distributionen sind minimal, und, mal ehrlich: wenn jemand die Transferleistung, daß das Apachepaket unter Debianen "apache2" heißt und in RPM-basierten "httpd", ist er mit einem Linux wahrscheinlich ohnehin nicht gut bedient.
Der Vorzug der verbreiteten Distributionen ist nicht, daß sie etwas besser können als die Exoten. Ihr Vorteil ist, daß es eine große Community gibt und die Wahrscheinlichkeit viel größer ist, Unterstützung und Hilfe zu finden. Im Umkehrschluß bedeutet das auch, daß die Wahrscheinlichkeit, Hilfe und Unterstützung für Exoten zu erhalten, geringer ist, und das dem Anwender dann meist abverlangt, sich selbst zu helfen -- und das auch zu können.
Ich hab weder mit Linux Mint noch mit KiCAD darauf ein Problem.
Und bei Beiden installiere ich sehr naiv Updates. Bei KiCAD überspring ich aber gerne mal die ersten 1 ... 2 Versionen bei größeren Neuerungen. Wirklich auf die Schnauze gefallen bin ich aber noch nie.
Ich hatte das Problem so ähnlich auch mal gehabt auf XUbuntu. Sogar mit
kicad.
Das konnte passieren, wenn man andere Repositories installierte, die z.B. eigene Versionen der occt-libs (https://de.wikipedia.org/wiki/Open_CASCADE_Technology) mitbrachten. Bei mir hatten sich mal die occt-dev-libs von ubuntu 22.04, die für Horizon gebraucht
wurden, mit denen vom kicad Repository gezwickt. Wollte man Horizon compilieren und die occt-dev-libs installieren, wurde kicad deinstalliert. Ist aber schon etwas her.
Fragen 2 und 3: Nein! Wie kommst du auf sowas? WaffG §52?
Evtl. ist ja dein ganzes System korrumpiert. Keine Angst,
wenn "sie" dich ernst nehmen würden, hätten "sie" das unauffälliger
gemacht.
Was, WaffG §52?? langsam glaube ich dass du für KiCAD arbeitest ;D
Weist du, vor zehn, fünfzehn Jahren hätte ich noch geglaubt dass meine Daten bei meinem Provider sicher sind, heute bin ich mir sicher dass jeder Pfosten dort auf so einige Daten Zugriff hat (welche Seiten ich besucht habe usw., welche Endgeräte ich benutze usw.). Damals hätte ich auch nie gedacht dass SIM Karten geklont werden können, dass es Ortungsgeräte gibt die ganz einfach an dein Auto geklemmt werden können und dass jeder Affe mit etwas Grips und einem Budget von 10€ dich tracken kann. Alles problematisch und strafbar!... Alles wird trotzdem gemacht.
Ok, ich denke dass sie remote Überwachung ginge zu weit, schließlich lädt sich jeder die selbe Software herunter. Aber das ist doch denkbar dass KiCAD zumindest bestimmte Aktivitäten meldet. Normale User wie ich haben keine Ressourcen oder wissen um dahinter zu kommen. Versuche jemanden zu finden der IT-Forensik betreibt und was wenn es sich herausstellt dass KiCAD doch hier und da spioniert? Dass wird doch keinen großartig interessieren.
Ich vermute allerdings, dass KiCAD kein sonderlich großes Interesse daran hat, ob du eine Durchkontaktierung am linken Rand direkt neben der Steckleiste vorgesehen hast.
Und selbst wenn du einen Widerstand aus Versehen Wiederstand genannt hast, wird das (vermutlich) keinen Einsatz eines Spezialkommandos nach sich ziehen.
Weist du, vor zehn, fünfzehn Jahren hätte ich noch geglaubt dass meine
Daten bei meinem Provider sicher sind, heute bin ich mir sicher dass
jeder Pfosten dort auf so einige Daten Zugriff hat (welche Seiten ich
besucht habe usw., welche Endgeräte ich benutze usw.).
Die meisten Daten werden heute mit Komfort gehandelt. Du willst Dienst XY benutzen? Aber gerne, wenn Du uns dafür Deine Daten gibst. Provider sind da nicht der richtige Ansatz, die sehen heute eh nur noch Verschlüsseltes.
Damals hätte ich
auch nie gedacht dass SIM Karten geklont werden können, dass es
Ortungsgeräte gibt die ganz einfach an dein Auto geklemmt werden können
und dass jeder Affe mit etwas Grips und einem Budget von 10€ dich
tracken kann.
Also von maximaler Naivität zu maximaler Paranoia... :-)
Aber das ist doch denkbar
dass KiCAD zumindest bestimmte Aktivitäten meldet.
Nein, sicher nicht. Der Code von Kicad ist offen und wird von vielen Leuten entwickelt, und der Tod der Verschwörung sind ihre Mitwisser. Anders gesagt müßte sich dort eine Vielzahl von Mitwissern zusammengetan haben, um die Daten ihrer Nutzer zu klauen, und von diesen Mitwissern müßten dann auch noch alle über Jahre hinweg geschwiegen haben. Für wie wahrscheinlich hälst Du das?
Und für wie wahrscheinlich hälst Du es, daß noch nie jemand in den Quellcode von Kicad geschaut und dort eine Spionagefunktion entdeckt hätte, wenn eine drin wäre? Daß noch nie jemand in sein Netzwerk geschaut und dort verdächtigen Datenverkehr bemerkt hätte, wenn Kicad spionieren würde? Nichtmal beim CERN, das Kicad nutzt und zur Entwicklung beiträgt?
Und dann, mal unter uns: was sollten die Spione dann mit Deinen Daten machen? Da reden wir ja nicht nur über Deine Daten, sondern über Daten von etlichen hunderttausenden Benutzern. Um solche Mengen zu analysieren braucht es enorme Speicherkapazität und Rechenleistung, die kleine OpenSource-Projekte sicher nicht haben -- schon gar nicht, um herauszufinden, wie Du Deine Bauelemente anordnest.
dass jeder Pfosten dort auf so einige Daten Zugriff hat
Auch wenn, was können die damit anfangen, außer ein auf Dich zugeschnittenes Werbepaket zu schnüren? Von Google und Microsoft ist seit Jahren bekannt, dass sie Dateien in der Cloud analysieren könn(t)en. Dass sie das tatsächlich machen, ist m. E. eher zweifelhaft. M.E. wird eh zuviel Bohei gemacht. Und die Regierungen wissen eh längst alles über uns.
