Best distro ? Cutting through Linux Hype

Jeg er meget enig med fyren for hvad angår hans distro agnostic, men der er ting han ikke har prøvet, formentlig fordi han er amerikaner og derfor ikke har forsøgt sig med andet end en engelsk installation, eksempelvis MX Linux.

Jeg har lige testet MX Linux af, der er et Debian derivat og i den forbindelse så må jeg konstatere at den ikke er specielt brugervenlig som arbejdsstation for eksempelvis en dansker. Til gengæld kan den alt, men bare ikke uden at rode rundt mellem flere systemkonfigurations apps, der ikke har noget med slutresultatet at gøre.

https://www.dropbox.com/s/6b8mbxtbx3241ai/mx-linux.png?raw=1

Så for "Cutting through Linux Hype", så er Linux Mint, med Cinnamon DE, stadig den nemmeste af alle for en dansk nybegynder med Linux.

Men ikke specielt stabil, fordi den bruger systemd. Der har været en gut, der har meget styr på servere inde på Mewe, der udtaler sig om uptimes, og der sagde han, at med f.eks. RHEL, eller en anden distribution, man kan bruge som server, der bruger systemd, er der nogle bugs, der gør, at systemet vil gå ned efter så og så lang tid, fordi systemd optager mere og mere memory, jo længere systemet er oppe. Derfor frarådede han folk, at bruge systemd-baserede distributioner til servere, men i stedet bruge f.eks. Slackware, som bruger init, fordi den er langt mere stabil, at have kørende og ikke har de problemer. Han anbefalede også FreeBSD til, at have som system til, at have kørende længe, hvilket jeg er enig i. FreeBSD er endda mere stabil, at have kørende, end Debian. Meget renere inde under hjelmen.

Nuvel, en desktop er bestemt anderledes, end servere, men der er indikatorer på, at systemd er designet på en måde, så det går ind og overskriver og blander sig i visse vitale dele af systemet, med de bugs og ustabilitet det kan medføre.

Så at vælge Linux Mint med Cinnamon, som ny bruger KAN medføre ustabilitet ved brug på grund af systemd, især i det lange løb. Det er en ting man skal være opmærksom på, hvis man administrerer en Linux Mint maskine, som superbruger for en anden helt almindelig bruger. - Det er sådan set volapyk for begynderen, men ikke for den, der er ansvarlig for, at maskinen kører godt, og yder support, og det er ofte en bekendt, eller et familiemedlem. Blot mine 50 øre.

Ps. MX Linux bruger init, ikke systemd.

Hej

Jeg ved godt at det kan være farligt at blande sig i en debat, som jeg intet ved noget om, men er lidt intraesseret i mxlinux og linux mint (de=xfce), og jeg er ik klar over om at "systemd vs init" gør at mxlinux er bedre end mint at installere som sin daglige distro (jeg kan ik få xubuntu 18.04 til at updatere og den viser et orange udråbstegn nede ved mit ur i højre hjørne (i menubjælken), så jeg skal reinstellere påny!, men hvis nogen kan hjælpe så jeg kan begynde at få den til at updatere igen er jeg meget lydhør for gode råd!!).

Iøvrigt faldt jeg over "sysvinit", som et tredje begreb og igen ved jeg ik noget om debatten, men jeg er mere ud efter at kører med mxlinux som min daglige distro (jeg har kørt med xubuntu 18.04 siden oktober 2018).

2 link som forklare om "systemd vs init":
sysvinit en.wikipedia.org om MX_Linux
init (short for initialization) en.wikipedia.org om Init#SYSV

Har fundet installtionen af de 2 distroer mht uefi:
vedr install linuxMint med uefi: video om linuxMint
vedr install mxLinux med uefi: video om mxLinux

/allan

sysvinit er det samme som init. Init er bare en forkortelse. Sysvinit er den "gamle" init, som alle distributioner brugte før Upstart, systemd, Runit, OpenRC, osv. tog over. Nogle siger systemd er hurtigere, det vil jeg give dem ret i. Problemet kan være, at systemd har nogle bugs nogle gange, der kan gøre visse distroer ustabile - nogle gange. Ikke altid. Det meste af tiden mærker man ikke noget til det. Og i mange tilfælde skal man, som ny bruger overhovedet ikke skænke det en tanke. Det er mest ment som et supplement til superbrugeren, at overveje, når vedkommende administrerer maskiner enten til eget brug, eller som en hjælp til en anden bruger.

Jeg vil bestemt ikke bede nye brugere om, at sidde og pille ved opstartsfasen, services, mm. som er det en init tager sig af.

Jeg takker mange gange for det pæne og informative svar, som du OracleJMT gav mig.

Jeg var ik klar over at init omhandlede opstarten, men jeg bed mærke i at systemd loggede mere RAM efterhånden som tiden gik og det er nok kun relevant ifm servere, som kører uden stop pga brugerne skal hænte data mm.

/1bot.dk

Systemd er også en init, og tager sig også af opstarten. Forskellen imellem systemd og de andre er formentlig, at systemd også gør andre ting og går lidt dybere i systemet, end f.eks. Sysvinit eller OpenRC gør.

systemd er inspireret af Apples launchd, men er efter min mening overhovedet ikke ligeså god.

#2: Men ikke specielt stabil, fordi den bruger systemd. Der har været en gut, der har meget styr på servere inde på Mewe, der udtaler sig om uptimes, og der sagde han, at med f.eks. RHEL, eller en anden distribution, man kan bruge som server, der bruger systemd, er der nogle bugs, der gør, at systemet vil gå ned efter så og så lang tid, fordi systemd optager mere og mere memory, jo længere systemet er oppe. Derfor frarådede han folk, at bruge systemd-baserede distributioner til servere
Det er overordenligt vigtigt at nævne der ikke er tale om servere. Der er tale om Workstations ...

Arbejdsdstationer skal ikke være online over længere tid. De skal genstartes jævnligt bl.a, af sikkerhedsårsager.

Det er også lidt på plads at nævne at Ubuntu og derivater, er langt længere fremme med systemd end Debian. På sådanne Worksstations er der ikke tale om stigende forbrug af system ressourcer over tid. Du kan, hvis du ønsker, udmærket have en fx Mint 19.1 kørende i uge uden genstart. Jeg holder øje med system ressourcerne.

Det er værd at bemærke at Debian er ved at implementere systemd. Det virker godt nok ikke ordentligt endnu, men som eksempel: Start MX Linux op med Grub's Advanced, og vælg opstart med systemd.

Blot til oplysning ...

Nuvel, en desktop er bestemt anderledes, end servere, men der er indikatorer på, at systemd er designet på en måde, så det går ind og overskriver og blander sig i visse vitale dele af systemet, med de bugs og ustabilitet det kan medføre.

Det var derfor jeg skrev ovenstående, frogmaster.

Jeg ville blot informere om, at sysvinit er designet kløgtigt i tråd med systemets integritet, hvoraf systemd er en meget eksperimenterende init, efter min mening. Eksperimenter har en klang, der ikke rimer på stabilitet efter min mening.

MXLinux bruger sysvinit, som standard, og kun systemd-shim,(ikke rigtig systemd) som systemd-emulator, hvilket gør den stabil, efter min overbevisning.

at Ubuntu og derivater, er langt længere fremme med systemd end Debian

Det kommer da an på, om du taler om Debian Unstable, eller testing, eller stable.

#8

#8: Det kommer da an på, om du taler om Debian Unstable, eller testing, eller stable.
Ja og nej. Det er MX Linux jeg taler om og den er Debian stable. MX Linux 18.2 er spritny, kun en måned gammel og derfor blot en "baby"

Såvel det er godt at vide at server udvikling er baseret på erfaringerne med arbejdsstationer. Resultatet er PT at MX Linux, såvel som Debian endnu er bagefter Ubuntu og derivaters Workstartions.

Det er uhyre vigtigt for nye for brugere med Linux. Ubuntu/Mint er særdelses stabil, systemd eller ej. Det er pointen ...

#2
Det er fint at være utilfreds med systemd men det er ikke fint at opfinde halve sandheder for at argumentere imod systemd (jeg siger ikke det er dig der har opfundet denne løgn men du deler den og derfor skyldig). Kan du ikke selv høre hvor stor en omgang sludder det er hvis RHEL ikke bør bruges til servere pga. noget trivielt som memory leak i systemd? Og det skal da sørme også være noget af et gigantisk memory leak hvis du tænker at det er noget der kan tage en moderne 64 bit server ned... Og hvor lang tid tænker du serveren så skal køre før den rammer ind i et memory leak? Fordi serveren skal jo genstartes helst en gang om måneden i forbindelse med kerne-opdatering hvis man følger god skik?

Mine erfaringer baserer sig på CentOS og Red Hat Enterprise Linux (begge dele bruger samme kildekode bagved så der vil næppe være nogen forskelle) som vi bruger på arbejdet både på vores egne testmiljøer og ude i driften ved vores kunder. Derudover har jeg også erfaringer med Arch (der også bruger systemd) både ved to Arch Linux ARM installationer (med forholdsvis mindre mængde ram på 512 MB) samt min private bærbar og en KVM server installation ved en cloud udbyder.

Ved enkelte af vores Red Hat servere glemte vores driftleverandør at genstarte serverne efter opdateringer hvilket medførte en oppetid på ca. 1½ år. Ellers kører alle Red Hat serverne således de genstartes en gang om måneden nu i forbindelse med sikkerhedsopdateringer (uanset om kernen er opdateret eller ej da det er nemmere at skrive i en drifthåndbog bare at genstarte det hele frem for at skulle genstarte de enkelte komponenter der kan være påvirket af opdateringen). Alle vores CentOS servere er en del af vores testmiljø (eller VM'er på vores egne PC'er) og sikkerhedsopdateres derfor ikke så ofte og kan derfor ofte køre i måneder uden genstart.

Vores Red Hat servere bruger systemd til håndtering af services samt trigger af timere hvor sidstnævnte medfører over 100 start og nedlukning af systemd services om dagen. Alt logges desuden til systemd's egen journal log hvor der derfor hældes nær en gigabyte log om dagen når der er pres på.

Og min egen Arch Linux ARM installationer så vedligeholder jeg dem ikke vildt ofte så de kører ofte 1-2 måneder mellem opdateringer (de er begge interne systemer og kører kun få interne services). Sidst, så min egen KVM installation vedligeholder jeg nær dagligt og derfor genstartes den ca. en gang om ugen når der er opdatering til kernen eller systemd.

Og lad mig ud fra alt dette konkludere at jeg ALDRIG har hørt om et problem med driften der kunne kædes sammen med systemd eller at en server har kørt for længe mellem genstart (igen, vi "glemte" at genstarte i over et år). Og det er til trods for jeg er en af de få Linux eksperter i virksomheden og kontaktes derfor ofte når der opstår noget "underligt. Vores servere kører også med forholdsvist lavt til loftet når det gælder RAM så hvis vi havde set et større memory leak så ville vi have opdaget dette med det samme (hvilket vi har gjort tidligere men her var det i vores egen applikation dette leak kunne findes).

Vi har set systemd's journal vokse sig meget stor da vi i starten ikke havde sat et loft på denne. Men efter en konfigureret begrænsning her så har vi ikke set nogen problemer på den front.

På min arbejdsplads har jeg kun gode erfaringer med systemd som har vist sig at være stabilt og forudsigeligt hvilket også har gjort at alt det software vi leverer køres som systemd services og alt overvågning af services køres igennem systemd. Privat har jeg oplevet 1-2 problemer til systemd hvor jeg måtte vente på en opdatering før problemet blev løst men det er så også Arch og langt de største problemer her drejer sig mere om at du skal være opmærksom på yderligere konfiguration. Men det er selvfølgelig også pointen med Arch! :)

Yes såvel det er godt at vide at server udvikling er baseret på erfaringerne med arbejdsstationer. Resultatet er PT at MX Linux, såvel som Debian endnu er bagefter Ubuntu og derivaters Workstartions.

Ubuntu baserer sig på upstream Debian Unstable, og fryser selv længere henne i processen inden udgivelse. Så jeg ved ikke hvad du mener med bagefter. Debian Stable er jo den stabile Debian, og er den "gamle," så ja, det er rigtigt, Debian Stable vil altid være bagefter.

MxLinux er ikke bagefter på verisonsnumre, det er Debian Testing og er rullende, så vidt jeg ved.

Lad mig sige det således. Systemd har endnu nogle fejl, men den bliver fremtiden ...

#10

Så så, ingen grund til, at blive perfid, fordi jeg deler en amerikansk Mewe-brugers erfaring, Julemand. Det er fint, at du har andre erfaringer, men min holdning er blot, at det er en god ting, at have med til oplysning, at systemd nærmest er udviklet som et subsystem i sig selv, og er designet på en måde, som KAN være risikabel i det lange løb - i teorien.

Når det så er sagt, så ville jeg alle dage køre FreeBSD til kritisk infrastruktur, som hospitaler mv. hvilket er de eksempler vedkommende Mewe-bruger taler om. FreeBSD er meget mere stabil, end Linux. Det er min oplevelse, og den deler jeg med mange andre. Blandt andet Netflix, som bruger den som CDN. Juniper networks, mfl. Slackware ville jeg alle dage sætte min lid til, da det efter min mening ikke er forurenet med alskens sovs på low level niveau, men har en ren base, at gå ud fra, ligesom FreeBSD.

#8
Jeg ville blot informere om, at sysvinit er designet kløgtigt i tråd med systemets integritet, hvoraf systemd er en meget eksperimenterende init, efter min mening. Eksperimenter har en klang, der ikke rimer på stabilitet efter min mening.

Æh wut? Det er vidst lidt en sandhed med modifikationer. En af de helt store årsager til systemd var netop at sysvinit er meget dårlig til at understøtte "systemets integritet" fordi du har ekstremt svært ved med sysvinit at udtrykke afhængigheder mellem services samt sikre en fortsat overvågning af systemet hvis afhængigheder skulle gå ned.

Dette er ikke et problem så længe du har et simpelt system med få afhængigheder mellem delsystemer. Men man kan sige at vi ikke har set mere komplekse systemer netop fordi sysvinit gør det virkelig trælst at have den slags. Og med systemd blev der så åbnet op for at kunne udtrykke sig mere kompliceret når det gælder services.

Det er fuldt tilladt at være utilfreds med denne udvikling da det kan være svært at være med på sidelinjen og fortsat føle at man har samme "fornemmelse" af ens system som man havde tidligere. Men jeg er nu meget glad for at jeg nemt i properties filer kan angive afhængigheder på tværs af services i de applikationer vi udvikler til vores kunder og have en garanti fra systemet om at alt er sat op inden vores programmer eksekveres.

Kunne det laves med sysvinit? Selvfølgelig kan du det da sysvinit bare et bash scripts der følger nogle regler. Men det vil stensikkert også medføre en stor risiko for fejl.

#11: MxLinux er ikke bagefter på verisonsnumre, det er Debian Testing og er rullende, så vidt jeg ved.
MX Linux er baseret på Debian Stable ...

Fremtiden er systemd ...

Fremtiden er systemd ... og Ubuntu arbejdsstationer inklusiv derivater, er overordentligt stabile.
Det er bedre at basere sig på personlige opdaterede oplevelser end på noget andet.

#13
Du bør altså have lidt kildekritik når du videregiver erfaringer fra andre. Især når vi taler om systemd hvor der er rigtig mange folk der nærmer som et religiøst forhold til sit had til systemd. Dit argument med det er fint med "oplysning" er jo lidt en and da jeg omvendt kan sige det også er fint at oplyse folk om at sysvinit har været skyld til mere tab af data end noget andet system uden at nævne mere end det.

Ked af at sige det men jeg arbejder på et patientjournal system i Region Midt og medicinsystem til Region Nordjylland (og vi arbejder netop nu på at sætte det fulde patientjournal system i drift i Region Syd). Og vi bruger her Red Hat Enterprise Linux i driften (pånær Oracle databasen som vidst fortsat kører Solaris ved en af kunderne).

Der er brugt Red Hat i midt i nok ca. 5 år efterhånden i Region Midt og erfaringerne herfra er altså ikke at dette skulle være ustabilt på nogen måder. Ligeledes har der været brugt Red Hat i Region Nordjylland i ca. 2 år og heller ikke nogen problemer her.

Jeg hælder altså nu mest til at det er langt mere vigtigt for stabiliteten at de som sætter systemet op kender den platform de skal konfigurere. FreeBSD og Slackware kan være nok så lækkert men det er sku svært at finde folk der forstår at bruge sådan et system og kan konfigurere det på en måde således der også kan være en garanti for at ting virker efterfølgende i forskellige situationer. Især hvis du har flere folk der skal udvikle op imod samme system og du vil undgå at folk træder hinanden over tæerne.

Du bør altså have lidt kildekritik når du videregiver erfaringer fra andre.

Hvorfor er det nødvendigt, når det blot er en oplevelse og en tendens, som kan være vigtig at have med i sine tanker? Det er jo ikke andet? Tag det dog roligt. Jeg hedder ikke Lars Løkke, og bliver interviewet af BT eller Ekstra Bladet, mand. Jeg siger blot, at der kan være visse tendenser, men jeg påstår ikke, at det er den endegyldige sandhed.

Damn, hvorfor er server-folk så så anspændte overfor deres legetøj?

#23: Damn, hvorfor er server-folk så så anspændte overfor deres legetøj?
Det handler ikke kun om serverfolk. Jo jeg er server administrator, men derfor har jeg brug for service arbejdsstationer.

Alene at installere et remote admin værktøj i service mode (starter under boot), uden systemd, er nærmet umuligt. Det er realiteten på fx MX Linux.

Det skydes ny software er skrevet til systemd.

Ja, men de vil, af samme årsag, tvinges til enten følge med tiden eller uddø.
Debian er ved at implementere systemd

Kan du ikke selv høre hvor stor en omgang sludder det er hvis RHEL ikke bør bruges til servere pga. noget trivielt som memory leak i systemd?

Hvorfor er det sludder, når en kæde ikke er stærkere, end det svageste led? Man må altså være lidt mere ydmyg i forhold til alternativerne. RHEL, Ubuntu, Debian, eller SLES er ikke Gud.

Jeg skriver dette fra MX Linux, og den har problemer med at skrive flere bogstaver ... ;)

#29
Måske fordi Red Hat og de andre lever af at sælge deres OS til store virksomheder der primært bruger OS'et til deres servere? Hvis der vitterligt var et systemd memory leak der gør OS'et uegnet til servere så er det et problem der er fikset for længst (specielt ved Red Hat eftersom det er dem der står for systemd projektet). Og igen, det er ikke noget jeg har hørt noget som helst om i min tid med systemet.

Eller påstår du nu at vi snakker om en fejl i systemd der er så vital at det umuligt kan løses uden at omskrive det hele fra bunden og faktisk også omdøbe projektet da alene navnet er skyldig i problemerne? :)

Eller påstår du nu at vi snakker om en fejl i systemd der er så vital at det umuligt kan løses uden at omskrive det hele fra bunden og faktisk også omdøbe projektet da alene navnet er skyldig i problemerne? :)

Ja, og det kan du mene er useriøst. Men at sætte sådan et fjols til, at varetage noget så vigtigt, som kerneudvikling, det skriger til himlen. Manden, der opfandt Pulseaudio, en slags metastase af en knude, der først blev fri for bugs flere år efter første udgivelse. Det er utroligt, at Linus ikke har blokeret for både Kay Sievers og Poetering og co. Det er simpelthen for risikabelt af have de to legebørn med i kerneudviklingen. Det har jeg hele tiden ment.

Måske fordi Red Hat og de andre lever af at sælge deres OS til store virksomheder der primært bruger OS'et til deres servere?

Jeg har det med imperier, som med autoriteter. De er kun hvad de er, fordi de har fået folk med sig i projektet tidligt. Red Hat er et firma. Dem kan man så stole på, eller lade være. Jeg stoler ikke på dem over en dørtærskel, i og med, at jeg oplever dem som luskede, ligesom jeg gør med Oracle.

#23
Hvorfor er det nødvendigt, når det blot er en oplevelse og en tendens, som kan være vigtig at have med i sine tanker?

Fordi det langt fra er sikkert at det faktisk er en oplevelse og/eller tendens? Det kan jo være at din kilde ikke forstår sig på systemd og har kludret rundt i det og konfigureret det forkert? Hvem siger at hans oplevelse overhovedet kommer af systemd? Det kan også være problemet kun var i en specifik distribution og skyldtes en fejl i distributionen? Det kan endda være problemet allerede er løst?

Derudover bruger du din kilde til at ligge vægt på dit budskab som er:

Så at vælge Linux Mint med Cinnamon, som ny bruger KAN medføre ustabilitet ved brug på grund af systemd, især i det lange løb. Det er en ting man skal være opmærksom på, hvis man administrerer en Linux Mint maskine, som superbruger for en anden helt almindelig bruger. - Det er sådan set volapyk for begynderen, men ikke for den, der er ansvarlig for, at maskinen kører godt, og yder support, og det er ofte en bekendt, eller et familiemedlem. Blot mine 50 øre.

Det er altså en underlig konklusion baseret på den evidens du kommer med og som endda er en kilde der udtaler sig om servere. Du skriver det jo så også selv lige før:

Nuvel, en desktop er bestemt anderledes, end servere, men der er indikatorer på, at systemd er designet på en måde, så det går ind og overskriver og blander sig i visse vitale dele af systemet, med de bugs og ustabilitet det kan medføre.

Lige præcis... men det er så dig selv der efterfølgende kommer med "men der er indikatorer på, at systemd er designet på en måde...". Nej? Der er intet i dit referat fra din kilde som peger over mod et specielt farligt design i systemd som skulle medføre en øget risiko for bugs og ustabilitet hvis man sammenligner med fx sysvinit.

Og netop derfor tænkte jeg at det var relevant at jeg kom med et indspark til debatten da jeg tænkte jeg faktisk havde nogle erfaringer fra virkeligheden at byde ind med. Så skal du være velkommen til at kalde det anspændthed men det gør det ikke mindre korrekt det jeg skriver. :)

#33
Ja, og det kan du mene er useriøst. Men at sætte sådan et fjols til, at varetage noget så vigtigt, som kerneudvikling, det skriger til himlen. Manden, der opfandt Pulseaudio, en slags metastase af en knude, der først blev fri for bugs flere år efter første udgivelse. Det er utroligt, at Linus ikke har blokeret for både Kay Sievers og Poetering og co. Det er simpelthen for risikabelt af have de to legebørn med i kerneudviklingen. Det har jeg hele tiden ment.
Og så lukker jeg af for i aften herfra da din post her så tydeligt viser din agenda og ståsted herinde og intet hvad jeg måtte komme med vil kunne ændre den holdning.

#34: Jeg har det med imperier, som med autoriteter.
Jeg forstår godt hvad du mener, men det er ikke hvad jeg taler om. Det er praktisk anvendelighed.

For at installere nye programmer uden systemd, så skal man igennem noget ingen ønsker. Dette link er blot et eksempel: https://www.digitalocean.com/community/tutorials/how-to-install-and-con…

Jo, men det eneste der står om services er konfiguration af systemd UNIT service-filer.

#37
Det er jo netop det.
systemd er ikke til at komme uden om ...

Ikke på Linux. Men det er det, hvis man agter, at bruge en af BSD operativsystemerne.

#39: Ikke på Linux. Men det er det, hvis man agter, at bruge en af BSD operativsystemerne.
De vil uddø ... De er allerede obsolete, udover det ikke har noget med hverken Debian eller MX at gøre.

#41
Jeg tror et proprietært (empirisk) foretagende som Netlix, med flere, selv må bestemme sig for deres fremtid.

(Damn, MX har problemer med bogstavet f)

#43: FreeBSD som deres CDN, pga. den fremragende TCP/IP stack, som regnes for, at være en af de bedste i verden.
Det er jeg ikke uenig i.

Jeg siger blot at det ikke har noget med hverken brugervenlige Linux at gøre, såvel som udviklingen af systemd ... I den forbindelse at MX Linux næppe kan kaldes brugervenlig.

Med andre ord, i henhold til tråden, at MX ikke er for en begynder, systemd eller ej, og at man ikke fatter en brik hvis man vælger den som arbejdsstation ... I det mindste hvis man ikke bruger et engelsk tastatur.

Trænede Linux folk er ikke medregnet ...

#27:
Og SMF er generelt anset som forløberen til systemd.

Så at sige at Solaris/Illumos osv. ikke bruger systemd er rigtigt, men så alligevel ikke helt.

Mvh Tony
Ex Sun Microsystems.