Trojaner in Delphi programmiert

Für alles, was in den übrigen Lazarusthemen keinen Platz, aber mit Lazarus zutun hat.
mse
Beiträge: 2013
Registriert: Do 16. Okt 2008, 10:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
CPU-Target: x86,x64,ARM

Re: Trojaner in Delphi programmiert

Beitrag von mse »

Bei mir ist die Firefox Binary in /usr/lib/firefox, in /usr/bin ist lediglich ein Link.
Systemweite unterschiedliche FPC Installation funktionieren nach dem gleichen Prinzip, die Dateien sind in /usr/lib/fpc/<version>.
Zuletzt geändert von mse am Mi 15. Nov 2017, 14:34, insgesamt 1-mal geändert.

Warf
Beiträge: 1908
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: Win10 | Linux
CPU-Target: x86_64

Re: Trojaner in Delphi programmiert

Beitrag von Warf »

Timm Thaler hat geschrieben:Wieso gehst Du eigentlich automatisch davon aus, dass ich Windows für das bessere System halte? Du versuchst zu beweisen, dass Linux besser ist, weil Windows scheisse ist. Einigen wir uns doch mal darauf, dass in Windows auch ganz viele Dinge scheisse sind, z.B. die Registry, die verkackte Rechteverwaltung... und lassen das mal so stehen.


Falls ich geschrieben habe das Windows scheisse ist, war das als Witz gemeint (falls es dir nicht aufgefallen ist, das ist ein Runninggag der Unix Community für die letzten 20 Jahre. Ich dachte das wäre bekannt), nur weil ich keine positiven Features von Windows erwähne Heist es nicht das es keine gibt.

Warf hat geschrieben:Als Nutzer der sich einen scheiß um alles kümmert (also wenn ich mal nicht programmiere) finde ich auch Windows besser als Linux.


Wär doch ziemlich dämlich wenn ich ein System bevorzuge was ich offensichtlich scheiße finde

Timm Thaler hat geschrieben:Selbst wenn es Windows nicht gäbe: Warum zum Henker muss ein Programm wie der Firefox genauso behandelt werden wie ls?

Wird es nicht.

Warf hat geschrieben:Außerdem gehören in den bin Ordner keine Programme, sondern nur die Binares, bzw. Softlinks auf die Binares. Das tatsächliche Anwendungsverzeichnis findet sich meist im lib oder share Ordner. Ein Beispiel, der FPC wird normalerweise in /usr/local/share abgelegt und lediglich ein SymLink wird dann in /usr/local/bin abgelegt. /usr/bin ist damit also mehr wie das Windows Startmenü als der Programme Order. Das hat den Grund das das Workingdirectory unter Unix nur selten dem Ort der Binary entspricht (im Gegensatz zu windows, wo ein anderes Working directory eher die ausnahme darstellt), der Ort an dem die Executeable liegt ist daher herzlich irrelevant, und die Pfade müssen sowieso hardcoded werden (oder configfiles).


Timm Thaler hat geschrieben:Natürlich hätte man, anstatt alle Binaries in ein Verzeichnis zu kübeln dedizierte Programmverzeichnisse schaffen können, in denen alle Bestandteile der Programme liegen, einschließlich der Sources und Manuals, und dann über Symlinks die Binaries aufrufen. Stattdessen sind, wenn ich ein Programm installiere die Programmteile in ettlichen Verzeichnissen verteilt, wobei nichtmal klar ist nach welchen Kriterien jetzt in welches Verzeichnis verteilt wird. Oder sich die Installation halt nicht dran hält, aber das scheint Uses zu sein.



Warf hat geschrieben:Außerdem gehören in den bin Ordner keine Programme, sondern nur die Binares, bzw. Softlinks auf die Binares. Das tatsächliche Anwendungsverzeichnis findet sich meist im lib oder share Ordner. Ein Beispiel, der FPC wird normalerweise in /usr/local/share abgelegt und lediglich ein SymLink wird dann in /usr/local/bin abgelegt. /usr/bin ist damit also mehr wie das Windows Startmenü als der Programme Order. Das hat den Grund das das Workingdirectory unter Unix nur selten dem Ort der Binary entspricht (im Gegensatz zu windows, wo ein anderes Working directory eher die ausnahme darstellt), der Ort an dem die Executeable liegt ist daher herzlich irrelevant, und die Pfade müssen sowieso hardcoded werden (oder configfiles).


Um das mal klarer zu machen, fast alle Programme die Ressourcen verwenden (z.B. LLVM, FPC, Firefox, etc.) haben ein eigenes Programmverzeichnis in entweder PREFIX/lib oder PREFIX/share. Tipp mal ls -l /usr/bin | grep '>' | wc -l in deine Shell ein, ist die zahl der Dateien die nur als Symlink in /usr/bin sind. Bei meiner Suse sind das fast 1/3 aller Dateien in /usr/bin. (und wenn man davon ausgeht das die Utility Programme die absolute Mehrheit ausmachen ist das doch eine gute Quote)

Timm Thaler hat geschrieben:Zum Beispiel wurde mal behauptet, für Programme externer Anbieter gibt es /opt. Das nutzt aber nur und ausschließlich Wolfram Alpha konsequent. Ich hab zwar LibreOffice runtergeschmissen, aber ich würde behaupten, dessen Binaries standen genauso in /usr/bin wie die von Firefox, Geany, Gimp und dem alsamixer. Und nix Symlinks, hier stehen die konkreten Binaries drin.


Das stimmt, opt ist ein Relikt aus einer Zeit vor dem Aufschwung des Personal Computers. Aus einer Zeit in der /usr alle Dateien enthält die Rechner unabhängig zwischen vielen Rechnern geteilt wurde, /usr/local war für die selbstkompilierten Programme und /opt für Drittanwendungen. Wenn jetzt allerdings der größte teil der User nicht mehr selbst kompiliert, und verschiedene Rechner sich eher selten im Privatgebrauch /usr teilen, ist natürlich die frage was es bringt Anwendungen in /opt zu installieren, wenn in /usr/local nur 1-2 wenn überhaupt drin sind, weil einfach kaum noch wer selbst kompiliert.

Timm Thaler hat geschrieben:Wie doof das ist merkst Du spätestens, wenn Du mal versuchst verschiedene Versionen von Lazarus und FPC parallel zu betreiben. Über das Repo gehts schon gar nicht, und von Hand musst Du sie ins Home-Verzeichnis installieren. Konzept?


Warf hat geschrieben:Außerdem gehören in den bin Ordner keine Programme, sondern nur die Binares, bzw. Softlinks auf die Binares. Das tatsächliche Anwendungsverzeichnis findet sich meist im lib oder share Ordner. Ein Beispiel, der FPC wird normalerweise in /usr/local/share abgelegt und lediglich ein SymLink wird dann in /usr/local/bin abgelegt. /usr/bin ist damit also mehr wie das Windows Startmenü als der Programme Order. Das hat den Grund das das Workingdirectory unter Unix nur selten dem Ort der Binary entspricht (im Gegensatz zu windows, wo ein anderes Working directory eher die ausnahme darstellt), der Ort an dem die Executeable liegt ist daher herzlich irrelevant, und die Pfade müssen sowieso hardcoded werden (oder configfiles).


Damit geht das kinderleicht. Neue fpc Version, einfach irgendwo hin installieren (bei mir nach /developer wenn mehr als ein Nutzer sonst ~/developer) und die Symlinks von ppc-XXX in /usr/local/bin austauschen und fertig. Das ist kinderleicht, und super gut durchdacht, und nur dank dem Dateisystem von Unix so einfach möglich.

Unter windows ist das allerdings ne echte Qual Immer den PATH anzupassen, da der bei mir mittlerweile so lang geworden ist, das jede Änderung erst mal minutenlanges suchen braucht

Timm Thaler hat geschrieben:Doch, hab ich gelesen.

Wenn ich mich selbst 4 mal Zitieren kann um deine zum Teil schlicht weg falschen aussagen zu beantworten, bezweifele ich das einfach mal stark

Antworten