Doch, habe ich!Glaube, du hast die letzten Beiträge nicht richtig gelesen oder?
Wenn 563MB ein Problem sein sollten dann nehme ich halt meine 1MB große Runtime (übrigens ohne LP2_DevX.sfs als Abhängigkeit)! Das Standard-Gambas.sfs nehme ich jetzt erst mal aus Bequemlichkeit. Du siehst es gibt immer mehrere Wege die auch sinnvoll sind.
Ob nun 563 MB, 40 MB oder 1 MB. Ein Vergleich mit der Größe der anzuzeigenden Konfigurationsoberfläche -nach Deinen Angaben im anderen Post: 9KB- zeigt doch schon den ganzen Irrsinn.
1 MB = 1024 KB
Somit ergeben 1024 KB : 9 KB das 113,777-fache an benötigtem Speicher!
Eine komprimierte Skriptdatei einer Größe von 10 KB ist (laut meinem gerade durchgeführten Versuch) exakt 207 Bytes groß!
Somit belegt ein 1 MB großes komprimiertes Programm-Modul das 4946,859903-fache an Speicherplatz des Skriptes, um das es eigentlich geht!
Obendein bezweifle ich, daß Deine Konfigurationsoberfläche, angelegt als Bash/GtkDialog Skript eine Größe von 9 KB erreichen würde; wohl allenfalls ein paar wenige hundert Byte, womit sich das Ganze wohl in einem Bereich des 100.000-fachen bewegen dürfte, der sich wiederum noch einmal erhöht, wenn man den Speicherplatz der entpackten Daten des 1 MB großen Programm-Moduls als Grundlage zur Berechnung heranzieht!
Da fällt mir Deine letzte Anfrage ein, ob ich nicht die bei der Startskripterzeugung automatisch eingefügten Kommentare am Anfang und am Ende jedes Startskriptes (wohl so um die 10 Zeilen Text), die ja immerhin auch Dich als Ideengeber für die Startskripte sowie z.B. sunburnt (für seine Hilfe durch Codebeispiele etc) und auch shinobar (für seine Übernahme meines Vorschlages der zu der Option --skip-fixmenus führte) als Mitwirkende benennt, entfernen könnte - um Speicherplatz zu sparen!
Schlußendlich wenn Du Dich nun noch auf eine tage-, wochen- oder gar monatelange Suche nach einer aktuelleren Version von Gambas begibst, dann steht doch der Aufwand zum Ergebnis in keinem vernünftigen Verhältnis mehr! Und es wird auch dadurch nicht besser, wenn Du hunderte oder gar tausende solcher Konfigurations-GUIs auf diese Art erstellen würdest!
Die Vernichtung einer Galaxie zur Erhaltung eines Kometenfragmentes wäre um einiges mehr verständlich und nachvollziehbar!
Code: Select all
Ist doch gut, wenn aus meiner Idee und meinem ersten Programm verschiedene Erweiterungen entstehen! Das zeigt doch nur, wie genial das grundsätzliche Konzept ist!
Exakt, man kann nicht alles haben - aber Du könntest!Ich arbeite mit meiner eigenen, ursprünglichen Version. Da habe ich beim Booten über mein ConfigMaster mehr Kontrolle was genau geladen wird und alles was ich brauche, speziell auch für Notebooks habe ich im Griff!
Meinen Ansatz die Konfiguration über scripte für jede Komponente zu starten finde ich nach wie vor besser! Bisher gibt es nur den Nachteil, dass meine Scripte erst nach dem kompletten Bootvorgang laufen und dein System eben schon am Anfang! Die Einstellungen am Anfang zu machen wäre natürlich günstiger aber man kann halt nicht alles haben
Das von mir aktualisierte System Deines PhyTechL, verfügt ja bereits über alles, was ich hier in meiner LazY Puppy 3 Version habe und verwende.
Natürlich steht es Dir frei, Deinen Ansatz für das Konfigurationsmodul, 'besser' zu finden. Jedoch gerade Dir als Pädagoge sollte bewußt sein: 'besser finden' ist in absoluter Vollkommenheit subjektiv!
Nachdem ich gestern mal wieder spaßeshalber mein altes Lucid 525 gestartet habe (an dem ich vor LazY Puppy arbeitete), viel mir auf, daß alle Puppies ja über etwas verfügen, das es in LazY Puppy schon seit ewigen Zeiten nicht mehr gibt: das Save-Icon auf dem Desktop, welches ja zu einer Funktion führt, die wiederum jene Dateien, die in der Speicherdatei landen (sollen) speichert. Das führte mich zu dem Skript /usr/sbin/snapmergepuppy - welches wiederum ebenfalls aus rc.shutdown aufgerufen wird, nachdem rc.shutdown alle Optionen zur Einstellung der Größe und des Dateisystems der Speicherdatei offerierte.
Wenn man einmal den ganzen notwendigen Kram zur Erstellung der Speicherdatei sowie des Dateisystems innerhalb der Speicherdatei (incl. der ganzen Überprüfungen nach vorhandenem Speicherplatz etc.pp.) außer Acht läßt, dann reduziert sich die Funktion von Barry Kaulers snapmergepupy Skript auf exakt das, was ich hier bei der Erstellung meines Konfigurationsmoduls ausführe: das Kopieren von Dateien aus pup_rw!
Einziger Unterschied:rc.shutdown in LazY Puppy, Zeile 757 wrote:/usr/sbin/snapmergepuppy /initrd/pup_ro1 /initrd/pup_rw
Ich kopiere die Dateien in ein eigenes Verzeichnis und sortiere Verzeichnisse und Dateien durch vordefinierte Listen aus; das Skript snapmergepuppy hingegen verwendet das Verzeichnis pup_ro1 (das im Livebetrieb immer leer ist und in dem später die Speicherdatei steckt, wenn eine verwendet wird) und Verzeichnisse sowie Dateien werden über diverse Funktionen, also reinen Bash-Code, aussortiert (was sicher die bessere, weil umfassendere Lösung darstellt, was die Verwendung unter unterschiedlichen Hardwarebedingungen betrifft).
Aber auch diesen Code werde ich noch knacken und dann leite ich die Ausgaben/Aktionen von snapmergepuppy (dann lazysnapmergepuppy) in meine eigenen Verzeichnisse um - et voila!
Gruß,
Rainer