Ich habe darüber nachgedacht, die Verwendung von GNU Coreutils auf meinen Linux-Systemen einzustellen, aber um ehrlich zu sein, kann ich mir im Gegensatz zu vielen anderen GNU-Komponenten keine Alternativen vorstellen (unter Linux) . Welche Alternativen gibt es zu GNU Coreutils? Benötige ich mehr als ein Paket? Links zum Projekt sind ein Muss, Bonuspunkte für die Benennung von Distributionspaketen.
Schlagen Sie außerdem nur dann Dinge vor, wenn Sie wissen, dass sie unter Linux funktionieren, und wenn Sie Anweisungen nachschlagen können. Ich bezweifle, dass ich bald den Kernel wechseln werde, und ich bin viel zu faul für alles, was weit über eine einfache Sache hinausgeht ./configure; make; make install
. Ich werde C sicher nicht dafür hacken.
Warnung: Wenn Ihre Distribution Coreutils verwendet, können diese die Funktionsweise Ihrer Distribution beeinträchtigen. Wenn Sie sie jedoch nicht an erster Stelle haben, $PATH
sollten Sie die Dinge nicht kaputt machen, da die meisten Skripte absolute Pfade verwenden sollten.
Antworten:
busybox
der Favorit von Embedded Linux-Systemen.Sie können so ziemlich jeden coreutil-Namen als Link zur busybox-Binärdatei definieren, und es wird funktionieren. Sie können auch laufen
busybox <command>
und es wird funktionieren. Beispiel: Wenn Sie auf Gentoo sind und Ihrvi
noch nicht installiert haben, können Sie ausführenbusybox vi filename
und Sie werden in vi sein. Es istArch Linux - Community / Busybox
Gentoo Linux - sys-apps / busybox
Alpine Linux - basierend auf BusyBox und uClibc, hier eine Übersicht
quelle
Dies ist ein älteres Thema, das ist mir klar. Diese Lösung wurde jedoch nie erwähnt und taucht bei Google für "Linux with bsd userland" relativ häufig auf.
Es gibt eine andere Lösung: Erbstück. Ich weiß, dass es auf Arch funktioniert und in der AUR gepackt ist (siehe zum Beispiel gnu2sysv). Dadurch wird das Coreutils-Paket von Arch ersetzt und das Gegenstück zum Erbstück bereitgestellt. Sie können über das Ganze im Wiki von arch lesen: https://wiki.archlinux.org/index.php/Base2heirloom
quelle
Schauen Sie sich Uutils an .
Dies ist eine plattformübergreifende Implementierung der in Rust geschriebenen GNU-Coreutils. Es ist MIT-lizenziert. Zum Zeitpunkt des Schreibens dieser Antwort ist sie noch nicht vollständig (einige wichtige wie
ls
und fehlencp
), aber viele andere sind bereits erledigt.quelle
Ich vermute, es würde Ihnen schwer fallen, GNU Coreutils loszuwerden. Es gibt jedoch immer die entsprechenden BSD-Tools, obwohl es sich nicht um Ersatz für die GNU-Tools handelt.
quelle
Wenn jemand von etwas Abstand nehmen möchte, das auf vielen Plattformen häufig verwendet, getestet und verifiziert wird, ist dies in der Regel ein äußerer Ausdruck eines zugrunde liegenden Problems, das als "Codegeruch" bezeichnet wird, und der unkontrollierten Anhäufung von "technischer Verschuldung" oder "Code" Schuld". Das GNU-Archiv hatte im Laufe der Jahre eine ziemlich große Menge an Code-Schulden aufgebaut, und wenn eine Codebasis nicht richtig gepflegt wird, kann sie einen Bruchpunkt erreichen (Legacy-Code und sogar krankhafter Legacy-Code).
Normalerweise würde man in regelmäßigen Abständen ein Re-Engineering und Refactoring durchführen, um dies unter Kontrolle zu halten. Die eigentliche Frage, die hier gestellt wird, ist, ob eine überarbeitete Version von coreutils entwickelt wurde. Dies beinhaltet natürlich die Möglichkeit eines direkten Ersatzes (als Sonderfall) - ähnlich wie Wayland für X aufgestellt wird ... viele seiner Entwickler kommen direkt aus dem X-Camp.
Mein Vorschlag ist, tatsächlich Coreutils zu refaktorieren. Jemand muss es tun. Und wer auch immer das Problem des Austauschs von coreutils aufwirft - Ihre Idee, Ihr Projekt.
Nutzen Sie zu diesem Zweck die Automatisierung, die Sie finden können: Refactoring-Engines wie cscout oder alles, was fortgeschrittenere Analyse- / Synthesemethoden (z. B. formale Konzeptgitter) anwendet. Die Tiefenanalyse ist jedoch noch ein relativ neues und offenes Gebiet der aktiven Forschung - und geht in die künstliche Intelligenz über. (Ein Robotersoftware-Ingenieur.)
Die meisten Dienstprogramme sollten bereits über Testsuiten verfügen, sodass die Validierung mit schrittweisen Änderungen und automatisierten Regressionstests erfolgen kann. Das kann ziemlich schnell gehen (zB 10 oder mehr Revisionsupdates / Tag). Eine Komplikation dieses Vorgangs tritt auf, wenn irgendwo in der Softwaresuite Hardware- oder Softwareabhängigkeiten auf niedriger Ebene vorhanden sind. da dies die Validierung auf mehreren Plattformen mit sich bringt. Ich weiß nicht viel darüber in coreutils; Es sollte eine gewisse Trennung von der Hardware- oder der Low-Level-Software-Schicht bestehen (z. B. die Anzahl der Stellen, an denen coreutils weiß, welcher Typ vorliegt)Das Dateisystem, auf dem es sich befindet, sollte mindestens oder besser null sein.) Für Emulatoren und virtuelle Maschinen, die zum Testen auf mehreren Plattformen verwendet werden, gelten Einschränkungen. Zum Beispiel wurde Mac OS X speziell dafür entwickelt, die Emulation oder VM-Fähigkeit zu beeinträchtigen.
quelle
Solaris (ab svn_140-something) wäre ebenfalls eine Option.
Wenn Sie eine Distribution verwenden, sind Sie verrückt. Hör jetzt auf. Suchen Sie psychiatrische Hilfe auf.
Wenn Sie LFS verwenden , rocken Sie weiter! Habe Spaß!
Wenn Sie eine Distribution machen, begrüße ich Ihren tapferen Herrn.
quelle