Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.os.unix.linux.misc > #110321 > unrolled thread

Eagle 7.7.0 64-bit in Linux, fehlende Libraries

Back to article view | Back to de.comp.os.unix.linux.misc

Contents

  Eagle 7.7.0 64-bit in Linux, fehlende Libraries Joerg <news@analogconsultants.com> - 2020-05-08 15:36 -0700
    Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries Kay Martinen <kay@martinen.de> - 2020-05-09 01:00 +0200
      Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries Joerg <news@analogconsultants.com> - 2020-05-09 15:10 -0700
        Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2020-05-10 11:28 +0200
          Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries Joerg <news@analogconsultants.com> - 2020-05-10 11:08 -0700
            Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2020-05-11 13:12 +0200
              Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries olaf <olaf@criseis.ruhr.de> - 2020-05-11 14:17 +0200
                Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2020-05-11 14:46 +0200
                Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries Joerg <news@analogconsultants.com> - 2020-05-11 13:36 -0700
        Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2020-05-10 21:11 +0200
          Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries Joerg <news@analogconsultants.com> - 2020-05-11 13:45 -0700
            Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2020-05-12 22:48 +0200
              Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries Joerg <news@analogconsultants.com> - 2020-05-13 11:48 -0700
                Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries Enrik Berkhan <Enrik.Berkhan@inka.de> - 2020-05-13 19:44 +0000
                  Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries olaf <olaf@criseis.ruhr.de> - 2020-05-14 06:01 +0200
                Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries olaf <olaf@criseis.ruhr.de> - 2020-05-14 05:59 +0200
                  Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries Joerg <news@analogconsultants.com> - 2020-05-15 11:59 -0700
                    Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries olaf <olaf@criseis.ruhr.de> - 2020-05-16 06:11 +0200
                Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries Ralph Angenendt <dein.name@strg-alt-entf.org> - 2020-05-14 08:48 +0000
                  Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries Herrand Petrowitsch <herrands@t-online.de> - 2020-05-14 16:50 +0200
                    Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries Joerg <news@analogconsultants.com> - 2020-05-15 12:07 -0700
                      Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries Ralph Angenendt <dein.name@strg-alt-entf.org> - 2020-05-19 10:24 +0000
                        Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries Joerg <news@analogconsultants.com> - 2020-05-19 15:50 -0700
                          Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries Ralph Angenendt <dein.name@strg-alt-entf.org> - 2020-05-20 10:59 +0000
                            Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries Christian Schumacher <cs.spam@nurfuerspam.de> - 2020-05-20 17:51 +0200
                              Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries Marc Haber <mh+usenetspam1118@zugschl.us> - 2020-05-20 18:16 +0200
                              Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries Ralph Angenendt <dein.name@strg-alt-entf.org> - 2020-05-25 13:10 +0000
                            Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries Joerg <news@analogconsultants.com> - 2020-05-20 09:27 -0700
                Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2020-05-15 22:03 +0200
                  Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries Joerg <news@analogconsultants.com> - 2020-05-15 14:33 -0700
                    Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2020-05-20 21:21 +0200
                      Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries Joerg <news@analogconsultants.com> - 2020-05-20 14:55 -0700
              Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2020-05-20 08:39 +0200
    Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries olaf <olaf@criseis.ruhr.de> - 2020-05-09 06:18 +0200
      Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries Joerg <news@analogconsultants.com> - 2020-05-09 15:12 -0700
        Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries olaf <olaf@criseis.ruhr.de> - 2020-05-10 08:13 +0200
          Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries Joerg <news@analogconsultants.com> - 2020-05-10 11:21 -0700
            Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries Michael Brand <brandm@gmx.net> - 2020-05-11 10:19 +0200
              Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries Joerg <news@analogconsultants.com> - 2020-05-11 13:52 -0700
            Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries Christian Garbs <mitch@cgarbs.de> - 2020-05-11 17:59 +0200
              Re: Eagle 7.7.0 64-bit in Linux, fehlende Libraries Joerg <news@analogconsultants.com> - 2020-05-11 13:53 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#110467

On 2020-05-14 07:50, Herrand Petrowitsch wrote:
> Ralph Angenendt schrieb:
>> Well, Joerg wrote:
>
>>> Es erscheint keine Dependency-Fehlermeldung :-)
>>
>> Du nutzt einen Rechner von 2007 um eine Software von ~2015 laufen zu
>> lassen, auf einem Linux von 2020.


So what? Das tat dieser Rechner auch mit Windows 7 wunderbar und tut es 
ueber Dual-Boot immer noch. Auch Windows 10 soll darauf problemlos 
laufen, doch das moechte ich aus verschiedenen Gruenden nicht.

>
> Schlimmer noch:
> Der OP verwendet Kommunikations-Software, die seit langem nicht mehr
> gewartet werden kann und damit zur boesartigsten Sorte gehoert, wie hier
>
> - Windows XP (seit >6 Jahren ohne security updates) sowie
> - Mozilla Thunderbird 2.0.0.6 (seit ca. 13 Jahren nicht mehr mit
>    Sicherheitsupdates versorgt).
>

Voreiliger Schluss. Das ist nur Alt-Information im TB Profile. Windows 
XP gibt es hier nicht und TB 2.x ebenfalls nicht.


> Zudem befindet sich sein Works, welches er offenbar fuer die Buchhaltung
> (!) verwendet, seit mindestens >7 Jahren ausserhalb jeglicher
> maintenance, von Windows 7 fange ich gar nicht erst an (wie kann jemand
> nur auf den abstrusen Gedanken verfallen, ein abgekuendigtes und
> ungewartetes OS jetzt noch kaeuflich erwerben und dieses auch noch
> kommerziell einsetzen zu wollen?).
>

Ganz einfach, ohne Internet-Zugang. Reality Check: Gehe mal in eine 
Produktion, Clean Room, was immer. Dort finden sich oft Anlagen, die mit 
Win2k oder noch alter laufen. Bei einem meiner Produkte, das ich 1994 
entwickelt habe, laeuft der In-Ciruit Test auf DOS und das geht nicht 
anders. Zumindest in Amerika schmeissen wir Produktionsanlagen, die 
sauber funktionieren und deren Neuanschaffung fett sechsstellig kosten 
wuerde, nicht einfach weg.

[...]

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#110513

Well, Joerg <news@analogconsultants.com> wrote:
> On 2020-05-14 07:50, Herrand Petrowitsch wrote:
>> Ralph Angenendt schrieb:
>>> Well, Joerg wrote:
>>
>>>> Es erscheint keine Dependency-Fehlermeldung :-)
>>>
>>> Du nutzt einen Rechner von 2007 um eine Software von ~2015 laufen zu
>>> lassen, auf einem Linux von 2020.
>
>
> So what? Das tat dieser Rechner auch mit Windows 7 wunderbar und tut es 
> ueber Dual-Boot immer noch. Auch Windows 10 soll darauf problemlos 
> laufen, doch das moechte ich aus verschiedenen Gruenden nicht.

Zum "So what" habe ich ein paar Zeilen darunter was erklärt: Nutze ein 
Linux, dass (wahrscheinlich, ich habe das nicht getestet) die für eine 5 
Jahre alte Software benötigten Libraries mitbringt - und dort auch noch 
Securityupdates bekommt.

Ralph
-- 
He'll rekindle all the dreams it took you a lifetime to destroy

[toc] | [prev] | [next] | [standalone]

#110519

On 2020-05-19 03:24, Ralph Angenendt wrote:
> Well, Joerg <news@analogconsultants.com> wrote:
>> On 2020-05-14 07:50, Herrand Petrowitsch wrote:
>>> Ralph Angenendt schrieb:
>>>> Well, Joerg wrote:
>>>
>>>>> Es erscheint keine Dependency-Fehlermeldung :-)
>>>>
>>>> Du nutzt einen Rechner von 2007 um eine Software von ~2015 laufen zu
>>>> lassen, auf einem Linux von 2020.
>>
>>
>> So what? Das tat dieser Rechner auch mit Windows 7 wunderbar und tut es
>> ueber Dual-Boot immer noch. Auch Windows 10 soll darauf problemlos
>> laufen, doch das moechte ich aus verschiedenen Gruenden nicht.
>
> Zum "So what" habe ich ein paar Zeilen darunter was erklärt: Nutze ein
> Linux, dass (wahrscheinlich, ich habe das nicht getestet) die für eine 5
> Jahre alte Software benötigten Libraries mitbringt - und dort auch noch
> Securityupdates bekommt.
>

Es ist aber schon traurig, wenn eine Software nach fuenf Jahren bereits 
als "zu alt" abgeschossen wird.

Doch das laesst sich ja in diesem Fall huebsch mit WINE umschiffen. Da 
laeuft sogar noch Software aus Zeiten, als die Leute noch von Baeumen 
geschwungen sind.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#110521

Well, Joerg <news@analogconsultants.com> wrote:
> On 2020-05-19 03:24, Ralph Angenendt wrote:
>> Zum "So what" habe ich ein paar Zeilen darunter was erklärt: Nutze ein
>> Linux, dass (wahrscheinlich, ich habe das nicht getestet) die für eine 5
>> Jahre alte Software benötigten Libraries mitbringt - und dort auch noch
>> Securityupdates bekommt.
>>
>
> Es ist aber schon traurig, wenn eine Software nach fuenf Jahren bereits 
> als "zu alt" abgeschossen wird.

Die Welt bleibt halt nicht stehen. Und es wäre auch kein Problem, die 
Software entweder ab und an mal neu zu bauen - aber das von Herstellern 
zu erwarten, die Geld für ihre Software nehmen, scheint echt zu viel 
erwartet zu sein.

Ich bin ja ganz froh, dass Linux nicht den koompletten Ballast mit sich 
rumschleppt, wie es Windows macht, damit auch ja irgendwelche Software 
von Anno Tuck noch läuft.

Ralph
-- 
He'll rekindle all the dreams it took you a lifetime to destroy

[toc] | [prev] | [next] | [standalone]

#110522

Am 20.05.20 um 12:59 schrieb Ralph Angenendt:
> Well, Joerg <news@analogconsultants.com> wrote:
>> Es ist aber schon traurig, wenn eine Software nach fuenf Jahren bereits
>> als "zu alt" abgeschossen wird.
> 
> Die Welt bleibt halt nicht stehen. Und es wäre auch kein Problem, die
> Software entweder ab und an mal neu zu bauen - aber das von Herstellern
> zu erwarten, die Geld für ihre Software nehmen, scheint echt zu viel
> erwartet zu sein.
> 
> Ich bin ja ganz froh, dass Linux nicht den koompletten Ballast mit sich
> rumschleppt, wie es Windows macht, damit auch ja irgendwelche Software
> von Anno Tuck noch läuft.

Dann wäre es ja mal Zeit für ein Newsreader-Update, oder? ;-)
old/slrn-1.0.2.tar.gz
     creation date: 2014-09-20

-- 
Gruß
Christian

[toc] | [prev] | [next] | [standalone]

#110523

Christian Schumacher <cs.spam@nurfuerspam.de> wrote:
>Am 20.05.20 um 12:59 schrieb Ralph Angenendt:
>> Well, Joerg <news@analogconsultants.com> wrote:
>>> Es ist aber schon traurig, wenn eine Software nach fuenf Jahren bereits
>>> als "zu alt" abgeschossen wird.
>> 
>> Die Welt bleibt halt nicht stehen. Und es wäre auch kein Problem, die
>> Software entweder ab und an mal neu zu bauen - aber das von Herstellern
>> zu erwarten, die Geld für ihre Software nehmen, scheint echt zu viel
>> erwartet zu sein.
>> 
>> Ich bin ja ganz froh, dass Linux nicht den koompletten Ballast mit sich
>> rumschleppt, wie es Windows macht, damit auch ja irgendwelche Software
>> von Anno Tuck noch läuft.
>
>Dann wäre es ja mal Zeit für ein Newsreader-Update, oder? ;-)
>old/slrn-1.0.2.tar.gz
>     creation date: 2014-09-20

Meiner ist von 2009 ;-)

Grüße
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[toc] | [prev] | [next] | [standalone]

#110605

Well, Christian Schumacher <cs.spam@nurfuerspam.de> wrote:
> Am 20.05.20 um 12:59 schrieb Ralph Angenendt:
> Dann wäre es ja mal Zeit für ein Newsreader-Update, oder? ;-)
> old/slrn-1.0.2.tar.gz
>      creation date: 2014-09-20

Hey, das Binary ist immerhin von 2016. Und slrn bekomme ich auch noch 
neu gebaut, wenn ich meine, dass das unbedingt sein muss - aber der von 
Ubuntu 16.04. läuft ja noch ...

Ralph
-- 
He'll rekindle all the dreams it took you a lifetime to destroy

[toc] | [prev] | [next] | [standalone]

#110524

On 2020-05-20 03:59, Ralph Angenendt wrote:
> Well, Joerg <news@analogconsultants.com> wrote:
>> On 2020-05-19 03:24, Ralph Angenendt wrote:
>>> Zum "So what" habe ich ein paar Zeilen darunter was erklärt: Nutze ein
>>> Linux, dass (wahrscheinlich, ich habe das nicht getestet) die für eine 5
>>> Jahre alte Software benötigten Libraries mitbringt - und dort auch noch
>>> Securityupdates bekommt.
>>>
>>
>> Es ist aber schon traurig, wenn eine Software nach fuenf Jahren bereits
>> als "zu alt" abgeschossen wird.
>
> Die Welt bleibt halt nicht stehen.


Leider tut sie das bei Software schonmal, besonders in Nischenbereichen.


>                                ... Und es wäre auch kein Problem, die
> Software entweder ab und an mal neu zu bauen - aber das von Herstellern
> zu erwarten, die Geld für ihre Software nehmen, scheint echt zu viel
> erwartet zu sein.
>

Hatte ich mehrfach geschrieben. Etliche Software-Hersteller gibt es 
schon lange nicht mehr. Bei anderen wurde ein Software-Produkt 
eingestellt, aber es ist ein sehr praktisches und gutes. In wiederum 
anderen Faellen hat man einen Fundus an existierenden Templates, die bei 
einem Wechsel saemtlich inkompatibel wuerden und in tagelanger und 
unnoetiger Arbeit neu erstellt werden muessten. Mit dem Ergebnis, dass 
dann Files aus den Vorjahren nicht mehr lesbar waeren. Beispiel MS-Works.

In diesem Fall ist es so, dass die Software mit allen Rechten am Design 
zweimal weiterverkauft wurde und der letzte Hersteller (Autodesk) auf 
ein Abo-Modell mit Jahresgebuehr gewechselt hat. Das moechten viele 
Leute wie ich aus naheliegenden Gruenden nicht mitmachen.


> Ich bin ja ganz froh, dass Linux nicht den koompletten Ballast mit sich
> rumschleppt, wie es Windows macht, damit auch ja irgendwelche Software
> von Anno Tuck noch läuft.
>

Trends in diese Richtung sind mit Snap und Flatpak aber deutlich zu 
vernehmen und das begruesse ich. Ohne solche Nachhaltigkeit hat ein OS 
keine Chance, dass der Marktanteil im Einzelplatzgebrauch steigt.

Ein Paradebeispiel fand ich gestern bei der Suche nach einem WLAN 
Treiber. Den muss man sich fuer den Linux-Boot (Debian) muehsam 
zusammenklauben und kompilieren. Mit dem Hinweis, dass einem ein 
Kernel-Update das ganze mit hoher Wahrscheinlichkeit wieder zerschiesst. 
Wenn das per Auto-Update kurz vor einem Meeting passiert, ist das ganz toll.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#110470

Hallo Joerg,

Du schriebst am Wed, 13 May 2020 11:48:22 -0700:

> > Klar sind Computer Werkzeuge, Werkzeuge ohne vorgefertigte Funktion. Ein
> > Computer macht halt ohne die Funktion - Software - _gernichts_. Na gut,
> > er verbraucht Strom, wenn er eingeschaltet wird...
> 
> Das ist bei normalem Werkzeug wie etwa einer Dremel nicht anders. Und da 

Kommt in (sehr) groben Zügen hin...

> haette ich es auch gern wie bei der Dremel. Wenn man die Polierscheibe 
> reintut, poliert sie. Wenn man einen Fraeskopf reinspannt, fraest sie. 

Ächt? So ganz ohne Mitwirken des Benutzers? Der muß da überhaupt nicht
wissen - oder gar lernen - wie man das richtig macht, damit man keine
Striemen in der Oberfläche oder gar Löcher an der falscha Stelle
produziert, oder sich gar in die Finger fräst?
Aber beim Computer muß das natürlich alles ohne Vorkenntnisse gehen.

> Es erscheint keine Dependency-Fehlermeldung :-)

Der 3er Bohrer paßt aber nicht, den kann ich nicht einspannen!
Und der Fräsersatz von <anderem Hersteller> geht auch nicht.
Warum ist das nicht alles schon im Grundgerät integriert?

[WINE]
> >> Schon, aber ich kann weder bei Eagle noch bei anderer Software (fuer
> >> die es keine Linux-Version gibt) Nachteile feststellen.  
> >
> > Die Nachteile sind: mit WINE wird ein dicker Klotz Software geladen, der
> > viel Arbeitsspeicher kostet, ...  
> 
> Macht nichts mehr. Zu meiner Ueberraschung hat der Rechner nach einem 
> BIOS Update 6GB RAM gefressen, obwohl laut Dell bei 4GB haette Schluss 

Bist ein guter Konsument...

> >             ... das Laden allein dauert schon elend lange, ...  
> 
> Das kann ich fuer Eagle, MS-Works und aehnliches nicht bestaetigen. Bei 

Bist ein geduldiger Benutzer, sozusagen ein Patient.

> LTSpice weiss ich es nicht, es funktioniert nur unmittelbar nach 
> Installation und dann sehr gut. Nach jedem Re-Boot ist es weg, wird 

Vielleicht geht das bei einer Linux-Implementation?

...
> > Aber auf einer Deiner schwächeren Maschinen solltest Du das wohl besser
> > nicht machen.
> 
> Das ist ja gerade der Pfiff. Ich habe zur Probe Simulationen mit LTSpice 
> unter WINE laufen lassen und die sind kaum langsamer als im Windows-Boot 

What wonder - Software, die zu 90% rechenintensive Funktionen abarbeitet,
die identisch laufen, ist "kaum langsamer" aufgrund der 10% Anzeige- und
Bedienfunktionen. Da ist dann wohl das, was wirklich beeinflußt wird, um
Faktoren >2 langsamer.

...
> > Nicht in diesem Zusammenhang - _Du_ hast Eagle haben wollen.  
> 
> Wer viel Hardware entwickelt, weiss wie muehselig ein CAD-Wechsel ist. 

Ist Dir doch unbenommen. Du darfst Dich auch mit der Zwischenlage WINE
damit rumquälen, wenn's für Dich ausreichend läuft.
Nur solltest Du dann nicht irgendwann mal kommen und Dich drüber beklagen,
daß es "unter Linux" doch so langsam und umständlich funktioniert.

...
> > Auch mit WINE wird der Aufwand nicht viel kleiner, ...  
> 
> Der Aufwand  war wesentlich kleiner. Rechtklick -> Install with WINE -> 
> Lizenz-File laden, Lizenz-Code eintippen -> feddich.
...
> Ja, allerdings muss ich noch herausfinden, wie man die Datenspeicherung 
> nicht ueber die emulierten Windows "Festplatten" macht, sondern z.B. in 

Soweit ich WINE (noch) kenne, nutzt das keine "emulierten Festplatten",
sondern einfach Links auf Verzeichnisbäume mit dem passenden Inhalt.
Stz' Dir einfach 'n Link "e:" oder so in Dein ~/.wine/dosdevices, der auf
ein Verzeichnis mit dem gewünschten Inhalt zeigt. Das kannst Du dann in dem
Windows-Programm als "Laufwerk" "E:" benutzen.

> eine gemeinsame NTFS Partition und ins Netzwerk kommt. Egal, das sind am 
> Ende nur Feinheiten und nicht "mission-critical".

Unter Linux - auch mit WINE - solltest Du NTFS künftig _meiden_. Das ist
keine "Feinheit", sondern verhindert u.U. größere Probleme mit fremdartigen
(Speicher-) Verfahren.

[Sicherheit]
> Klar, Web Browsing machen wir hier jetzt eh mit Linux und meine Frau hat 
> weder Dual-Boot noch WINE auf dem Rechner.

Wobei der größte Gefahrenherd bei internet-Zugängen immer vor dem
Bildschirm sitzt.

...
> > WINE ist nichtmal eine Krücke, WINE ist der Rollstuhl, die Vorstufe zur
> > Bettlägrigkeit.
> 
> Ach wat, es ist eine wunderbares Feature von Linux. Fuer einige von uns 

Wie Du grandios belegst, ist es ein wunderbares Mittel für Leute, die
eigentlich kein anderes System haben wollen, trotz geändertem Unterbau
weiterhin auf ihren gewohnten Dielen 'rumlaufen zu können.

> gibt es "mission-critical" Software, fuer die es keine Linux-Version 
> oder Alternative gibt und mit aelteren Rechnern kann man VM vergessen, 
> seit Oracle den VT-x Zwang eingefuehrt hat.

Nur, wenn man unbedingt VirtualBox verwenden will, weil man sich dann nicht
weiter mit Grundlagen beschäftigen müssen zu können meint.

> [...]
> Gerade probiert. Vom Doppelklick auf das Eagle Desktop Icon bis zum 
> offenen Proramm dauert es mit WINE 15 Sekunden. Das finde ich voellig 
> akzeptabel, zumal es ein Rechner Baujahr 2007 ist.

Gut meine Kiste ist - wenn auch in einem erheblich älteren Gehäuse - schon
deutlich schneller, da startet Eagle (egal ob 5.8.0 oder 7.5.0) in weniger
als 1 Sekunde, inklusive Umschaltung der Installationsverzeichnisse.

> Das ist nicht mein Hauptrechner, sondern der fuer Arbeiten am 
> Labortisch. Man braucht nicht fuer alle Erledigungen einen Ferrari.

Mich stört's nicht, wenn Du damit zufrieden bist.
Wenn Du damit zufrieden bist, will ich Dir das nicht ausreden.
Alles Gute mit Deinem ([wine] "besoffenen") Eagle!

-- 
-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#110471

On 2020-05-15 13:03, Sieghard Schicktanz wrote:
> Hallo Joerg,
>
> Du schriebst am Wed, 13 May 2020 11:48:22 -0700:
>
>>> Klar sind Computer Werkzeuge, Werkzeuge ohne vorgefertigte Funktion. Ein
>>> Computer macht halt ohne die Funktion - Software - _gernichts_. Na gut,
>>> er verbraucht Strom, wenn er eingeschaltet wird...
>>
>> Das ist bei normalem Werkzeug wie etwa einer Dremel nicht anders. Und da
>
> Kommt in (sehr) groben Zügen hin...
>
>> haette ich es auch gern wie bei der Dremel. Wenn man die Polierscheibe
>> reintut, poliert sie. Wenn man einen Fraeskopf reinspannt, fraest sie.
>
> Ächt? So ganz ohne Mitwirken des Benutzers? Der muß da überhaupt nicht
> wissen - oder gar lernen - wie man das richtig macht, damit man keine
> Striemen in der Oberfläche oder gar Löcher an der falscha Stelle
> produziert, oder sich gar in die Finger fräst?
> Aber beim Computer muß das natürlich alles ohne Vorkenntnisse gehen.
>

Die Anwender-Software kann als hinlaenglich bekannt vorauagesetzt 
werden, damit kann ich umgehen. Der Computer muss sie aber fressen, ohne 
dass es Dependency Errors et cetera gibt. Ich muss bei der Dremel ja 
auch nicht wissen, wie die Maschine innen aussieht.


>> Es erscheint keine Dependency-Fehlermeldung :-)
>
> Der 3er Bohrer paßt aber nicht, den kann ich nicht einspannen!
> Und der Fräsersatz von <anderem Hersteller> geht auch nicht.
> Warum ist das nicht alles schon im Grundgerät integriert?
>

Gibt es Adapter fuer oder man nimmt den Akkuschrauber.

https://www.amazon.com/Dremel-4486-MultiPro-Keyless-Chuck/dp/B0000302ZV


> [WINE]
>>>> Schon, aber ich kann weder bei Eagle noch bei anderer Software (fuer
>>>> die es keine Linux-Version gibt) Nachteile feststellen.
>>>
>>> Die Nachteile sind: mit WINE wird ein dicker Klotz Software geladen, der
>>> viel Arbeitsspeicher kostet, ...
>>
>> Macht nichts mehr. Zu meiner Ueberraschung hat der Rechner nach einem
>> BIOS Update 6GB RAM gefressen, obwohl laut Dell bei 4GB haette Schluss
>
> Bist ein guter Konsument...
>

Das war nicht das erste Mal :-)

Ich habe hier viele Werkzeuge in Benutzung, die weit ueber ein halbes 
Jahrhundert alt sind.

http://www.analogconsultants.com/ng/sed/olddrill.JPG

Die Kroenung war eine alte Dame, die ueber ihr ganzes Leben nur ein 
einziges Auto gekauft hat und immer noch fuhr, einen in den 50ern 
gebraucht erworbenen Austin Sportwagen.


>>>              ... das Laden allein dauert schon elend lange, ...
>>
>> Das kann ich fuer Eagle, MS-Works und aehnliches nicht bestaetigen. Bei
>
> Bist ein geduldiger Benutzer, sozusagen ein Patient.
>

15sec sind fuer mich jetzt keine Ewigkeit, zumal man ja immer auch was 
anderes zu tun hat.


>> LTSpice weiss ich es nicht, es funktioniert nur unmittelbar nach
>> Installation und dann sehr gut. Nach jedem Re-Boot ist es weg, wird
>
> Vielleicht geht das bei einer Linux-Implementation?
>

Tja, wenn es die denn gaebe :-(

> ...
>>> Aber auf einer Deiner schwächeren Maschinen solltest Du das wohl besser
>>> nicht machen.
>>
>> Das ist ja gerade der Pfiff. Ich habe zur Probe Simulationen mit LTSpice
>> unter WINE laufen lassen und die sind kaum langsamer als im Windows-Boot
>
> What wonder - Software, die zu 90% rechenintensive Funktionen abarbeitet,
> die identisch laufen, ist "kaum langsamer" aufgrund der 10% Anzeige- und
> Bedienfunktionen. Da ist dann wohl das, was wirklich beeinflußt wird, um
> Faktoren >2 langsamer.
>

Fast alle meine Software ist fuer rechenintensive Dinge. Vielleicht 
begeistert mich WINE deshalb so.

> ...
>>> Nicht in diesem Zusammenhang - _Du_ hast Eagle haben wollen.
>>
>> Wer viel Hardware entwickelt, weiss wie muehselig ein CAD-Wechsel ist.
>
> Ist Dir doch unbenommen. Du darfst Dich auch mit der Zwischenlage WINE
> damit rumquälen, wenn's für Dich ausreichend läuft.
> Nur solltest Du dann nicht irgendwann mal kommen und Dich drüber beklagen,
> daß es "unter Linux" doch so langsam und umständlich funktioniert.
>

Was ich noch rausfinden muss ist, wie man von WINE aus auf 
Speicherbereicher ausserhalb von /.wine zugreift, vor allem auf das 
Netzwerk. Fuer Dateien und so. Das haben andere jedoch schon geloest.

https://fitzcarraldoblog.wordpress.com/2016/09/18/how-to-enable-a-windows-application-in-wine-to-access-a-samba-share-on-a-nas/


> ...
>>> Auch mit WINE wird der Aufwand nicht viel kleiner, ...
>>
>> Der Aufwand  war wesentlich kleiner. Rechtklick -> Install with WINE ->
>> Lizenz-File laden, Lizenz-Code eintippen -> feddich.
> ...
>> Ja, allerdings muss ich noch herausfinden, wie man die Datenspeicherung
>> nicht ueber die emulierten Windows "Festplatten" macht, sondern z.B. in
>
> Soweit ich WINE (noch) kenne, nutzt das keine "emulierten Festplatten",
> sondern einfach Links auf Verzeichnisbäume mit dem passenden Inhalt.
> Stz' Dir einfach 'n Link "e:" oder so in Dein ~/.wine/dosdevices, der auf
> ein Verzeichnis mit dem gewünschten Inhalt zeigt. Das kannst Du dann in dem
> Windows-Programm als "Laufwerk" "E:" benutzen.
>

Danke, so aehnlich sollte es gehen.


>> eine gemeinsame NTFS Partition und ins Netzwerk kommt. Egal, das sind am
>> Ende nur Feinheiten und nicht "mission-critical".
>
> Unter Linux - auch mit WINE - solltest Du NTFS künftig _meiden_. Das ist
> keine "Feinheit", sondern verhindert u.U. größere Probleme mit fremdartigen
> (Speicher-) Verfahren.
>

Nicht so einfach, da ich auch im Windows-Boot auf dieselben 
Speicherbereiche muss. FAT32 ginge natuerlich auch, zumal ich keine 
Spielfilme speichern muss. Ich koennte das mit gparted umformatieren, 
habe aber im Internet gelesen, dass Debian inzwischen recht gut mit NTFS 
zurechtkommen soll.

Mit ArchLinux wuerde ich das natuerlich nicht versuchen, da ist derzeit 
alles ext3 und FAT.


> [Sicherheit]
>> Klar, Web Browsing machen wir hier jetzt eh mit Linux und meine Frau hat
>> weder Dual-Boot noch WINE auf dem Rechner.
>
> Wobei der größte Gefahrenherd bei internet-Zugängen immer vor dem
> Bildschirm sitzt.
>

Bei uns weniger, wir machen keine heiklen Sachen ueber Internet.


> ...
>>> WINE ist nichtmal eine Krücke, WINE ist der Rollstuhl, die Vorstufe zur
>>> Bettlägrigkeit.
>>
>> Ach wat, es ist eine wunderbares Feature von Linux. Fuer einige von uns
>
> Wie Du grandios belegst, ist es ein wunderbares Mittel für Leute, die
> eigentlich kein anderes System haben wollen, trotz geändertem Unterbau
> weiterhin auf ihren gewohnten Dielen 'rumlaufen zu können.
>

Nein, es ist ein Notbehelf, aber ein weit besser als erwartet 
funktioniertender. Wie soll ich sonst meine LTSpice Files laufen lassen 
oder MS-Works Datenbanken weiterpflegen?


>> gibt es "mission-critical" Software, fuer die es keine Linux-Version
>> oder Alternative gibt und mit aelteren Rechnern kann man VM vergessen,
>> seit Oracle den VT-x Zwang eingefuehrt hat.
>
> Nur, wenn man unbedingt VirtualBox verwenden will, weil man sich dann nicht
> weiter mit Grundlagen beschäftigen müssen zu können meint.
>

Klar, qemu und anderes werde ich noch probieren. Der Tag hat leider nur 
24h und es liegen noch bergeweise anderer Arbeiten an. Was ich noch weit 
weniger als Dependencies leiden kann, ist z.B. Unkraut zupfen :-)


>> [...]
>> Gerade probiert. Vom Doppelklick auf das Eagle Desktop Icon bis zum
>> offenen Proramm dauert es mit WINE 15 Sekunden. Das finde ich voellig
>> akzeptabel, zumal es ein Rechner Baujahr 2007 ist.
>
> Gut meine Kiste ist - wenn auch in einem erheblich älteren Gehäuse - schon
> deutlich schneller, da startet Eagle (egal ob 5.8.0 oder 7.5.0) in weniger
> als 1 Sekunde, inklusive Umschaltung der Installationsverzeichnisse.
>

Das ist so wie die Rudolf Diesel Gedenkzeit bei aelteren Benzen 
(Vorgluehen), hat keinen von deren Besitzern gestoert. Ausser wenn die 
Batterie so gut wie platt war.


>> Das ist nicht mein Hauptrechner, sondern der fuer Arbeiten am
>> Labortisch. Man braucht nicht fuer alle Erledigungen einen Ferrari.
>
> Mich stört's nicht, wenn Du damit zufrieden bist.
> Wenn Du damit zufrieden bist, will ich Dir das nicht ausreden.
> Alles Gute mit Deinem ([wine] "besoffenen") Eagle!
>

Selbst bevorzuge ich Belgische Klosterbiere.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#110528

Hallo Joerg,

(Sorry, war ein paar Tage unerreichbar, Albasani ist derzeit verschwunden.)

Du schriebst am Fri, 15 May 2020 14:33:00 -0700:

> >>> Klar sind Computer Werkzeuge, Werkzeuge ohne vorgefertigte Funktion.
...
> >> Das ist bei normalem Werkzeug wie etwa einer Dremel nicht anders. Und
...
> > Ächt? So ganz ohne Mitwirken des Benutzers? Der muß da überhaupt nicht
> > wissen - oder gar lernen - wie man das richtig macht, damit man keine
...
> Die Anwender-Software kann als hinlaenglich bekannt vorauagesetzt 
> werden, damit kann ich umgehen. Der Computer muss sie aber fressen, ohne 
> dass es Dependency Errors et cetera gibt. Ich muss bei der Dremel ja 
> auch nicht wissen, wie die Maschine innen aussieht.

Nee, aber Du mußt wissen, daß das Futter keine 3er Bohrer aufnehmen kann
und daß eine Trennscheibe möglichst nicht in Laufrichtung über Kanten
geführt werden sollte. Du mußt bei sonem Ding sogar recht genau wissen, wie
Du mit den einzelnen Werkzeugen umgehen mußt und wie die eingesetzt werden
sollen.

> >> Es erscheint keine Dependency-Fehlermeldung :-)  

Spannst Du den Bohrer mit der Schneide ins Futter ein -> Dependency Error,
nix geht. Und der wird Dir nichtmal angezeigt, den mußt Du selber finden!

> > Der 3er Bohrer paßt aber nicht, den kann ich nicht einspannen!
> > Und der Fräsersatz von <anderem Hersteller> geht auch nicht.
> > Warum ist das nicht alles schon im Grundgerät integriert?
> 
> Gibt es Adapter fuer oder man nimmt den Akkuschrauber.

Aber ich _WILL_ doch unbedingt den Dremel (Linux) nehmen! Den Akkuschrauber
(Windows) will ich nicht mehr! (O-Ton Joerg in de.comp.os.unix.linux.misc.)

> > [WINE]  
> >>> Die Nachteile sind: mit WINE wird ein dicker Klotz Software geladen,
...
> >> BIOS Update 6GB RAM gefressen, obwohl laut Dell bei 4GB haette
...
> > Bist ein guter Konsument...
...
> Das war nicht das erste Mal :-)
> 
> Ich habe hier viele Werkzeuge in Benutzung, die weit ueber ein halbes 
> Jahrhundert alt sind.

Auch alle mit viel Geld soweit "aufpoliert", daß sie mit aktuellen
Zusatzteilen arbeiten? (Deine alte Bohrmühle kannste steckenlassen, die
bohrt inzwischen wahrscheinlich eher Dreicke.)

> Die Kroenung war eine alte Dame, die ueber ihr ganzes Leben nur ein 
> einziges Auto gekauft hat und immer noch fuhr, einen in den 50ern 
> gebraucht erworbenen Austin Sportwagen.

Muß sie eine schöne Stange Geld für die Aufbereitungen gekostet haben.

Aber sicher, solange es noch sinnvoll (!) machbar ist, sind Reparaturen
einer Neuanschaffung vorzuziehen - sogar wenn sie teurer kommen, weil dafür
einges an "unsichtbaren" Kosten (Dreck, Gesundheitsbeeinträchtigung,
Belastungen) entfällt. Aber irgendwann ist dann eine Wiederverwertung der
alten Teile doch sinnvoller.

> >>>              ... das Laden allein dauert schon elend lange, ...  
..
> 15sec sind fuer mich jetzt keine Ewigkeit, zumal man ja immer auch was 
> anderes zu tun hat.

Wenn Du das so siehst, i.O.

> >> LTSpice weiss ich es nicht, es funktioniert nur unmittelbar nach
> >> Installation und dann sehr gut. Nach jedem Re-Boot ist es weg, wird  
> >
> > Vielleicht geht das bei einer Linux-Implementation?
> 
> Tja, wenn es die denn gaebe :-(

Von Spice gibt es Varianten, für die auch Linux-Implementationen
existieren. Nachdem ich sowas bisher nicht notwendig gebraucht habe, kenne
ich mich da aber nicht recht aus.

...
> >> Das ist ja gerade der Pfiff. Ich habe zur Probe Simulationen mit
> >> LTSpice unter WINE laufen lassen und die sind kaum langsamer als im
> >> Windows-Boot  
> >
> > What wonder - Software, die zu 90% rechenintensive Funktionen
> > abarbeitet, die identisch laufen, ist "kaum langsamer" aufgrund der 10%
> > Anzeige- und Bedienfunktionen. Da ist dann wohl das, was wirklich
> > beeinflußt wird, um Faktoren >2 langsamer.
> 
> Fast alle meine Software ist fuer rechenintensive Dinge. Vielleicht 
> begeistert mich WINE deshalb so.

Ein Graphiker oder in verwandten Bereichen Arbeitender sähe das sicher
anders. Sogar schon ein "Softwerker", wenn der speicherintensive Sachen
bearbeitet. Und Speicherbedarf kann Dir auch Deine Simulationen versauen,
wenn die nicht nur klitzeklein sind.

> > ...  
> Was ich noch rausfinden muss ist, wie man von WINE aus auf 
> Speicherbereicher ausserhalb von /.wine zugreift, vor allem auf das 
> Netzwerk. Fuer Dateien und so. Das haben andere jedoch schon geloest.
> 
> https://fitzcarraldoblog.wordpress.com/2016/09/18/how-to-enable-a-windows-application-in-wine-to-access-a-samba-share-on-a-nas/

Naja, ohne das jetzt angeschaut zu haben - ich würde das Samba-Share halt
einfach auf ein passendes, vom "WINE-Programm" zugängliches Verzeichnis
mappen und das darüber benutzen. (Wobei das NAS doch hoffentlich unter
Linux läuft und dann auch NFS zur Verfügung stellen sollte...)

> > ...  
> >>> Auch mit WINE wird der Aufwand nicht viel kleiner, ...  
> >>
> >> Der Aufwand  war wesentlich kleiner. Rechtklick -> Install with WINE ->
> >> Lizenz-File laden, Lizenz-Code eintippen -> feddich.  

Bis auf die eigentliche Arbeit...

> >> Ja, allerdings muss ich noch herausfinden, wie man die Datenspeicherung
> >> nicht ueber die emulierten Windows "Festplatten" macht, sondern z.B.
...
> > Soweit ich WINE (noch) kenne, nutzt das keine "emulierten Festplatten",
> > sondern einfach Links auf Verzeichnisbäume mit dem passenden Inhalt.
> > Stz' Dir einfach 'n Link "e:" oder so in Dein ~/.wine/dosdevices, der
> > auf ein Verzeichnis mit dem gewünschten Inhalt zeigt. Das kannst Du
> > dann in dem Windows-Programm als "Laufwerk" "E:" benutzen.
> 
> Danke, so aehnlich sollte es gehen.

Kannst ja mal berichten, ob.

...
> > Unter Linux - auch mit WINE - solltest Du NTFS künftig _meiden_. Das ist
...
> Nicht so einfach, da ich auch im Windows-Boot auf dieselben 
> Speicherbereiche muss. FAT32 ginge natuerlich auch, zumal ich keine 

Ok, das ist natürlich ein Ausschlußkriterium. FAT(32) ist da sicher die
letzte Wahl...

> Mit ArchLinux wuerde ich das natuerlich nicht versuchen, da ist derzeit 
> alles ext3 und FAT.

Wenn das einigermaßen aktuell ist, sollte das genauso gehen. Kennzeichen:
ntfs-3g und Fuse-Treiber (Fuse: File System in User Space).

> > [Sicherheit]  
> > Wobei der größte Gefahrenherd bei internet-Zugängen immer vor dem
> > Bildschirm sitzt.
> 
> Bei uns weniger, wir machen keine heiklen Sachen ueber Internet.

Manchmal machen die heiklen Sachen die Betreiber der Sites...
Da kann angeblich schon das Überfahren eines "Links" (natürlich nicht
erkennbar gekennzeichnet) reichen, oder ein mitgeladenes Script macht das
sowieso schon alles gleich beim Aufruf. Nur gut, daß sowas hauptsächlich
auf Windows-Benutzer abzielt - aber man sollte sich auch als Linuxer nicht
zu sicher meinen.

> > ...  
> >>> WINE ist nichtmal eine Krücke, WINE ist der Rollstuhl, die Vorstufe
> >>> zur Bettlägrigkeit.  
...
> > Wie Du grandios belegst, ist es ein wunderbares Mittel für Leute, die
> > eigentlich kein anderes System haben wollen, trotz geändertem Unterbau
> > weiterhin auf ihren gewohnten Dielen 'rumlaufen zu können.
> 
> Nein, es ist ein Notbehelf, aber ein weit besser als erwartet 
> funktioniertender. Wie soll ich sonst meine LTSpice Files laufen lassen 
> oder MS-Works Datenbanken weiterpflegen?

Etwa genauso wie eine originale James-Watt-Dampfmaschine oder einen
Lanz-Bulldog?

[VirtualBox, VT-x]
> Klar, qemu und anderes werde ich noch probieren. Der Tag hat leider nur 
> 24h und es liegen noch bergeweise anderer Arbeiten an. Was ich noch weit 
> weniger als Dependencies leiden kann, ist z.B. Unkraut zupfen :-)

Das (und Rasenpflege) habe ich "delegiert". Bloß Erdhaufen mit Baumstümpfen
planieren "durfte" ich grade eben... aber freiwillig, bei schönstem Wetter.

-- 
-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#110531

On 2020-05-20 12:21, Sieghard Schicktanz wrote:
> Hallo Joerg,
>
> (Sorry, war ein paar Tage unerreichbar, Albasani ist derzeit verschwunden.)
>
> Du schriebst am Fri, 15 May 2020 14:33:00 -0700:
>
>>>>> Klar sind Computer Werkzeuge, Werkzeuge ohne vorgefertigte Funktion.
> ...
>>>> Das ist bei normalem Werkzeug wie etwa einer Dremel nicht anders. Und
> ...
>>> Ächt? So ganz ohne Mitwirken des Benutzers? Der muß da überhaupt nicht
>>> wissen - oder gar lernen - wie man das richtig macht, damit man keine
> ...
>> Die Anwender-Software kann als hinlaenglich bekannt vorauagesetzt
>> werden, damit kann ich umgehen. Der Computer muss sie aber fressen, ohne
>> dass es Dependency Errors et cetera gibt. Ich muss bei der Dremel ja
>> auch nicht wissen, wie die Maschine innen aussieht.
>
> Nee, aber Du mußt wissen, daß das Futter keine 3er Bohrer aufnehmen kann
> und daß eine Trennscheibe möglichst nicht in Laufrichtung über Kanten
> geführt werden sollte. Du mußt bei sonem Ding sogar recht genau wissen, wie
> Du mit den einzelnen Werkzeugen umgehen mußt und wie die eingesetzt werden
> sollen.
>
>>>> Es erscheint keine Dependency-Fehlermeldung :-)
>
> Spannst Du den Bohrer mit der Schneide ins Futter ein -> Dependency Error,
> nix geht. Und der wird Dir nichtmal angezeigt, den mußt Du selber finden!
>

Sowas weiss man. Genauso wie man mit der Anwender-Software umgehen kann, 
sonst wuerde man die nicht benutzen. Doch ist es nicht erforderlich, die 
Innereien des Dremel zu kennen oder gar neue bauen und in dessen 
Steuerung integrieren zu muessen.


>>> Der 3er Bohrer paßt aber nicht, den kann ich nicht einspannen!
>>> Und der Fräsersatz von <anderem Hersteller> geht auch nicht.
>>> Warum ist das nicht alles schon im Grundgerät integriert?
>>
>> Gibt es Adapter fuer oder man nimmt den Akkuschrauber.
>
> Aber ich _WILL_ doch unbedingt den Dremel (Linux) nehmen! Den Akkuschrauber
> (Windows) will ich nicht mehr! (O-Ton Joerg in de.comp.os.unix.linux.misc.)
>

Die Gruende hatte ich mehrfach erklaert. Ich wuerde auch die Dremel 
nicht mehr benutzen, wenn sie staendig an eine Zentrale melden wuerde, 
wieviele Loecher ich gebohrt habe und wann.


>>> [WINE]
>>>>> Die Nachteile sind: mit WINE wird ein dicker Klotz Software geladen,
> ...
>>>> BIOS Update 6GB RAM gefressen, obwohl laut Dell bei 4GB haette
> ...
>>> Bist ein guter Konsument...
> ...
>> Das war nicht das erste Mal :-)
>>
>> Ich habe hier viele Werkzeuge in Benutzung, die weit ueber ein halbes
>> Jahrhundert alt sind.
>
> Auch alle mit viel Geld soweit "aufpoliert", daß sie mit aktuellen
> Zusatzteilen arbeiten?


Opa hat vor gut einem halben Jahrhundert tatsaechlich ein Zusatzteil 
besorgt, einen Adapter von Taper auf runde Standardbohrer. Ich weiss 
nicht mehr, wie Taper bei Euch bezeichnet wird, es sind die Bohrer mit 
schwertartigem Schaft. Von denen ich uebrigens noch sehr viele in 
Benutzung und die sind weit ueber ein halbes Jahrhundert alt. Ich habe 
dann noch ein US-Stromkabel rangebaut, wegen Auswanderung.


>           ... (Deine alte Bohrmühle kannste steckenlassen, die
> bohrt inzwischen wahrscheinlich eher Dreicke.)
>

Nix, die bohrt absolut sauber.


>> Die Kroenung war eine alte Dame, die ueber ihr ganzes Leben nur ein
>> einziges Auto gekauft hat und immer noch fuhr, einen in den 50ern
>> gebraucht erworbenen Austin Sportwagen.
>
> Muß sie eine schöne Stange Geld für die Aufbereitungen gekostet haben.
>

Genau das habe ich sie gefragt und war erstaunt, wie wenig das war.


> Aber sicher, solange es noch sinnvoll (!) machbar ist, sind Reparaturen
> einer Neuanschaffung vorzuziehen - sogar wenn sie teurer kommen, weil dafür
> einges an "unsichtbaren" Kosten (Dreck, Gesundheitsbeeinträchtigung,
> Belastungen) entfällt. Aber irgendwann ist dann eine Wiederverwertung der
> alten Teile doch sinnvoller.
>

Wir haben letztes Jahr bei einem Toyota Baujahr 1995 die Servolenkung 
erneuern lassen. Sie leckte ganz leicht. Das haette ich mit Leak Stop 
Spezial-Oel noch ein paar Jahre hinziehen koennen, aber wir haben vor, 
den Wagen mindestens weitere 20 Jahre zu fahren. Also knapp $1000 
reingesteckt und jetzt isser wieder fast wie neu. Bei meinem 
Gelaendewagen Baujahr 1996 hat sich bisher nichtmal eine Gluehbirne 
erdreistet, durchzubrennen.


>>>>>               ... das Laden allein dauert schon elend lange, ...
> ..
>> 15sec sind fuer mich jetzt keine Ewigkeit, zumal man ja immer auch was
>> anderes zu tun hat.
>
> Wenn Du das so siehst, i.O.
>
>>>> LTSpice weiss ich es nicht, es funktioniert nur unmittelbar nach
>>>> Installation und dann sehr gut. Nach jedem Re-Boot ist es weg, wird
>>>
>>> Vielleicht geht das bei einer Linux-Implementation?
>>
>> Tja, wenn es die denn gaebe :-(
>
> Von Spice gibt es Varianten, für die auch Linux-Implementationen
> existieren. Nachdem ich sowas bisher nicht notwendig gebraucht habe, kenne
> ich mich da aber nicht recht aus.
>

Es gaebe schon Alternativen, aber nicht mit "Behavioral Modeling". Dabei 
werden komplexe ICs mathematisch in ihren Eigenschaften simuliert, also 
nicht auf Transistor-Level. Es ist bei der Entwicklung von Schaltreglern 
oft die einzig gangbare Methode, da es sonst ewig dauert.


> ...
>>>> Das ist ja gerade der Pfiff. Ich habe zur Probe Simulationen mit
>>>> LTSpice unter WINE laufen lassen und die sind kaum langsamer als im
>>>> Windows-Boot
>>>
>>> What wonder - Software, die zu 90% rechenintensive Funktionen
>>> abarbeitet, die identisch laufen, ist "kaum langsamer" aufgrund der 10%
>>> Anzeige- und Bedienfunktionen. Da ist dann wohl das, was wirklich
>>> beeinflußt wird, um Faktoren >2 langsamer.
>>
>> Fast alle meine Software ist fuer rechenintensive Dinge. Vielleicht
>> begeistert mich WINE deshalb so.
>
> Ein Graphiker oder in verwandten Bereichen Arbeitender sähe das sicher
> anders. Sogar schon ein "Softwerker", wenn der speicherintensive Sachen
> bearbeitet. Und Speicherbedarf kann Dir auch Deine Simulationen versauen,
> wenn die nicht nur klitzeklein sind.
>

So mit 300-500MB kommen die aus und man kann das auch im RAM lassen.

Aber klar, wenn z.B. jemand unbedingt wettkampfmaessig Fortnite spielen 
muss, braucht der ganz anderes Kaliber.

>>> ...
>> Was ich noch rausfinden muss ist, wie man von WINE aus auf
>> Speicherbereicher ausserhalb von /.wine zugreift, vor allem auf das
>> Netzwerk. Fuer Dateien und so. Das haben andere jedoch schon geloest.
>>
>> https://fitzcarraldoblog.wordpress.com/2016/09/18/how-to-enable-a-windows-application-in-wine-to-access-a-samba-share-on-a-nas/
>
> Naja, ohne das jetzt angeschaut zu haben - ich würde das Samba-Share halt
> einfach auf ein passendes, vom "WINE-Programm" zugängliches Verzeichnis
> mappen und das darüber benutzen. (Wobei das NAS doch hoffentlich unter
> Linux läuft und dann auch NFS zur Verfügung stellen sollte...)
>

Es laeuft mit ArchLinux und hat bisher kein NFS, nur Samba. NFS ist fuer 
Anfaenger ziemlich komplex.


>>> ...
>>>>> Auch mit WINE wird der Aufwand nicht viel kleiner, ...
>>>>
>>>> Der Aufwand  war wesentlich kleiner. Rechtklick -> Install with WINE ->
>>>> Lizenz-File laden, Lizenz-Code eintippen -> feddich.
>
> Bis auf die eigentliche Arbeit...
>

Das Arbeiten mit der Software? Kein Problem, habe ich probiert und 
(bisher) keinen Unterschied zum Windows-Boot festgestellt.


>>>> Ja, allerdings muss ich noch herausfinden, wie man die Datenspeicherung
>>>> nicht ueber die emulierten Windows "Festplatten" macht, sondern z.B.
> ...
>>> Soweit ich WINE (noch) kenne, nutzt das keine "emulierten Festplatten",
>>> sondern einfach Links auf Verzeichnisbäume mit dem passenden Inhalt.
>>> Stz' Dir einfach 'n Link "e:" oder so in Dein ~/.wine/dosdevices, der
>>> auf ein Verzeichnis mit dem gewünschten Inhalt zeigt. Das kannst Du
>>> dann in dem Windows-Programm als "Laufwerk" "E:" benutzen.
>>
>> Danke, so aehnlich sollte es gehen.
>
> Kannst ja mal berichten, ob.
>

Mache ich. Doch erstmal muss ich die Linux-Kisten dazu ueberreden, Samba 
Shares und Windows Shares zu sehen. Dann noch einen WLAN Stick zum 
Laufen bringen, Unkraut zupfen, 15 Raummeter Holz stapeln, und so weiter.

> ...
>>> Unter Linux - auch mit WINE - solltest Du NTFS künftig _meiden_. Das ist
> ...
>> Nicht so einfach, da ich auch im Windows-Boot auf dieselben
>> Speicherbereiche muss. FAT32 ginge natuerlich auch, zumal ich keine
>
> Ok, das ist natürlich ein Ausschlußkriterium. FAT(32) ist da sicher die
> letzte Wahl...
>
>> Mit ArchLinux wuerde ich das natuerlich nicht versuchen, da ist derzeit
>> alles ext3 und FAT.
>
> Wenn das einigermaßen aktuell ist, sollte das genauso gehen. Kennzeichen:
> ntfs-3g und Fuse-Treiber (Fuse: File System in User Space).
>

Fuse habe ich versucht, hat es nicht gepackt. Das ganze ist eine 
ArchLinux Version fuer einen kleinen ARM Prozessor (Marvell Kirkwood 
800MHz). Macht aber nichts, mit ext3 laeuft ja alles. Wenn ich mal einen 
zweiten mit Festplatte zum Backup hinzusetze, muesste die ebenfalls 
umformatiert werden.


>>> [Sicherheit]
>>> Wobei der größte Gefahrenherd bei internet-Zugängen immer vor dem
>>> Bildschirm sitzt.
>>
>> Bei uns weniger, wir machen keine heiklen Sachen ueber Internet.
>
> Manchmal machen die heiklen Sachen die Betreiber der Sites...
> Da kann angeblich schon das Überfahren eines "Links" (natürlich nicht
> erkennbar gekennzeichnet) reichen, oder ein mitgeladenes Script macht das
> sowieso schon alles gleich beim Aufruf. Nur gut, daß sowas hauptsächlich
> auf Windows-Benutzer abzielt - aber man sollte sich auch als Linuxer nicht
> zu sicher meinen.
>

Stimmt, allerdings besuchen wir nur wenige Web Sites und meist immer die 
gleichen. Medien aller Art haben in unserem Haus einen geringen 
Stellenwert. Jedenfalls solange mir niemand die Western von YouTube 
abspenstig macht :-)

[...]

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#110520

On 12.05.20 22:48, Sieghard Schicktanz wrote:
> Die Nachteile sind: mit WINE wird ein dicker Klotz Software geladen, der
> viel Arbeitsspeicher kostet, ...

Hält sich eigentlich in Grenzen. So "fett" ist Wine gar nicht. Zumal das 
"Bibliotheks-Konzept" von Windows 1:1 umgesetzt ist. Wine ist zwar sehr 
groß aber nicht jede DLL wird für jedes Programm geladen.

>> Dann hat man die Container. WINE ist IMO eine der sehr praktischen
>> Aspekte von Linux.
> 
> WINE ist nichtmal eine Krücke, WINE ist der Rollstuhl, die Vorstufe zur
> Bettlägrigkeit.

An einzelnen Stellen kommt man um Wine nicht herum.

Man sollte es meiden wo immer möglich und Eagle unter Wine laufen 
lassen, wenn doch eine native Version verfügbar wäre, wäre für mich auch 
ein No-Go.

Allerdings wäre Eagle auf dem PC, an dem ich gerade tippe, schon 
prinzipiell ein No-Go weil es Closed-Source ist.

Gruß

Manuel

[toc] | [prev] | [next] | [standalone]

#110324

Joerg <news@analogconsultants.com> wrote:

 >Die Installation von Cadsoft Eagle Version 7.7.0 64-bit schlaegt fehl, 
 >weil es 32-bit Libraries braucht, warum auch immer. Leider schlaegt 
 >deren Nachladung ebenfalls fehl mit diesen Fehlermeldungen im Terminal:

Kann ich nix genaues zu sagen, aber ich hab eine alte 5.6er bei mir unter
64Bit Centos7.7 laufen. Und ja, man muss einiges nachinstallieren.

Ich hab mir das mal notiert:

yum install libstdc++-4.8.5-39.el7.i686
yum install libjpeg-turbo-1.2.90-8.el7.i686
yum install libpng12.i686
yum install libXi.i686
yum install libXft.i686
yum install libXcursor.i686
yum install libXrandr-devel.i686
yum install libXrender.i686
yum install glibc-2.17-292.el7.i686

Beim start wird eagle jedesmal eine neue fehlende Libarie anmeckern,
dann kann man mit diesem Kommando schauen in welchem Packet man sie
findet:

yum provides '*/libstdc++.so.6'


 >E: Couldn't find any package by regex 'libcrypto++9'

Hier sagt er dir ja auch schon was. Das musst du halt
Distributionsabhaengig loesen.

 >Muss man vorher irgendwelche Geheim-Repositories aktivieren oder 
 >sonstige Tricks benutzen?

Es reicht vollkommen aus zu lesen was dir das Programm mitteilt. .-)

 >Ich moechte von Autodesk unabhaengig bleiben und daher in Linux meine V7 
 >Lizenz weiterbenutzen.

Das versteht sich ja wohl von selbst.

Olaf

[toc] | [prev] | [next] | [standalone]

#110342

On 2020-05-08 21:18, olaf wrote:
> Joerg <news@analogconsultants.com> wrote:
>
>   >Die Installation von Cadsoft Eagle Version 7.7.0 64-bit schlaegt fehl,
>   >weil es 32-bit Libraries braucht, warum auch immer. Leider schlaegt
>   >deren Nachladung ebenfalls fehl mit diesen Fehlermeldungen im Terminal:
>
> Kann ich nix genaues zu sagen, aber ich hab eine alte 5.6er bei mir unter
> 64Bit Centos7.7 laufen. Und ja, man muss einiges nachinstallieren.
>
> Ich hab mir das mal notiert:
>
> yum install libstdc++-4.8.5-39.el7.i686
> yum install libjpeg-turbo-1.2.90-8.el7.i686
> yum install libpng12.i686
> yum install libXi.i686
> yum install libXft.i686
> yum install libXcursor.i686
> yum install libXrandr-devel.i686
> yum install libXrender.i686
> yum install glibc-2.17-292.el7.i686
>
> Beim start wird eagle jedesmal eine neue fehlende Libarie anmeckern,
> dann kann man mit diesem Kommando schauen in welchem Packet man sie
> findet:
>
> yum provides '*/libstdc++.so.6'
>

Also bei jedem Start geht das Gebastel los? Oh Graus, lieber nicht.


>
>   >E: Couldn't find any package by regex 'libcrypto++9'
>
> Hier sagt er dir ja auch schon was. Das musst du halt
> Distributionsabhaengig loesen.
>
>   >Muss man vorher irgendwelche Geheim-Repositories aktivieren oder
>   >sonstige Tricks benutzen?
>
> Es reicht vollkommen aus zu lesen was dir das Programm mitteilt. .-)
>

Ja, aber es scheint fuer einen Linux-Anfaenger was kompliziert zu sein. 
Ich habe dann doch die Windows Version mit WINE installiert, das 
flutschte problemlos durch, inklusive Lizenz und allem.

[...]

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#110344

Joerg <news@analogconsultants.com> wrote:


 >Also bei jedem Start geht das Gebastel los? Oh Graus, lieber nicht.

Quatsch. Eagle testet beim start ob eine Libary vorhanden ist und
bricht dann mit dem Hinweis darauf ab. Die musst du dann besorgen und
installieren. Beim naechsten start wird es dann eine andere Libary
anmeckern. Wenn du das 10-12x gemacht hast dann wird es danach starten
und das wird dann auf ewig so bleiben.
Das war insgesamt so 1h arbeit....

Noch ein Tip zum Drucken. Obwohl Eagle ja postscript erzeugt (ich
nutze den Camprozessor!) und ich einen Drucker mit integrierten
Interpreter habe, hat zumindest mein Centos beim ersten Druck die
Platine 1-2mm auf 100mm verkleinert.  Die Loesung bestand bei mir
darin anzugeben das ich DIN/A4 verwende:

lp  -o media=a4   

Das muss irgendwas was mit den verkorksten Amis und ihren
imperialistischen Massen zutun haben. :-) Auch wenn mich das
schwer wundert. Ich dachte bisher das Postscript ein brauchbarer
systemuebergreifender Standard sei.

> Ja, aber es scheint fuer einen Linux-Anfaenger was 
> kompliziert zu sein.

Die ganze Art mit Libaries umzugehen ist DIE grosse Leiche im Keller
der Programmierzunft. Das Problem existiert bei Windows und Linux
gleichermassen. Allerdings wird es bei Linux dadurch vergroessert das
es unterschiedliche Distributionen gibt die natuerlich das Problem in
ihrer jeweils eigenen Geschmacksrichtung haben. Und am schlimmsten, 
anstatt sich darum zu kuemmern das Problem richtig zu loesen hat 
man sich entschlossen die Scheisse in Container zu fuellen um so
alles vor Anwendern zu verstecken. Dein Problem als ahnungsloser
Anwender ist nun natuerlich das sich keiner die Muehe macht einen
Container (auspuck) fuer deine Linuxversion zu basteln.

Olaf

[toc] | [prev] | [next] | [standalone]

#110353

On 2020-05-09 23:13, olaf wrote:
> Joerg <news@analogconsultants.com> wrote:
>
>
>   >Also bei jedem Start geht das Gebastel los? Oh Graus, lieber nicht.
>
> Quatsch. Eagle testet beim start ob eine Libary vorhanden ist und
> bricht dann mit dem Hinweis darauf ab. Die musst du dann besorgen und
> installieren. Beim naechsten start wird es dann eine andere Libary
> anmeckern. Wenn du das 10-12x gemacht hast dann wird es danach starten
> und das wird dann auf ewig so bleiben.
> Das war insgesamt so 1h arbeit....
>

10-12x? Oh weia.


> Noch ein Tip zum Drucken. Obwohl Eagle ja postscript erzeugt (ich
> nutze den Camprozessor!) und ich einen Drucker mit integrierten
> Interpreter habe, hat zumindest mein Centos beim ersten Druck die
> Platine 1-2mm auf 100mm verkleinert.  Die Loesung bestand bei mir
> darin anzugeben das ich DIN/A4 verwende:
>
> lp  -o media=a4
>

Danke, aber ich mache keine Layouts, kontrolliere sie nur und aendere 
hie und da was an den ekligeren Punkten.


> Das muss irgendwas was mit den verkorksten Amis und ihren
> imperialistischen Massen zutun haben. :-) Auch wenn mich das
> schwer wundert. Ich dachte bisher das Postscript ein brauchbarer
> systemuebergreifender Standard sei.
>

Wir wollen hier ja schliesslich keine anti-imperialistischen Masse 
haben, wo kaemen wir hin :-)

Bei mir ist es manchmal umgekehrt. Der Drucker wirft nach dem Drucken 
einer Seite eine Fehlermeldung aus und eine gelbe Lampe leuchtet. 
Immerhin nicht die rote, also kann man ihn auch so weiterbenutzen. Das 
passiert meist bei Software aus dem EU Raum, wo DIN-A4 irgendwo 
festgeschrieben ist. Muss ich dann immer ueber Menue-Geklimper loeschen, 
damit die gelb LEDs ausgeht.


>> Ja, aber es scheint fuer einen Linux-Anfaenger was
>> kompliziert zu sein.
>
> Die ganze Art mit Libaries umzugehen ist DIE grosse Leiche im Keller
> der Programmierzunft. Das Problem existiert bei Windows und Linux
> gleichermassen. Allerdings wird es bei Linux dadurch vergroessert das
> es unterschiedliche Distributionen gibt die natuerlich das Problem in
> ihrer jeweils eigenen Geschmacksrichtung haben.


So wie ich das als Laie beobachte, wird das Problem dadurch groesser, 
dass zu vieles gemeinsam verwendet wird und man Dependencies bekommt. 
Dann passiert irgendwann mal ein Update und schon laefut eine aeltere 
Software nicht mehr richtig oder gar nicht mehr.


>                                         ... Und am schlimmsten,
> anstatt sich darum zu kuemmern das Problem richtig zu loesen hat
> man sich entschlossen die Scheisse in Container zu fuellen um so
> alles vor Anwendern zu verstecken. Dein Problem als ahnungsloser
> Anwender ist nun natuerlich das sich keiner die Muehe macht einen
> Container (auspuck) fuer deine Linuxversion zu basteln.
>

Da hoffe ich, dass die Popularitaet von MX-Linux gross genug wird, dass 
Container entstehen. Der MX-Installer hat extra Repository-Tabs zum 
Anklicken dafuer. Persoenlich finde ich Container sinnvoller und so hat 
man bei Windows ja auch so gut wie keinen Aerger, dass nach Updates was 
nicht funktioniert. Anfang der 90er soll das mit dll anders gewesen 
sein, aber da war Windows fuer mich qualitativ zu schlecht und ich blieb 
bis Anfang 1997 bei DOS.

Beim Laborrechner hatte ich einen seltsamen Effekt beider Installation 
von WINE. Ueber Synaptic installiert, lief sauber durch, fluppte aber 
nicht. Man konnte keine Windows Software installieren. Dann nochmal 
ueber den MX-Installer. Dabei wurde das erst-installierte WINE 
herausgeworfen und danach lief alles wie Sahne. Warum auch immer.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#110359

Joerg wrote:
[...]

>> anmeckern. Wenn du das 10-12x gemacht hast dann wird es danach starten
>> und das wird dann auf ewig so bleiben.
>> Das war insgesamt so 1h arbeit....
>>
> 
> 10-12x? Oh weia.

Einmalig, und dann läuft das.
Merkwürdig, die einfachen Sachen sind dir zu kompliziert und auf die
schwierigen stürzt du dich mit "wird schon schief gehen".
[...]
> So wie ich das als Laie beobachte, wird das Problem dadurch groesser, 
> dass zu vieles gemeinsam verwendet wird und man Dependencies bekommt. 
> Dann passiert irgendwann mal ein Update und schon laefut eine aeltere 
> Software nicht mehr richtig oder gar nicht mehr.

Das gibt es bei jedem System...Linux, Windows, macOS.

[...]
> Da hoffe ich, dass die Popularitaet von MX-Linux gross genug wird, dass 
> Container entstehen.

Darauf würde ich nicht warten.

> Der MX-Installer hat extra Repository-Tabs zum 
> Anklicken dafuer. Persoenlich finde ich Container sinnvoller

Nun, die Geschmäcker sind verschieden.

> und so hat 
> man bei Windows ja auch so gut wie keinen Aerger, dass nach Updates was 
> nicht funktioniert.

Bruuaaahhhh....gröhl...hust....

Ich glaube, da gibt es hier eine Menge Leute die anderes zu berichten
haben. Ein Beispiel: Vorletztes (?) Major-Update (eigentlich Upgrade)
von Windows 10: Oh, TCP/IP V6 ist kaputt gepatcht worden. Was soll's,
benutzt ja eh' keiner. Hauptsache V4 funktioniert.
Und schon war die Ka.... am dampfen, weil die neue Alarmierungssoftware
ohne IP V6 nicht läuft.

> Anfang der 90er soll das mit dll anders gewesen 
> sein, aber da war Windows fuer mich qualitativ zu schlecht und ich blieb 
> bis Anfang 1997 bei DOS.

Die DLL-Hell gab es auch noch später. Wenn die Programmierer oder
Schlipse nicht lernfähig sind, wird bis ultimo so weiter gemacht wie bisher.

> Beim Laborrechner hatte ich einen seltsamen Effekt beider Installation 
> von WINE. Ueber Synaptic installiert, lief sauber durch, fluppte aber 
> nicht. Man konnte keine Windows Software installieren. Dann nochmal 
> ueber den MX-Installer. Dabei wurde das erst-installierte WINE 
> herausgeworfen und danach lief alles wie Sahne. Warum auch immer.

Vielleicht solltest du mal eine weiter verbreitete Distribution versuchen.
Wer weiß, ob nicht wenigstens ein Teil deiner Probleme unter Debian oder
Fedora oder SuSE nicht auftauchen würde.

Michael

[toc] | [prev] | [next] | [standalone]

#110380

On 2020-05-11 01:19, Michael Brand wrote:
> Joerg wrote:
> [...]
>
>>> anmeckern. Wenn du das 10-12x gemacht hast dann wird es danach starten
>>> und das wird dann auf ewig so bleiben.
>>> Das war insgesamt so 1h arbeit....
>>>
>>
>> 10-12x? Oh weia.
>
> Einmalig, und dann läuft das.
> Merkwürdig, die einfachen Sachen sind dir zu kompliziert und auf die
> schwierigen stürzt du dich mit "wird schon schief gehen".


Wenn es keinen anderen Weg gibt, hacke ich mich mit der Machete durch. 
Etwa beim Hack eines Pogoplug, auf der nur eine bestimmte Version 
ArchLinux in spartanischer Ausstattung laeuft. Das war was knifflig, 
geht aber jetzt. Bei Eagle gab es hingegen den Weg des geringeren 
Widerstandes ueber WINE.


> [...]
>> So wie ich das als Laie beobachte, wird das Problem dadurch groesser,
>> dass zu vieles gemeinsam verwendet wird und man Dependencies bekommt.
>> Dann passiert irgendwann mal ein Update und schon laefut eine aeltere
>> Software nicht mehr richtig oder gar nicht mehr.
>
> Das gibt es bei jedem System...Linux, Windows, macOS.
>

So oft wie in einem Jahr Linux habe ich das noch nicht erlebt. Auch 
konnte man hier in der NG lesen, wie es auch hartgesottene Experten 
erwischte, die sich drueber aergerten.


> [...]
>> Da hoffe ich, dass die Popularitaet von MX-Linux gross genug wird, dass
>> Container entstehen.
>
> Darauf würde ich nicht warten.
>
>> Der MX-Installer hat extra Repository-Tabs zum
>> Anklicken dafuer. Persoenlich finde ich Container sinnvoller
>
> Nun, die Geschmäcker sind verschieden.
>
>> und so hat
>> man bei Windows ja auch so gut wie keinen Aerger, dass nach Updates was
>> nicht funktioniert.
>
> Bruuaaahhhh....gröhl...hust....
>
> Ich glaube, da gibt es hier eine Menge Leute die anderes zu berichten
> haben. Ein Beispiel: Vorletztes (?) Major-Update (eigentlich Upgrade)
> von Windows 10: Oh, TCP/IP V6 ist kaputt gepatcht worden. Was soll's,
> benutzt ja eh' keiner. Hauptsache V4 funktioniert.
> Und schon war die Ka.... am dampfen, weil die neue Alarmierungssoftware
> ohne IP V6 nicht läuft.
>

Ok, ich meine jetzt die "guten" Windows Versionen. NT4, Win2k, XP und 
Win7. Alles andere habe ich ausgesessen und Win10 mache ich nicht mit.


>> Anfang der 90er soll das mit dll anders gewesen
>> sein, aber da war Windows fuer mich qualitativ zu schlecht und ich blieb
>> bis Anfang 1997 bei DOS.
>
> Die DLL-Hell gab es auch noch später. Wenn die Programmierer oder
> Schlipse nicht lernfähig sind, wird bis ultimo so weiter gemacht wie bisher.
>

Hmm, nie erlebt.


>> Beim Laborrechner hatte ich einen seltsamen Effekt beider Installation
>> von WINE. Ueber Synaptic installiert, lief sauber durch, fluppte aber
>> nicht. Man konnte keine Windows Software installieren. Dann nochmal
>> ueber den MX-Installer. Dabei wurde das erst-installierte WINE
>> herausgeworfen und danach lief alles wie Sahne. Warum auch immer.
>
> Vielleicht solltest du mal eine weiter verbreitete Distribution versuchen.
> Wer weiß, ob nicht wenigstens ein Teil deiner Probleme unter Debian oder
> Fedora oder SuSE nicht auftauchen würde.
>

MX ist auch auf aelterer HW brauchbar und kommt der gewohnten 
Windows-Umgebung sehr nahe. Ich bleibe jetzt dabei, man muss sich ja mal 
entscheiden. Anfangs hatte ich Lubuntu, aber das war fuer mich nicht 
stabil genug.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#110374

Mahlzeit!

Joerg <news@analogconsultants.com> wrote:

[paketierte vs. containerisierte Software]

> So wie ich das als Laie beobachte, wird das Problem dadurch groesser, 
> dass zu vieles gemeinsam verwendet wird und man Dependencies bekommt. 
> Dann passiert irgendwann mal ein Update und

… man hat eine Sicherheitslücke auf einen Schlag direkt in allen
nutzenden Paketen gefixt.  Grau-en-haft ;-)

(Siehe auch der Snap-Thread, der gerade läuft)

Gruß
Christian
-- 
....Christian.Garbs....................................https://www.cgarbs.de
What could possibly go wrong?

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | de.comp.os.unix.linux.misc

csiph-web