Jeg har tenkt på å avvikle bruken av GNU Coreutils på Linux-systemene mine, men for å være ærlig, i motsetning til mange andre GNU-komponenter, kan jeg ikke «t tenk på eventuelle alternativer (på Linux) . Hvilke alternativer er det til GNU coreutils? trenger jeg mer enn en pakke? Lenker til prosjektet er et must, bonuspoeng for å navngi distro-pakker.

Ikke vær så snill å foreslå ting med mindre du vet de fungerer på Linux, og kan referere til instruksjoner. Jeg tviler på at jeg snart vil bytte kjerne, og jeg er for lat til noe som er mye mer enn en rett ./configure; make; make install. Jeg kommer absolutt ikke til å hacke C for det.

advarsel: hvis distroen din bruker kjernefysiske verktøy, kan du fjerne dem slik at distribusjonen fungerer. Hvis du ikke har dem først i $PATH, bør du ikke bryte ting, ettersom de fleste skript bør bruke absolutte baner.

Kommentarer

  • Merkelig, hvorfor ser du etter alternativer?
  • @xeno » Mer robust »
  • @xeno Debian bruker nå faktisk EGLIBC , som en slags gaffel med GLibC. Men det følger GLibC nøye, så forskjellen er ‘ t så stor.
  • Både Clang og tcc kunne (samtidig, uansett) kompilere Linux-kjernen.
  • Det er folk som jobber med et GNU-brukerland på en BSD-kjerne , men jeg har ikke ‘ t hørt om omvendt. Det ville være enklere å bytte kjerner. Du kan prøve det først i en VM hvis du ‘ er sjenerte.

Svar

busybox favoritten til Innebygde Linux-systemer.

BusyBox kombinerer små versjoner av mange vanlige UNIX-verktøy i en enkelt liten kjørbar. Det gir erstatninger for de fleste verktøyene du vanligvis finner i GNU fileutils, shellutils, etc. Verktøyene i BusyBox har generelt færre alternativer enn deres fulle GNU fettere; alternativene som er inkludert, gir imidlertid forventet funksjonalitet og oppfører seg veldig som deres GNU-kolleger. BusyBox gir et ganske komplett miljø for ethvert lite eller innebygd system.

BusyBox er skrevet med størrelsesoptimalisering og begrensede ressurser i tankene . Det er også ekstremt modulært, slik at du enkelt kan inkludere eller ekskludere kommandoer (eller funksjoner) på kompileringstidspunktet. Dette gjør det enkelt å tilpasse de innebygde systemene dine. For å lage et fungerende system, er det bare å legge til noen enhetsnoder i / dev, noen få konfigurasjonsfiler i / etc og en Linux-kjerne.

Du kan stort sett få et hvilket som helst coreutil-navn til å være en lenke til binær travelbox, og det vil fungere. du kan også kjøre busybox <command>, så fungerer det. Eksempel: Hvis du «er på Gentoo og ikke har installert vi ennå, kan du kjøre busybox vi filename og du vil være i vi . Det «s

Kommentarer

  • modifiser dette gjerne med lenker til distro
  • også, dette er en favoritt på innebygd, så selv om det ‘ sannsynligvis ikke kommer til å være nok å erstatte GNU for skrivebords- / servermiljøet mitt
  • Dette er den eneste praktiske løsningen atm, hvis du ikke ‘ ikke vil hacke C. Og opptaksboksversjoner bør være ganske standard i samsvar.

Answe r

Dette er et eldre tema, skjønner jeg. Denne løsningen ble imidlertid aldri nevnt og kommer relativt høyt opp på google for «Linux med bsd brukerland».

Det er en annen løsning: arvestykke. Jeg vet at det fungerer på Arch, og det er pakket i AUR (se for eksempel på gnu2sysv). Dette vil erstatte Arch «s coreutils-pakke og gi arvestykkeekvivalenter. Du kan lese om det hele på arch» s wiki: https://wiki.archlinux.org/index.php/Base2heirloom

Svar

Sjekk ut verktøy .

Dette er en plattformimplementering av GNU coreutils som er skrevet i Rust. Det er MIT-lisensiert.Når dette svaret skrives, er det ikke 100℅ komplett (mangler noen viktige som ls og cp), men mange andre er ferdig.

Svar

Jeg mistenker at du «ville ha vanskelig for å bli kvitt GNU Coreutils, men det er alltid de likeverdige BSD-verktøyene, selv om de ikke er erstatningserstatninger for GNU-verktøyene.

Kommentarer

  • hvordan vil jeg gå frem for å installere BSD verktøy på en Linux-distro? hvor skulle jeg få dem?
  • FreeBSD ‘ hele operativsystemet er tilgjengelig via CVS freebsd.org/cgi/cvsweb.cgi/src , men å få BSD-brukerlandet til å kompilere under en Linux-kjerne vil være ganske vanskelig. GNU ‘ s brukerland er trolig mer bærbar enn BSD, siden GNU ‘ s brukerland (i det minste i begynnelsen) ble bygget for å være bærbart mellom flere kjerner.
  • det høres ut som ea PITA, sikker på om det ‘ er rimelig mulig noen et sted har pakket det minst en gang for linux.
  • Solaris (fra og med 140-noe er også tilgjengelig) ville også være et alternativ. Hvis du bruker en distro, er du gal. Stopp nå. Hvis du bruker LFS , fortsett! Ha det gøy! Hvis du lager en distro, applauderer jeg tapperheten din.
  • Ja, jeg ‘ er ikke sikker på at det ‘ til og med mulig. Det ‘ ville sannsynligvis være lettere å bare installere FreeBSD og aktivere linux-kompatibilitet. Du kan enkelt få GNU-kjernemutlene til å fungere under FreeBSD, men ikke omvendt.

Svar

Vanligvis, når noen ber om å komme vekk fra noe som er i utbredt bruk, velprøvd, verifisert på mange plattformer, er det et ytre uttrykk for et underliggende problem kjent som «kodelukt» og den ukontrollerte akkumuleringen av «teknisk gjeld» eller «kode gjeld». GNU-arkivet hadde opparbeidet seg en ganske stor mengde kodegjeld gjennom årene, og når en kodebase ikke vedlikeholdes ordentlig, kan den nå et bristepunkt (eldre kode og til og med sykelig eldre kode).

Normalt , ville man gjennomføre en prosess med omprosjektering og refactoring med intervaller for å holde dette under kontroll. Så det virkelige spørsmålet som stilles her er om det er utviklet en omformet versjon av coreutils. Dette inkluderer selvfølgelig muligheten for en direkte erstatning (som et spesielt tilfelle) – omtrent som Wayland blir satt opp for å være for X … mange av utviklerne som kommer rett ut av X-leiren.

Mitt forslag er å faktisk gå inn og refaktorere kjernefysiske verktøy. Noen må gjøre det. Og den som tar opp spørsmålet om å erstatte coreutils – ideen din om prosjektet.

For dette formål, dra nytte av hvilken automatisering du kan finne: refactoring motorer, som cscout, eller noe som gjelder mer avanserte analyse / syntesemetoder (f.eks. formelle konseptgitter). Men dyp analyse er fortsatt et relativt nytt og åpent område for aktiv forskning – og krysser over i kunstig intelligens. (En robotprogramvareingeniør.)

De fleste verktøyene bør allerede ha testserier på plass, så validering kan gjøres med progressive trinnvise endringer + automatiserte regresjonstestetrinn; som kan gå ganske raskt (f.eks. 10 eller flere oppdateringsoppdateringer / dag). En komplikasjon til denne prosessen oppstår hvis det er maskinvare eller programvareavhengigheter på lavt nivå hvor som helst i programvarepakken; siden det innebærer validering på flere plattformer. Jeg vet ikke mye av det som er i kjernefysiske stoffer. Det bør være en slags separasjon i den fra maskinvaren eller programvarelag på lavt nivå (f.eks. Antall steder der kjernefysiske deler vet hva type av filsystemet det er på, bør være minimalt eller bedre, null.) Emulatorer og virtuelle maskiner, som brukes til å utføre testing på flere plattformer, har begrensninger. For eksempel er Mac OS X spesielt designet for å hindre evnen å etterligne eller VM det.

Svar

Solaris (fra og med svn_140-noe) vil også være et alternativ.

Hvis du bruker distro, er du gal. Stopp nå. Søk psykiatrisk hjelp.

Hvis du bruker LFS , rock on! Ha det gøy!

Hvis du lager en distro, applauderer jeg tapperheten din.

Kommentarer

  • dette er ikke ‘ et spørsmål om » hvilken distro » kan jeg bruke, det

    handler om å erstatte coreutils på Linux. Med mindre du ‘ henviser til opensolaris coreutils? er dette også mindre PITA enn FreeBSD-alternativet?

  • Kildekoden for OpenSolaris er bare Solaris. Solaris-kildekoden frem til svn_14x ble utgitt av Sun / Oracle under CDDL. Det er i utgangspunktet tre hovedarv for Unix brukerland.» Genetisk » Unix (Solaris, AIX, True64, etc., som kom fra AT & T-kode og er stort sett lukket, men Solaris var åpen en stund), BSD (som til slutt sto på den ‘ sin egen fra 4.4-lite) og GNU. Men jeg tror at det å flytte vekk fra GNU vil være like vanskelig (eller enkelt) uansett om du går med BSD eller Solaris. Eller du kan bli veldig ambisiøs og lage xenocore-verktøy 😉

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *