Beiträge von gandro

  • Pre-Release: siginfo-ng 0.2.0pre5 mit Lua-Support (Update: 08.März.2011)

    Fürs Protokoll: Die Portabilität ist ggf. doch nicht so übel wie befürchtet, hab siginfo-ng ohne Änderung im Quellcode statisch kompiliert gekriegt, auf Basis der dietlibc.

    Man muss die dietlibc zwar für libm patchen, damit es mit Lua läuft, und Lua selber braucht auch einen Einzeiler-Patch, dann läufts aber und man kriegt ein statisch gelinktes Binary, ohne jegliche Abhängigkeiten (anders als das alte siginfo-ng, was mit der glibc auch nicht komplett statisch kompilieren konnte, wegen DNS), und das ganze Programm ist nur 254 KBytes gross (inklusive HTTP und Lua).

    Einzig io.popen() von Lua wird rausgeschmissen, weil "posix" ein zu generisches Target für Lua ist. Das kann man aber bestimmt wieder reinholen.

    Nachtrag: Das mit popen ist Blödsinn, das ist drin wenn man POSIX macht. Man muss es nur auch nutzen.

    Werd mir das was überlegen, wie man das etwas automatisieren kann.

  • Die große Retro-Diskussion mit Gästen!

    HTML programmiert man nicht.

    Und: HTML hat valide zu sein, dann gibts keine Probleme. Selbst IE8 besteht Acid2, das reicht für 90% aller statischen Webseiten da draussen, dann braucht man sich das auch nicht in allen 300 Browsern testen.

    Der IE bis und mit Version 7 zeigt HTML falsch an. Der IE8 richtig, führt aber dazu, dass all die vielen kaputten firmen-internen HTML-Seiten mit den IE8 nicht mehr richtig aussehen, daher die Kompatibilitätsansicht, die das alte Verhalten emuliert.

  • Pre-Release: siginfo-ng 0.2.0pre5 mit Lua-Support (Update: 08.März.2011)

    Wie schon angekündigt, hab ich siginfo-ng praktisch von Grund auf neu geschrieben, jetzt mit Lua für Plugins, anstelle statisch einkompilierter C-Funktionen.

    Beitrag

    Präsentiere: siginfo-ng 0.1

    *push*

    Das Plugin-Framework von siginfo-ng 0.1 an sich ist ein bisschen unpraktisch, abgesehen davon, dass Blue-Fox und Blue, afaik die beiden einzigen die noch bisschen daran rumbasteln, nur C-Basiskenntnisse haben, ist es mühsam, die Binary jedes mal neu zu kompilieren für andere Plugins.

    Ich hab mir überlegt, das ganze Pluginsystem mit dynamischen Libraries zu machen (.so-Dateien über dlopen() und Co), das gibt allerdings viel zu tun, und macht im Grunde nichts einfacher, im Gegenteil, nur…
    gandro
    23. Juli 2010 um 18:42

    Ich bin allerdings mit der Plugin-Architektur noch nicht so ganz zufrieden, daher veröffentliche ich meinen Status-Quo (der abgesehen vom noch nicht zufriedenstellenden Plugin-System aber robust sein sollte) als Pre-Release. Das Ding bietet nicht alle Features der 0.1.xer-Serie, ist daher viel mehr zum ausprobieren und Feedback geben gedacht, wie man dass dann in der "finalen" 0.2.0er machen soll.

    Dokumentation ist praktisch nicht existent zur Zeit. Für Plugins gilt grundsätzlich folgendes:

    Es sind gewöhnliche .lua-Dateien, die an sich keine besonderen Anforderungen erfüllen müssen. Diese werden von siginfo-ng geladen und ausgeführt. Alle aus sicht des Plugisn globalen Variabeln befinden sich allerdings in einer separaten Table, und können in der Config-Datei dann so angesprochen werden. Beispiel:

    Code
    -- Datei "plugin.lua"


local tmp = 21
illuminaten = tmp + 2


function random()
    return math.random(0, 100)
end

    Lädt man diese Datei in der Konfigurationsdatei (config.lua) mit load_plugin("plugin", "plugin.lua"), dann kann man in der Konfigurationsdatei im Layout diese wie folgt verwenden:

    Code
    siginfo.layout = {} -- neues, leeres Layout
siginfo.layout.row1 = { "Zahl der Illuminaten: ", plugin.illuminaten }
siginfo.layout.row2 = { "Zufallszahl: ", plugin.random }

    Während plugin.tmp via Konfigurationsdatei nicht ansprechbar ist. Hoffe, das ist einigermassen verständlich.

    Problem an der Architektur ist, dass zwar ständig ändernde Werte möglich sind (siehe plugin.random, diese Funktion wird bei jedem Update frisch aufgerufen), aber das bei vielen kleinen Werten sehr mühsam wird (siehe mem.lua). Daher wäre ich um Feedback froh.

    Auch ein ungelöstes Problem ist es, wie und wo man die Plugins lädt. Zur Zeit gibt es in der Config-File zwei Funktionen: load_plugin(ns, file) und load_plugin_dir(file), erstere lässt einem bestimmen, wie das Plugin angesprochen wird, zweitere lädt einfach alle Plugins in einem Verzeichnis und gibt ihnen den Dateinamen als Namespace.

    Grundsätzliche Lua-Kenntnisse sind allerdings schon von nöten, daher empfehle ich folgende Seiten:
    Lua für Anfänger: Lua fr Anfnger
    Programming in Lua (Buch, englisch): Programming in Lua, Second Edition
    Lua 5.1 Sprachrefrenz (englisch): Lua 5.1 Reference Manual - contents

    Der Rest sollte einigermassen fertig sein. HTTP-Support wurde komplett überarbeitet und fehlerbereinigt, auch wenn der HTTP-Parser nicht immer ganz standardkonform arbeitet, so reicht es wenigstens für siginfo.de. Die Portabilität wird vorerst etwas zurückgegangen sein, weil ich 2-3 POSIX-Funktionen mehr verwendet habe, und sogar eine GNU-Funktion, auf einem Linux mit dynamischer glibc wird es aber funktionieren. Während statisches reinkompilieren des Lua-Interpreteres unter
    Arch zwar funktioniert hat, aber das Binarie danach nich lief. Daher auch Pre-Release.

    Download wie immer auf GitHub: gandro's siginfo-ng at master - GitHub

  • Ankündigung: Neue Regeln

    Zitat von niwax

    Darf man im UIT jetzt "bla" posten?


    Nein. Jetzt eben nicht mehr.

    Im alten Text war die Spam-Regel vom OT ausgenommen, das was implizierte, dass man gemäss Regeln im OT unbeschränkt hätte spammen dürfen, obwohl die Rubrikbeschreibung das klar verbietet.

    Mit der neuen Regel jetzt darf im OT nicht mehr unbeschränkt gespamt werden, sondern nur noch in einem gewissen Toleranzbereich.

  • Rapidshare Free-User Shellscript 4.0

    Tut mir leid, aber ich kann den Bug nicht reproduzieren. Gerade nochmals ne Liste mit 4 Links erfolgreich durchrattern lassen, hat alles gelöscht.

    Dafür, dass er den Link nicht löscht, fallen mir nur zwei Erklärungen ein: Entweder wurde die Datei nicht richtig heruntergeladen (wget Rückgabewert != 0), oder die Linkliste wurde bearbeitet, während das Script bereits am laufen war.

    Die dritte Erklärung wäre, dass ich nen Fehler im sed escaping gemacht habe, aber das trifft nicht zu, wenn der Link beim zweiten Mal (wo doppelt eingetragen) dann doch gelöscht wurde.

    Dass die Links doppelt gelöscht werden, wenn doppelt vorhanden, ist überigens korrekt.

  • Rapidshare Free-User Shellscript 4.0

    Die Idee find ich gut, hab sie eingebaut. Link ist der alte, Version ist aber jetzt 3.2

    Folgende Veränderungen:
    - Consume-Modus, der alle erfolgreichen Downloads aus der Input-Datei löscht. Bitte beachten: Editiert man während dem Download die Datei und fügt neue Links ein, werden diese trotzdem ignoriert! Das lässt sich mit Dateien nicht so einfach machen, dazu müsst ihr schon mit mkfifo ne Named-Pipe oder sowas in der Art verwenden.
    - Der Paste-Modus ist wieder da. Wenn man jetzt keine URL oder Input-File angibt, kann man URLs von Hand reinkopieren und mit CTRL+D (EOF) den Download starten.
    -Desweiteren eine Art Bugfix, dass er Dateinamen nicht mehr doppelt in die MD5SUMS reinschreibt, was bei Premium-Resume-Downloads recht nervig sein konnte.

  • Präsentiere: siginfo-ng 0.1

    *push*

    Das Plugin-Framework von siginfo-ng 0.1 an sich ist ein bisschen unpraktisch, abgesehen davon, dass Blue-Fox und Blue, afaik die beiden einzigen die noch bisschen daran rumbasteln, nur C-Basiskenntnisse haben, ist es mühsam, die Binary jedes mal neu zu kompilieren für andere Plugins.

    Ich hab mir überlegt, das ganze Pluginsystem mit dynamischen Libraries zu machen (.so-Dateien über dlopen() und Co), das gibt allerdings viel zu tun, und macht im Grunde nichts einfacher, im Gegenteil, nur vieles komplizierter, dafür müsste nur nicht mehr so oft kompilieren.

    Daher ist mein Gedanke, einen Lua-Interpreter in siginfo-ng 0.2 einzubauen. Würde heissen: Man schreibt Plugins zukünftig nicht mehr in C, sondern in Lua. Dessen Standard-Bibliothek kann zwar nur wenig mehr als Dateien und Prozesse öffnen und Strings parsen, aber für 95% der existierenden Plugins machen ja genau das.

    Das coole an Lua ist, dass es wirklich überall läuft (überall wo ANSI-C läuft, also wirklich überall) und nicht zwingend eine Abhängigkeit darstellt, da man die ganze Sprache inkl. Standardbibliothek direkt ins Binary mit einkompilieren kann, sind nur rund 120KB.

    Vorteil ist: Man kann Plugins als Scripte schreiben, zur Laufzeit laden, muss nur einmal kompileren und hat ne einfachere Programmiersprache.

    Frage ans Publikum ist jetzt daher, ob die Leute, die siginfo-ng nutzen bzw. daran basteln, Interesse haben das einzubauen, oder ob sie lieber mit dem alten statischen C-Müll bleiben wollen, daran werd ich aber in naher Zukunft nichts tun.

  • Ankündigung: Neue Regeln

    Gab ein paar wenige Updates:

    • Signaturregel wurde überarbeitet, es gibt jetzt eine maximale Höhe.
    • Avatarbeschränkungen gelöscht, weil es da eh technische Blockaden gibt.
    • Crossposting ist jetzt offiziell verboten.
    • Wir dürfen jetzt auch ganz offiziell temporär sperren.
    • Kleinere sprachliche Fehler korrigiert.

    Geänderte Passagen:

    Spoiler anzeigen

    Die alte Version ist auf GitHub noch vorhanden.

  • [gelößt] WOL Problem mit Realtek 8139 Onboard

    Zitat von Dirk

    Generell empfehle ich den Treiber direkt von Realtek, den hier kann man unter Erweitert einiges einstellen, u.a. MUSS der sinnlose Punkt "Wake on Lan herunterfahren" aktiviert sein.


    Ist überigens zwar eine irreführende Bezeichnung, aber nicht ganz sinnlos: Die meisten Karten machen nur WOL, wenn sie beim Herunterfahren vom Treiber dazu aufgefordert werden.

    Darum funktioniert WOL bei den meisten Rechnern auch nicht, wenn man den PC nicht ordnungsgemäss runterfährt.

    Nachtrag: Du hast ihn zwar damals gelesen, aber für alle anderen mit WOL-Problemen habe ich ja vor paar Monaten auch mal nen recht allgemeinen Beitrag dazu verfasst:

    Beitrag

    WOL - Wake on Lan per PCI?

    Ich hab in einer Firma als Praktikant mal den Auftrag gehabt, bei über 200 Rechnern Wake-on-LAN zu aktivieren.

    Folgende Erkenntnisse:

    1. Das Board muss entweder so ein WOL-Anschluss haben oder PME (Power Management Events, ab PCI 2.2) unterstützen. PME muss man im BIOS desöfteren aktivieren, "PME Enable" oder "Wake up on PCI" oder ähnliches unter "Power "Management". Fürs Kabel muss man es auch aktivieren. Das BIOS muss wissen, dass es die PCI-Karte mit Strom versorgen muss (manchmal auch…
    gandro
    8. Februar 2010 um 21:36

  • Das Ende für Windows 2000

    Zitat von adun


    Wie hast du den patch für NT 5.0 gemacht?
    möchte das selbe für win2k machen


    Weil freaked und die ganzen Nachfolgeposten das offenbar falsch verstanden haben: adun fragt danach (@Eddie), wie man die Sicherheitslücke in einem nicht-gemoddeten Windows 2000 patcht, und nicht wie man nen Windows-Mod macht.

  • YAFU Fehler

    1. yafu1 ist nicht mehr supported, wenns nicht läuft, verwende ein anderes Script. Nachfolger gibts (noch) nicht.
    2. strex hat richtig erkannt, dass ich yafu1 damals für Apache geschrieben habe, für andere Server muss man mindestens die Rewrite-Rules umschreiben, wenn nicht mehr.
    3. Ich meine, yafu lief zwar unter Windows (Alex hatte das doch mal in Betrieb), das war aber vor einigen Versionen, kann gut sein, dass das inzwischen nicht mehr will. Hängt vermutlich auch von PHP-Einstellungen und anderem ab, aber Windows-Support könnte ich da nicht mal geben, selbst wenn ich wollte.

    Lange Rede kurzer Sinn: Probier ein anderes Script, selbst wenns läuft hat yafu einige unbehobene Fehler.

  • Ein paar Impressionen von Office 2010 Starter

    Dass das Teil nur auf Vista läuft ist doch ganz klar: Das Teil ist nur für OEMs gedacht, als Ersatz für MS Works zum vorinstallierten auf Rechner. Als Endbenutzer hat man da nichts verloren.

    Selbst wenn es noch Rechner mit vorinstallierten XP gibt (was ich nicht glaube), dann hat Microsoft hat kein Interesse, dass die noch Verbreitung kriegen.

    Nachtrag: An sich find' ich das auch eine gute Idee. Besser jedenfalls als das nutzlose Works und die dämlichen Office-60-Tage-Testversionen. MIt denen konnte keiner was anfangen, mit nem Office Starter hingegen wird der eine oder andere, der nicht mehr als fünf Word-Dokumente im Jahr bearbeiten muss, dann doch glücklicher.

    Nachtrag 2: Englische Wikipedia meint sogar, man kann das Teil auf nen USB-Stick kopieren. Das fänd ich ja mal sehr leet.

  • Nutzt ihr 64-Bit Anwendungen?

    Im überigen sind Pointer bei 64bit nicht zwingend immer 64bit gross, AMD hat bei AMD64 programm-counter-relative Adressen eingeführt, so dass man relative "Pointer" verwenden kann, die nicht die vollen 64bit ausfüllen müssen.

    Gerade standardmässiges SSE bringt dem Compiler einiges bei nicht-optimierten Standard-Anwendungen, und da läuft 64Bit dann auch im Einzelfall signifikant schneller.