For os der engang opdagede UNIX og "Software Tools" som en forfriskende simpel tilgang til en computer, er det hårde tider efterhånden.
Software Tools ideen er at man skal have en værktøjskasse fuld af programmer som kan kobles sammen.
Det modsatte af Software Tools er i store træk "MS Office", en stor plamage af kode der kan en millard ting.
Man skal imidlertid ikke være ret god til kombinatorik for at gennemskue en milliard er et trivielt lille tal i forhold til hvad /usr/bin på et ordentligt UNIX system kan kombineres til.
Det har Microsoft naturligvis set, det er derfor de har boltet programmeringssprog ind i MS Office, så man kan lappe de huller i funktionalitet, som deres egen begrænsede fantasi har efterladt.
At kunne sammenkobler programmer frit har en omkostning, de skal f.eks kunne forstå hinanden, hvilket i den klassiske UNIX situation blev klaret ved at alting var tekstfiler.
For lang tid siden begyndte jeg at overveje om Software Tools overhovedet kunne virke, som ide, med noget som helst andet format.
Kan Software Tools der arbejder på XML eller JSON overhovedet bruges til noget ?
Svaret på dét spørgsmål, er formodentlig halvdelen af svaret på det mere fundamentale spørgsmål: Har Software Tools nogen fremtid (mere) ?
Et sted Software Tools styrer for vildt er GnuRadio, hvor man kan koble alle mulige DSP klodser sammen til lige nøjagtig det signalbehandlingsbehov man har:
I den modsatte grøft har vi SystemD, hvor større og større dele af Linux's userland proppes ned i den ene og samme MS-Office-agtige super-daemon.
Fra nytår 2019 til nytår 2020 voksede antallet af kodelinier i SystemD med 10% - igen.
Med tæt på 1.3MLOC er SystemD nu for alle praktiske formål kerne#2 på et Linux system.
Her er det værd at erindre at Andy Tannenbaum i sin tid "dumpede" Linus for at skrive en monolitisk kerne, han argumenterede, som mange andre på den tid, for at kernen burde brydes op i mindre dele der hver gjorde en ting godt[1].
På tidens hardware var der et konkret overhead ved den nødvendige kommunikation mellem delkomponenter og derfor vandt den monolitiske kerne, til trods for at kloge folk allerede den gang påpegede at det ville vi fortryde når paralllel computere engang blev mere udbredte og før eller siden en nødvendighed[2].
Hvis man argumenterer for en monolitisk kerne med nogle fagter i luften og henvisning til performance, hardware-abstraktion og sikkerhed, har man naturligvis ikke moralsk højde til at argumentere imod en tilsvarende monolitisk tilgang til at håndtere skift i system-tilstande og isolering af root-privilegiet generelt set.
En af fiduserne ved Software Tools er at programmøren kan skrive et værktøj færdig, tage sin hat og slentre videre i livet.
Med store programmer sker der det præcis modsatte, de bliver aldrig færdige, tværtimod, væksten bliver et mål i sig selv, for det er den eneste måde for de involverede at bevare job og avancementmulighederne.
Kerne#1 er 21 gange større end Kerne#2, men Kerne#2 vokser 3.5% hurtigere end Kerne#1, så det vil indsnævres.
F.eks når kerne#2 bruger sin nær-monopol-status til at møve sig ind på markedet for boot-kode, eller beslutter sig for at diktere hvorledes hjemmekataloger skal håndteres.
I må have mig undskyldt, men jeg synes at Linux ligner Microsoft alt for meget efterhånden...
phk
[1] Hans eget forsøg på dette i Minix var ikke ligefrem et fantastisk eksempel at starte fra, den havde tre nogenlunde veldefinerede subsystemer og så en fjerde der med rette blev omtalt som "resten".
[2] Det er tankevækkende at overveje hvorledes verden ville se ud, hvis AMD's Zen arkitektur ikke spildte sine serielle kanaler på at simulere en "single-view" memory-model, men i stedet havde brugt dem til en blændende hurtig IPC mekanisme i "Transputer" stil, med hardware routing og authentikering.
En helt subjektiv forskel på systemd og MS Office: Jeg har stadig til gode at møde nogen som ikke hader systemd. Office er der få som elsker, men man lærer at leve med det. Det klarer opgaverne, og er ikke til debat på arbejdspladsen.
Antallet af kodelinier i systemd er direkte skræmmende, med tanke på hvad man ellers kan udrette på den plads.
Med tæt på 1.3MLOC er SystemD nu for alle praktiske formål kerne#2 på et Linux system.
Det linieantal du henviser til er jo ikke bare kode. Tallet inkluderer dokumentation, oversættelser af tekst, hardwaredatabsen, service filer, osv. Den egentlige kode er tæt på 1/3 af det tal du angiver.
Størrelsesmæssigt er systemd sammenlignelig med f.eks. X serveren eller wifi clienten og langt langt mindre end 3d koden i mesa. Størrelsen på systemd er ikke nogen sensation.
Jeg forstår udemærket den pointe du prøver at lave, men det tal du gør til omdrejningspunkt for din artikel er ikke sagligt.
Så vidt jeg ved / kan læse mig til så fungerer pipes i PowerShell ved at mellem processerne overføres der objecter - ikke tekstlinjer. Jeg har ikke sat mig ind i detaljerne (bruger sjældent Windows), men for mig lyder det som om at man kan få små rekombinerbare softwarekomponenter til at snakke sammen om andet end tekstlinjer.
Jeg tror ikke at en sådan fremgangsmåde egner sig til "intern deltajeret OS-drift" (i mangel af bedre navn), for der er det ikke tekstlinjer/objekter/gulerødder som bliver sendt mellem programmerne, men nærmere notifikationer.
Hvis din pointe/spørgsmål er om man kan konstruere det som små programmer, så vil jeg mene at det i mange tilfælde er muligt, og for det meste ønskeligt. Det interessante er når der er delproblemer som ikke kan løses sådan, eller performer for dårligt. Der vil de religiøse fanatikere insistere på at blive ved med små programmer, mens pragmatikerne kigger på hvordan man løser det bedre.
Sådan som jeg ser det er en af fordelene ved den oprindelige metode til at modularisere programmer på Unix at den fælles protokol er tekst (som phk også nævner). Det gør det muligt for et program skrevet i C kan levere data til et program skrevet i Java eller Python. Men siden da er dynamisk linking kommet til og mange bruger denne metoder til at få de forskellige dele af deres moduler til at kommunikere sammen. Men ulempen er selvfølgelig at et program der er skrevet i Java skal have lavet nogle komplicerede wrappere for at kommunikere med et modul skrevet i C. Nogle sprog har nemt ved at kommunikere med hinanden hvor andre har det meget svært. Jeg har lavet en del integrationer imellem tools i mit arbejde som programmør og har fundet frem til at integration imellem f.eks. java og .net er nemmere gjort med en websocket på localhost. Der har jeg oftest valgt at bruge json, men xml har også været brugt.
I forlængelse af @Magnus Jørgensen, er de bedste eksempler på nyere måder at modularisere et system på, hvor de enkelte dele er kan bindes sammen efter behov, microservices- og cloud-arkitektur:
Her er de enkelte moduler en service med veldefinerede API'er (input/output) og mulighed for at specificere opførsel (configuration) af modulerne med enten parametre eller kode. Hvis/når man har et tilstrækkelig god dokumentation (a'la man) kan man opnå den dekobling phk beskriver, hvor services kan bruges efter en udvikler(-gruppe) stopper eller udskiftes.
Forskellen er primært at de fleste systemer bygget på microsrvice-/cloud-arkitektur er opbygget til at opfylde systemets behov, så der er få services (primært infrastruklturelle), der generaliseres tilstrækkeligt til at blive genbrugt udenfor systemet, hvor de er skabt.
Jeg har stadig til gode at møde nogen som ikke hader systemd
Så må vi finde en dag at mødes. Jeg giver en øl :-)
Personligt har jeg lettere ved at overskue indholdet af /lib/systemd/system/ end indholdet af /etc/init.d/ . Jeg synes SytemV er noget rod og SystemD er en god løsning. Og jeg kan godt lide at den opsætning der kommer fra distributionen liger i /lib/systemd imens mine lokale tilføjelser kommer i /etc/systemd.
Jeg er også glad for at sætte noget sammen af de værktøjer der ligger i /usr/bin . Nogen gange måske lidt for glad. Det er ikke altid sjovt at møde et 50 linjer Bash program man kodede for 3 år siden. Bash er ikke bedre en Perl på det område. Ofte er en stor del af koden brugt til at parse og godkende input og derfor køre en kommando og lave select/map/reduce på det output. Og så gemme det som en array i en streng variabel. Udfordringen er at værktøjerne i /usr/bin/ ikke er så konsistente. Det er svært at vælge hvilke "kolonner" i output man skal bruge. Så der er noget om data type vi kan lære af PowerShell. Sorry der.
Jeg er også vild med at man kan koble lange pipes af sammen af små værktøjer og gøre magiske ting.
Men det er bare også en akilleshæl. Antallet af sikkerhedshændelser der skyldes problemer med præcist at tolke output fra en kommando i den næste er pænt stort, især hvis vi begynder at tage input fra nettet og sende gennem diverse små-kommandoer. Kombinationen af tekst-input, "quick-fix" administrator-scripts med mangelfuld inputvalidering, og root-rettigheder er farlig.
JSON som interface i stedet for rå tekst kan måske hjælpe på det, men jeg tror sådan en ændring vil give lige så meget ballade som SystemD. Så vil vi have to standarder for at sende data mellem kommandoer, for de gamle tools forsvinder ikke.
Helt enig i at SystemD i udpræget grad lider af scope-creep, men at det er roden til alt ondt køber jeg ikke.
I komplekse systemer kan der optræde et win ved, at to eller flere atomare komponenter sammenbygges, for at etablere et nyt virke på et nyt højere niveau.
Eksempelvis merger ZFS volumenhåndtering og filsystem, og kan på baggrund af dette levere features, som er upraktiske eller umulige for seperate old school volumen- og filsystemer.
Et andet eksempel er microservices A og B som outperformes af service C = A+B som følge af deling af intern state og eliminering af netværkstrafik.
Hvad er den systematiske tilgang til at vurdere hvornår man ikke skal monolitisere en service?
Udover man selvfølgelig kan hævde det som princip, og derfor aldrig påbegynde udvikling af visionært programmel som f.eks. ZFS.
Jeg er selv ikke fan af SystemDs størrelse og f.eks. afvigelse fra rene rare text logs, men omvendt standardiseres begrebet om, hvad en service, som startes på en server, er.
Men at merge HomeD med SystemD istedet for at lade det være et seperat projekt, er tydeligt bevis for at SystemD er gak. Debian, som er den distro jeg har mest erfaring med, må have en holdning til det her crazy forslag.
Men at merge HomeD med SystemD istedet for at lade det være et seperat projekt, er tydeligt bevis for at SystemD er gak. Debian, som er den distro jeg har mest erfaring med, må have en holdning til det her crazy forslag.
Jeg mener det nærmere er et bevis for at SystemD aldrig kun var tiltænkt som init-alternativ.
Jeg bruger Devuan som er en Debian fork uden SystemD.
Virker fint.
K
En helt subjektiv forskel på systemd og MS Office: Jeg har stadig til gode at møde nogen som ikke hader systemd. Office er der få som elsker, men man lærer at leve med det. Det klarer opgaverne, og er ikke til debat på arbejdspladsen.
Måske fordi folk, som synes at systemd fungerer fint, ikke føler det store behov for at udbasunere det?
Det virker som om, at den primære årsag til at nogen ikke kan lide systemd er, at "det virker anderledes end jeg er vant til" - der er i hvert fald langt mellem den reelle kritik, som ikke består af at skyde stråmænd ned. Det ovenstående med de 1.3MLOC er et godt eksempel - det tæller som nævnt i en kommentar ovenfor dokumentation osv. med, men holdt op imod antallet af linjer kode i de komponenter, som systemd erstatter, er 1.3MLOC heller ikke så voldsomt igen.
Og nej, systemd er ikke en "super-daemon", men derimod en samling af individuelle programmer, som udvikles som et fælles projekt. Det minder skægt nok om det, som mange BSD'er gør med base system, hvilket der ikke er den store kritik af.
Man kunne måske have ønsket sig et andet navn for projektet, fordi "systemd" giver associationer til inetd o.a., som er daemoner i klassisk forstand. Det er systemd ikke (længere), men man kan forledes til at tro det.
Et andet eksempel er microservices A og B som outperformes af service C = A+B som følge af deling af intern state og eliminering af netværkstrafik.
Det sker også en gang imellem med værktøjerne i /usr/bin For år tilbage skulle jeg trække information ud af gigantiske logs på en remote server som allerede var 90% belastet. grep+cut+awk brugte simpelthen for meget CPU til at jeg kunne bruge dem, og båndbredden til serveren var for lav til at jeg kunne hente de fulde logs hjem. Så jeg endte med at skrive et kombineret værktøj som kunne andvendes i den situation.
Personligt har jeg lettere ved at overskue indholdet af /lib/systemd/system/ end indholdet af /etc/init.d/ . Jeg synes SytemV er noget rod og SystemD er en god løsning.
Hørt! Jeg har skrevet min portion af init.d-scripts og har aldrig været fan af det. Den deklarative fremgangsmåde i systemds unit-filer virker bedre for mig.
Jeg kan også lide den konsistens og kontrol man får ud af det. Ikke noget med at serviceX skal have en post-start kommando, ikke noget med at serviceY ikke kan stoppes, ikke noget med at serviceZ har en racecondition på en pid-fil. systemctl start/stop/restart/reload virker på dem alle. Jeg er sådan set ligeglad med hvilket system der bruger de unit-filer - det kan være systemd, omnistart, PHKcontrol, eller en samling programmer skrevet i cobol. Bare giv mig mine unit-filer.
Det ovenstående med de 1.3MLOC er et godt eksempel
Min kritik er i denne forbindelse ikke på hvad "SystemD gør", men hvordan man "gør SystemD".
Dengang man faktisk tænkte seriøst over "system og metode" indenfor IT, blev man ret hurtigt enige om at en skreven linie var en skreven linie og at det overhovedet ikke gav mening at skelne imellem kommentarer og kodelinier, hverken i forbindelse med produktivitet eller sværhedsgrad.
At der er 1.3MLOC i SystemD's repo betyder at nogen har tastet 1.3MLOC ind[1] og dermed er SystemD er ét projekt på 1.3MLOC som er vokset nogenlunde konstant med 10% om året de seneste år.
Det er meget langt fra "Software Tools", uanset om der findes mere eller mindre veldokumenterede interne og externe interfaces til SystemD.
[1] Mig bekendt har de ikke checket tusindvis af maskin-genererede linier ind?
[1] Mig bekendt har de ikke checket tusindvis af maskin-genererede linier ind?
$ find ./* -type f -print0 | xargs -0 wc -l|sort -g |tail -n 20 4741 ./src/core/manager.c 5004 ./src/core/load-fragment.c 5237 ./src/nspawn/nspawn.c 5663 ./src/core/execute.c 5946 ./src/libsystemd/sd-bus/bus-message.c 5976 ./src/core/unit.c 6552 ./src/shared/linux/nl80211.h 7705 ./hwdb.d/20-acpi-vendor.hwdb 9527 ./src/systemctl/systemctl.c 10215 ./NEWS # Sikkert kompileret ud fra en historik 16850 ./test/sys-script.py # tydeligvis auto genereret 17292 ./hwdb.d/ma-medium.txt # db extract 21294 ./hwdb.d/ma-small.txt # db extract 21818 ./hwdb.d/usb.ids # db extract 32184 ./hwdb.d/pci.ids # db extract 60285 ./hwdb.d/20-usb-vendor-model.hwdb # db extract 94332 ./hwdb.d/20-pci-vendor-model.hwdb # db extract 100482 ./hwdb.d/20-OUI.hwdb # db extract 162894 ./hwdb.d/ma-large.txt # db extract 1278226 total 162894 + 100482 + 94332 + 60285 + 32184 + 21818 + 21294 + 17292 + 16850 = 527431
Det er meget langt fra "Software Tools", uanset om der findes mere eller mindre veldokumenterede interne og externe interfaces til SystemD.
Hvorfor det? Altså - der er vel ikke i sig selv noget galt i, at nogen har skrevet 1.3MLOC, især ikke fordi de giver en stor mængde funktionalitet og erstatter en masse anden kode?
systemd (som det staves) er i øvrigt netop en samling af programmer, som kan kobles sammen; ca. 70 af slagsen. De fleste kan udskiftes, og der er udvidelsespunkter til integration med andre komponenter; som eksempel kan journald fint forwarde til syslog.
Min kritik er i denne forbindelse ikke på hvad "SystemD gør", men hvordan man "gør SystemD".
Kan du ikke skrive din forståelse af hvordan man har gjort systemd?
Et program der gør mange ting vil have mange kode linier, så jeg er ikke helt sikker på at 1.3MLOC er noget problem. Men hvis du kan documentere at systemd er bygget op på en uhensigtsmæssig måde, så er jeg lutter øre. Sådan som jeg forstår det er structuren i systemd meget modulariseret. Oven i købet udnytter systemd dbus som er en IPC metoder der bruger XML til interchange format. Tager jeg fejl?
Et program der gør mange ting vil have mange kode linier, så jeg er ikke helt sikker på at 1.3MLOC er noget problem.
De 1.3MLOC er en konsekvens af de 10% om året og det er nok dem jeg finder mest bekymrende, for det er der Parkinssons lov og Peter princippet sniger sig ind.
Hertil naturligvis hele debatten om kvalitetssikring. Med 1.3MLOC taler vi allerede om 1300 deciderede fejl i koden, iflg. gængse tommelfingerregler.
En eller anden skrev tidligere, at systemd ikke er en "super-daemon" - og det er den måske heller ikke i den forstand, at det er "een stor binær fil" eller noget i den retning. Men det er eet stort system og folkene bag kalder det selv for "a system daemon" (se under "spelling": https://freedesktop.org/wiki/Software/systemd/)
På github er der pt. omkring 1100 issues: https://github.com/systemd/systemd/issues?q=is%3Aopen+is%3Aissue - hvilket selvfølgelig ikke er det samme som 1100 bugs, men det siger alligevel lidt om systemd's størrelse.
Systemd har uden tvivl nogle fordele i forhold til "den traditionelle" måde at gøre tingene på i en Linux-distro - ellers ville så mange formentlig ikke være hoppet med på vognen (eller hvad...?).
Det, der bekymrer mig ved systemd, er netop omfanget. Hvis noget havde en bug før, behøvede man kun at rette i netop den komponent. Men hvis så stor en del af OS'et består af systemd, skal en rettelse i gennem folkene bag systemd, som nu skal koordinere rettelser i et stort og komplekst system - koordineringen alene bliver kompleks. Det tager tid og - som en tidligere chef udtalte engang om store systemer - "it's prone to error".
Det bekymrer mig også, at systemd tilsyneladende er så svært et blive fri for; jeg har selv prøvet PClinuxOS og MX Linux, hvor init softwaren ikke er systemd, men de implementerer dele af systemd må benytte sig af shimming.
Som sagt har systemd formentlig nogle fordele og jeg vil ikke bare afskrive det som skrammel; en "traditionel" Linux-distro er heller ikke uden issues. Men jeg undrer mig over, at man har ladet ét system vokse sig så stort og at det partout skulle overtage dele af et Linux-OS, som fungerede uden problemer før.
Hvis 'fremtiden' er micro-kernels og micro-services så er det et ganske intelligent træk af Amazon. FreeRTOS ville ikke være et dårligt sted at starte en 'micro-kernel + toolbox' UNIX infrastruktur fra!
Prisen har nok været inden for den månedlige afrundingsfejl på AWS kaffebudget!
Det problem som jeg oplever med systemd er at udviklerne sætter tentaklerne ind i Alting og at det Sjældent er deres problem at ting der fungerede OK før stopper med at fungere - det er jo 'De Andre', de urene vantro uden for systemd-Katedralen, der skal opdatere deres software!
Det er en dårlig holdning at have; man håber lidt at overtagelsen af 'home directories' bricker så mange ting at problemet bliver åbenlyst.
PS: Jeg vil hellere tage besværet med at skifte til FreeBSD end at lade systemd håndtere mine data på den per-definition eneste rigtige måde (with FIFO on top!) som systemd mener at det skal gøres på!
@phk Troller du?
Jeg har lige vist dig at der mindst er 530k linier auto gen. kode, men du persisterer med at citere dine egne 1.3 MLOC.
Men hvis vi troller, vil jeg være med!
Tæller man alle linier i alle filer i systemd får jeg 1.27 MLOC. Fratrækkes autogen kode, så har systemd 0.7 MLOC. Opgjort på samme måde har, e.g., Varnish 0.2 MLOC kode.
Da systemd er ca 70 værktøjer, får vi 11k linier/værktøj i snit. Varnish må derfor, ud fra din logik, have ca en faktor 20 flere fejl end et gennemsnits systemd værktøj. Det vil jeg give dig ret i er skræmmende :)
PS: Jeg vil hellere tage besværet med at skifte til FreeBSD end at lade systemd håndtere mine data på den per-definition eneste rigtige måde (with FIFO on top!) som systemd mener at det skal gøres på!
Nøjagtigt sådan har jeg det også ! Jeg havde besluttet mig for at skifte fra Linux til FreeBSD. Men så opdagede jeg at kyndige hænder valgte at fork'e debian til Devuan.
K
Jeg er temmelig enig med PHK omkring det gavnlige at opdele programmer i relevante logiske dele, primært fordi det ofte gør det nemmere at teste hver enkelt del for sig, sekundært at man potentielt har muligheden for at koble ting anderledes sammen for at løse den enkelte opgave.
MEN jeg synes at store dele af den moderne end user applikations udvikling går ud i ekstremer på det område.
Java med SpringBoot samt alle de forskellige application server miljøer, er et fantastisk godt eksempel på 1) opdeling i små bidder, 2) misbrug ved opdeling i små bidder.
Det jeg henviser til er den ekstremt flexible mulighed der er for injection og udskiftning af enkelte komponenter og rutiner via typisk XML manifest filer spredt med rund hånd forskellige steder i en typisk installation.
Det ses også i Javascript, hvor et tilfældigt script totalt kan forandre hvordan den oprindelige Javascript kode blev afviklet, pga. den direkte adgang til redefinition af DOM.
Problemet er at det, trods gode pakketerings muligheder, er alt for nemt at fejle i opsætningen, og specielt den videre vedligeholdelse af sådan et kludetæppe af løst sammenholdte dimser og dimsedutter.
Af driftsmæssige årsager, vil jeg ofte foretrække noget som optræder som en monolit overfor administratoren samt brugerne, hvor det kræver en ny release at forandre dens overordnede funktion.
