Beiträge von hjs

    Eine SSD ist auch um Größenordnungen schneller. Und am PCIe habe ich bisher noch nie eine angeschlossen. Es ist nach wie vor durchaus gängig dafür SATA zu nehmen.

    Und eine nvme ist wiederum um Grössenordnungen schneller als eine SSD via Sata.


    Was gängig ist, ändert sich ja durchaus im Laufe der Zeit ;) und wenn ich mir den Markt ansehe, gehen z.B. die "besseren" NB mehr und mehr in Richtung nvme oder nvme+HDD, wir sind also beim Ändern. Ob ich allerdings ne nvme im VDR einsetzen würde ... wohl eher nicht, wäre sinnfrei, es sei denn es kommt mir aud ein paar Sekunden Boot-Up-Time an, bzw bei Softdecodern mit X und pipapo sinds denn auch mal n paar Sekunden mehr, keine 5 Sekunden für "on" bis "Gui" natürlich WAF förderlich ;)


    Zurück zum Thema: Bei USB Sticks hab ich schon so unangenehme Erfahrungen gemacht, dass ich eher nen CF am Adapter nehmen würde :)


    Generell würd ich eine wie auch immer angeschlossene SSD favorisieren mit Blick auf Preis/Leistung/Sicherheit .


    HJS


    Na ja, ehrlich gesagt ist auch bei mir alles semi-automatisch. Ich habe ein kleines tool in c geschrieben, was die jeweils aktuelle html Seiten der LFS-dev per wget holt, parsed und bash scripte erstellt.

    Bin mittlerweile auf den tarball umgestiegen und bei mir machens halt die Herren sed, awk und die Dame grep :)


    Zitat

    Ich hab nochmal reingeschaut, auf dem server sollte ein komplettes LFS-dev vom Mai inklusive der build-scripte liegen (der Ordner 'bash_scripts'). Wenns bei irgendwo hakt, kannst du dort schmulen. ;)

    Immer sinnvoll. Thx :)

    Zitat

    Die Scripte dort entpacken, patchen und bauen und räumen auf, so dass sich alles problemlos wiederholen lässt, wenn mal was schief läuft. Einige scripte sind von Hand editiert, wenn der Parser 'Mist' gebaut hat.

    Leider stelle ich häufig fest, dass der Parser nur den Mist baut, den der Programmierer zulässt, bzw zwischen den Ohren hat :rolleyes:


    Abba weil sich das ja leider nicht immer vermeiden lässt, gedenke ich ja auch SVN-Tarballs weiterhin "im Sortiment" zu führen.


    Mal davon abgesehen, dass man keinen Parser auf die Änderungen der nächsten Jahre einstellen kann, das musste auch jh feststellen ( falls er noch gelegentlich drüber schaut, hat ja auch schon lange keine neue Version mehr rausgelassen, war abba ja bisher auch nicht nötig, seit libelf schon.


    Schön, dass Andere denn gleichen Weg gehen und auch straucheln, das beruhigt ungemein :) :gap


    HJS


    Meine 60GB SSD im Vdr ist ca. 2 Jahre alt. Die war am Anfang für 1/2 Jahr in einem Windows PC verbaut. Auf die Platte wurden in den 2Jahren ca. 2TB geschrieben. Ohne regelmäßiges Trim wäre die Platte vermutlich schon tot.


    Ernsthaft? Nach statistisch 30maligem Beschreiben jeder Zelle stirbt ne SSD ? Glaubste nicht wirklich oder ? Wenn das der Fall wäre, wäre die derzeit zum hjslfs-build benutzte nvme , mit Build auf 30GB ( immer die gleichen ) auch schon ziemlich tot.


    HJS

    ..auf deinem ftp liegt noch eine komplette LFS stage1, die erst ein paar Wochen alt ist.

    kannste mal sehen, wie oft ich in Dein Verzeichnis auf Meinem Server schaue :gap


    Hatte auch gar nicht mehr damit gerechnet, dass Du noch mal n Upload machst.


    Hats dann also doch noch funktioniert - fein - Thx


    Die Version, die mal angekommen ist, hatte ich mir angesehen, aber mich dann doch entschieden, Zähne zusammen beissen und durch.


    Hatte leichte Probleme mit dem Handling und enweder alles händisch regeln oder n neues Script schreiben.


    Da ich ja letztlich gerne meinen Weg weiterfahren wollte, haben meine Kronen halt leiden müssen :gap


    Aber vielen Dank. Könnt ich ja debian nach dem nächsten Kollaps wieder wechwerfen und n schönes LFS nehmen :)


    Irgendwann zwischendurch hab ich denn auch mal erkannt, warum sowohl Du als auch jh den untar und rmsrc nicht in die Scripte packen. Als lfs kann das ziemlich nervig und nur mit hohem Aufwand automatisierbar werden.


    Den untar übernimmt weiterhin das Buildscript, den rmsrc macht das Masterscript, da bin und bleib ich root.


    Derzeit fahre ich den Host als lfs, den Rest zwangsweise als root : ich fands schon erstaunlich, das


    Code
    1. su - lfs -s <script>

    im Host klappt, im system dagegen nicht.


    Wie oben bereits erwähnt, werden die Fehlermeldungen i Ch6 immer rarer, der Weg zum vollständig einsatzfähigen Build ist nicht mehr weit.


    Dann noch ch7&8 abhaken und die nötigen tools ergänzen, um das Ding zur CD, mittlerweile wohl eher DVD zu machen, um auch wieder mal nen aktuellen Host anbieten zu können.


    HJS

    Ächz, langsam kommt Licht ins Dunkel ...


    Nachdem ich nun endlich den Grund für permanente Bauchlandungen bereits in gcc-pass1 stage2 heraus gefunden habe ( die Parameterübergabe bei Aufruf eines Scriptes mit der gleichen Bash Instanz funktioniert als root nicht mehr, lt Debian-aktivem Kollegen vor Ort haben die Jungs dort viel an der "Sicherheit" geschraubt ?!? ) muss ich nur noch meine Denkfehler und die Tücken des Parsens bewältigen .


    - Erstaunlich, dass Dialog bei Verwendung von Umlauten eines anderen Zeichensatzes schlicht den Dienst verweigert

    - Erschreckend, dass eine Parameterzuweisung die von ´04 bis ´13 funktionierte, bestenfalls einen Fehlermeldungshagel verursacht, dann weiss man wengstens, dass was nicht passt

    - Übelst, dass man, durch Dauerfehler begünstigt, Messages im web Glauben schenkt, mit vielen gängigen Distris sei der Build von gcc wegen "unresolved symbols" bzw Header-Fehlern nicht möglich und man eine Distri nach der Anderen checkt und kickt - weil der Fehler wie erwähnt an ganz anderer Stelle liegt.

    - Dumm gelaufen, dass beim configure als root von coreutils die Message kommt, man möge den "unsafe configure" per Parameter erlauben, aber kein Hinweis, dass dies auch beim make nötig wäre, um so unscheinbare tools wie env auch zu bauen.

    - ganz Dumm gelaufen, wenn man zwar weiss, dass die Parameterübergabe nich mehr geht wie früher, aber leichtfertig statt in /mnt/lfs in / chrootet und dann selbstverfreilich seinen Host zum hangup und anschliessend beim reboot zur kernelpanic verurteilt, dezent geschrottet :rolleyes:


    Die Litanei will ich nicht fortsetzen, ist zu lang und interessiert vermutlich keinen.


    Aber gibt es da draussen jemanden, der mit erklären kann, inwiefern es unsecure ist, die coreutils und _TAR_ als root zu bauen ? Insbesondere bei _TAR_ ??


    Naja, viel Gesabbel, noch n bisschen biegen hier und schubsen dort, dann wirds ne 1.7 geben.

    Anfangs nur mit dem Nachladen der vorbereiteten Buildscripte wie bisher und nur LFS.


    Ziel der Dev-Runde ist die Option laden der jeweiligen SVN-Build-Tarballs oder Downloads des Books (wenn ich mal wieder anderweitig beschäftigt bin und der Buildtarball nicht online ist z.B.) und die Generierung der Buildscripte direkt aus dem Book, auch für BLFS ( das wird sicher noch lustig und ne Weile dauern :gap )


    HJS

    Musste nur meine ersten Cds dünne halten und auf max 65 MB begrenzen, seither mit der Domain anfangs 10, derzeit glaub ich 20 GB.


    Kost mich in der teuren Schweiz derzeit knapp 90 jährlich, das gönn ich mir :)


    BN/PW haste in der 4-Augen-Ecke


    HJS


    Gebaut wird immer parallel auf allen maximal möglichen Kernen, die i7-7700T x86_64 hat.


    Deshalb acker ich ja grad, hab z.Zt. nen i7-7700HQ mit ner nvme zur Nutzung :]

    Da geht was, wenn ich denn mal endlich was lauffähiges hinkrieg, denk ich über nen Hexacore mit ner WD Black nach, im bezahlbaren Rahmen derzeit wohl optimal, zumal ich noch ner Filemaker App MySQL/PHP näherbringen muss.

    Daher muss ich mit dem LFS mal langsam zu Potte kommen, die andere Geschichte wird besser bezahlt und n fms leidet auch nich unter was Zügigem.


    HJS

    Immer das bei mir aktuell noch laufende LFS, z.Z. ist mein vdr ein LFS-dev vom 08.02.2017.

    War bis zur grossen Pause bei mir auch so, aber die Anforderungen sind nu halt zu hoch für das alte Sys

    Ich generiere daraus dann immer halb-automatisch build-scripte lade mit wget die Pakete dazu herunter.

    Das mach ich nu schon (annähernd fehlerfrei) vollautomatisch


    Ich hab zum letzten Build noch alle sourcen, bash scripte und die tool chain.


    mit tool chain meinst Du den Host, also den vorherigen Build oder schon den statischen /tool ?

    Wäre interessant, habe zwar parallel gesehen, dass auf sourceforge tatsächlich ein inoffizieller LFS-8.0-LiveCD-Build verfügbar ist und den mal pauschal gezogen,


    Allerdings wäre natürlich der Vergleich meine Scripte / Deine Scripte vielleicht auch sehr aufschlussreich :gap , wobei ich schon ziemliche Gurkenscheiben auf den Augen haben müsste, um so gravierende Fehler der Scripte nicht zu erkennen ( bis gcc-pass2 isses ja nich weit ).

    Mal davon abgesehen, machen auch die ausgeliehenen jhalfs Scripte ne Bauchlandung und sehen meinen ziemlich ähnlich ...


    Haste nen ftp im Einsatz ?


    HJS

    Jo, abba die Post is spät dran


    Irgendwie treibt mich der Host zur Weissglut :§$%


    Egal was ich anstelle, spätestens bei gcc-pass2 ist das Ding gelaufen, 64bit host oder 32, Debian, manjura oder wie das Vieh hiess, Slax ( also auch Debian ) oder auch mein letzter erfolgreicher Build, gemäss prerequisites aufgepeppt ( ich bilde mir ein, es sei alles drin :rolleyes: )


    Auf nem Quadcore, Dualcore, Singlecore, jhalfs zur Hilfe, in ner VM ... streng nach Book ( als LFS, nich wie ich das typischerweise handhabe als root ) ...


    Wenn die letzte LFS_Live CD nicht so dermassen asbach wäre, dass man minnigens einen Zwischenbuild fahren müsste, und hoffen, die alten Sourcen noch alle zu erwischen ...

    Irgendwie ist mir nach :wand


    wirbel : Welchen Host nimmst Du eigentlich, wenns Dich mal wieder reitet ?


    HJS

    Immer diese frommen Wünsche :gap


    Mittlerweile durfte der Compiler wieder schaffen, aber ob der langen Abstinenz ist ihre Gottheit mir nicht mehr wirklich wohl gesonnen :rolleyes:


    Da mir die diversen Fehler auf unterschiedlichen Hosts irgendwann mal suspekt vorkamen, hab ich mal jhalfs angestrengt.


    Zumindest wusste ich auf die Art, dass auch wirklich alle nötigen Packages im Host installiert sind.


    Leider hat auch jhalfs fürs aktuelle development n Kleinen und nen grossen Kinken eingebaut.


    efitools builden wollen, aber gettext auspacken ist nicht hilfreich, weiss ich aus Erfahrung :gap


    Ihm unter die Arme greifen führt zu einem Ergebnis, dessen Ursache ich noch nicht ganz erfasst habe ...


    Naja, lange Rede kurzer Sinn, bin tatsächlich mal wieder am Ball ...


    HJS


    Die (Nutz-)Gartensaison is weitestgehend Geschichte.
    Könnte also demnächst mal wieder etwas mehr Zeit für die Scripte haben.
    Hat sich ja einiges getan - wenn ich die Ursache für die drei "Abweichler" im autoscript finde ( generiert aus dem Book die Buildscripte ) dann is auch mal wieder Arbeit für den Compiler angesagt ...


    HJS



    Tjo - war doch noch etwas mehr als nur drei Abweichler :rolleyes: und irgendwie hat man ja auch mal "Winterferien" , abba auch wenn die Gartensaison schon wieder losgeht : Bin guter Hoffnung ... :gap --- nee nich schwanger


    HJS

    das es dich noch gibt. ich hoffe es geht dir gut.


    vdr-box



    Sicher gibts mich noch - Unkraut vergeht nicht !


    Analog dazu isses ja bekannt, dass es schlechten Menschen immer gut geht :)


    Die (Nutz-)Gartensaison is weitestgehend Geschichte.
    Könnte also demnächst mal wieder etwas mehr Zeit für die Scripte haben.
    Hat sich ja einiges getan - wenn ich die Ursache für die drei "Abweichler" im autoscript finde ( generiert aus dem Book die Buildscripte ) dann is auch mal wieder Arbeit für den Compiler angesagt ...


    HJS

    Och Jungs - ich fand einfach die Stylemäßige Positionsangabe witzig .
    Ob Dieser oder Jener besser über oder unter der Erde aufgehoben ist/wäre liegt wie üblich im Auge des Betrachters .


    Ansonsten hat man Humor oder auch nicht - gleich welchen Levels - auch das liegt im Auge des Betrachters ;)


    HJS