Linux får ”blåskärm”

Permalänk
Medlem
Skrivet av Sidde:

Det är rätt simpelt. Den gamla init-processen är en hög med shellscript vem som helst kan rätt lätt styra upp, och det finns inga externa beroenden. Medan systemd är en allt växande skara binärer med få möjligheter att modifiera beteendet över, och att de allt mer har beroenden till varandra. Dessutom finns det allt mer integration och beroenden mellan init-processen systemd och andra binärer som dbus, eller desktop-delar av systemet vilket gör att det blivit "allt eller inget".

Tyvärr har systemds komplexitet också lett till att man måste använda nya verktyg för att öht hantera sina maskiner och den gamla men väletablerade unix-filosofin har försvinnit.

systemd gör allt för många saker "samtidigt" och spottar inte inte ur sig text. Utan man måste ha andra binärer för att läsa loggar etc. Det är inte alls i enlighet med de gamla principerna.

Det har dessutom förekommit hårdkodningar mot t.ex Googles tidservrar i systemd-koden vilket leder till än mer "hat" mot hela konceptet. Det är helt enkelt något byggt av någon som inte bryr sig om idéerna bakom varför det öppna unix/*nix en gång i tiden skapades utan av helt andra ideal.

Utöver detta har det skapat en rejäl split mellan *BSD och Linux för att fler och fler desktop-miljöer kräver t.ex dbus som kräver systemd etc. Och projekt har inte oändligt med resurser så de får helt enkelt överge delarna med färre användare för att öht hänga med.

Summerat kan man säga att om man uppskattar det gamla UNIX/BSD så är systemd det som delar *nix-världen i det gamla och det nya rent praktiskt. Det går inte att kombinera.

Att ngn hårdkodat mot Googles time servrar låter som ett ärligt och mycket lättfixat misstag. Dessutom lär ju funktionaliteten vara hundra gånger större hos systemd.

Permalänk
Medlem
Skrivet av jspider:

Att ngn hårdkodat mot Googles time servrar låter som ett ärligt och mycket lättfixat misstag. Dessutom lär ju funktionaliteten vara hundra gånger större hos systemd.

Misstag säkerligen, men som kommer från ett aktivt designval.
När ingen satt tidsservern så valde man att bygga in en egen lösning i systemd så systemd kunde ha koll på tiden ändå. Så att hårdkoda mot google var bara en del av det större problemet.
Och det är en del av många designval där systemd bara växer och växer.

Varför måste systemd byta ut resolv och tidservrar?
Det som sker är att det blir en så stor koloss där alla sakerna måste sitta ihop för att fungera.
Det växer på alla håll och kanter där även ram-minneskrav etc. trissas upp vilket slår mot andra marknader.

En stor del av alla designval kommer från bland annat att redhat vill molntjänster, containrar och container-os.
Någonstans där kanske alla miljoner slutanvändare försvann ur ekvationen.

Problemet som skapats med systemd idag är att det är en så stor stack av mjukvara som bygger på varandra, och projekt har inte resurser att hantera scenariot att inte ha systemd, dbus etc. att det inte längre finns något val för en modern linux-distro.
Och där i ligger problemet, förr kunde man välja distros som hade BSD Init, eller SystemV init etc.
Man kunde till och med välja andra FOSS-system som *BSD, Hurd eller annat och fortsätta köra "samma" mjukvara, men vi har nu i princip nått vägens ende för det.

Nu ligger allt i händerna på big blue/redhats roadmap och fokuset är containrar.

Permalänk
Medlem
Skrivet av Sidde:

Misstag säkerligen, men som kommer från ett aktivt designval.
När ingen satt tidsservern så valde man att bygga in en egen lösning i systemd.
Och det är en del av många designval där systemd bara växer och växer.

Varför måste systemd byta ut resolv och tidservrar?
Det som sker är att det blir en så stor koloss där alla sakerna måste sitta ihop för att fungera.
Det växer på alla håll och kanter där även ram-minneskrav etc. trissas upp vilket slår mot andra marknader.

En stor del av alla designval kommer från bland annat att redhat vill molntjänster, containrar och container-os.
Någonstans där kanske alla miljoner slutanvändare försvann ur ekvationen.

Systemd är ett stort projekt med flera komponenter som gör många olika saker. Det är stort och komplext för att vad systemd försöker hantera är komplext. Om du är så missnöjd så utveckla ett alternativ eller sluta använd systemd.

Du kan säkert med rationella och sakliga argument få Arch, Debian, Ubuntu, Red Hat osv att sluta använda det. Det räcker nog med att visa hur systemd strider mot "unix filosofin" eller visa dem hur elak Poettering var mot dig för 15 år sedan när du gnällde om PulseAudio.

Visa signatur

Speldator - X570 | 5900X | 32GB 3600 CL16 | 4090 | 2TB 980 Pro | Win 11 Pro
Server - 3700X | 32GB | 7x5TB RAID-Z2 | TrueNAS

Permalänk
Medlem
Skrivet av test0r:

Om du är så missnöjd så utveckla ett alternativ eller sluta använd systemd.

Hurra för att Haiku, macOS och *BSD finns och jag kör alla 3.

Men det förhindrar inte mig från att vara missnöjd över att någon tar bort mitt val.

Permalänk
Skrivet av Sidde:

Misstag säkerligen, men som kommer från ett aktivt designval.
När ingen satt tidsservern så valde man att bygga in en egen lösning i systemd så systemd kunde ha koll på tiden ändå. Så att hårdkoda mot google var bara en del av det större problemet.
Och det är en del av många designval där systemd bara växer och växer.

Varför måste systemd byta ut resolv och tidservrar?
Det som sker är att det blir en så stor koloss där alla sakerna måste sitta ihop för att fungera.
Det växer på alla håll och kanter där även ram-minneskrav etc. trissas upp vilket slår mot andra marknader.

En stor del av alla designval kommer från bland annat att redhat vill molntjänster, containrar och container-os.
Någonstans där kanske alla miljoner slutanvändare försvann ur ekvationen.

Problemet som skapats med systemd idag är att det är en så stor stack av mjukvara som bygger på varandra, och projekt har inte resurser att hantera scenariot att inte ha systemd, dbus etc. att det inte längre finns något val för en modern linux-distro.
Och där i ligger problemet, förr kunde man välja distros som hade BSD Init, eller SystemV init etc.
Man kunde till och med välja andra FOSS-system som *BSD, Hurd eller annat och fortsätta köra "samma" mjukvara, men vi har nu i princip nått vägens ende för det.

Nu ligger allt i händerna på big blue/redhats roadmap och fokuset är containrar.

Jag skulle säga att systemd är symptomatiskt snarare än orsaken, dock: Det har blivit så billigt att bygga sin programvara på beroenden istället för att skriva funktionaliteten själv att majoriteten utvecklare gör just detta.
Det är fortfarande helt görbart att drifta tjänster på mer traditionellt uppbyggda system, men ja: den som gör det kommer att köra en minoritetsplattform, och det kan påverka hur lätt det är att exempelvis få extern hjälp med systemet.

Permalänk
Medlem

Ja, det var ju något användbart att de lagt till TPM i alla fall!

Min erfarenhet är att BSOD är 99% pga. hårdvarufel... nån enstaka gång kan en hårdvarunära drivrutin ha kraschat förstås.
Men kul att dom gjorde den "finare"?

Visa signatur

|[●▪▪●]| #Lekburk#: Ryzen 3700X >-< GB-X570-AE >-< 32GB DDR4 >-< MSI RTX 3070 >-< 970 EVO 1TB SSD>--
--< Arctic Freezer 34 >-< FD Define R4 >-< Seasonic F.+ 650W >-< Acer XF270HUA >-< AOC Q2778VQE >--
#Servering#: Ryzen 1700@3,6GHz >-< Prime X470 Pro >-< 16GB DDR4 >-< GTX 1030 >-< 970 EVO 500GB SSD >--
--< Stockkylare >-< Antec P182 >-< Silver Power 600W >-< Samsung 245T |[●▪▪●]|

Permalänk
Medlem
Skrivet av test0r:

Jag är helt jäkla förbluffad att hat-kampanjen mot systemd fortfarande är igång. Ingen tvingar er att använda systemd. Gå och använd Void, Devuan eller Gentoo och sluta gnäll om det. Om ni kör på Gentoo så kan ni ju spendera kompileringenstiden med att fundera över varför alla distributioners utvecklare valde att byta till systemd.

https://www.youtube.com/watch?v=o_AIw9bGogo

Det är ju ganska mycket upprördhet över Linuxkärnan i sig, åtminstone senare versioner men jag är inte tekniskt insatt, jag tror att kritiken handlar mycket om att bolag som microsoft är mer och mer involverade i utvecklingen av Linux men att även där så frångås gamla principer.
T ex att kärnan växer i storlek och koden fylls av saker som vissa tycker inte hör hemma där.

Visa signatur

No man is free who is not master of himself

Permalänk
Medlem
Skrivet av Sidde:

Det är rätt simpelt. Den gamla init-processen är en hög med shellscript vem som helst kan rätt lätt styra upp, och det finns inga externa beroenden. Medan systemd är en allt växande skara binärer med få möjligheter att modifiera beteendet över, och att de allt mer har beroenden till varandra. Dessutom finns det allt mer integration och beroenden mellan init-processen systemd och andra binärer som dbus, eller desktop-delar av systemet vilket gör att det blivit "allt eller inget".

Tyvärr har systemds komplexitet också lett till att man måste använda nya verktyg för att öht hantera sina maskiner och den gamla men väletablerade unix-filosofin har försvinnit.

systemd gör allt för många saker "samtidigt" och spottar inte inte ur sig text. Utan man måste ha andra binärer för att läsa loggar etc. Det är inte alls i enlighet med de gamla principerna.

Det har dessutom förekommit hårdkodningar mot t.ex Googles tidservrar i systemd-koden vilket leder till än mer "hat" mot hela konceptet. Det är helt enkelt något byggt av någon som inte bryr sig om idéerna bakom varför det öppna unix/*nix en gång i tiden skapades utan av helt andra ideal.

Utöver detta har det skapat en rejäl split mellan *BSD och Linux för att fler och fler desktop-miljöer kräver t.ex dbus som kräver systemd etc. Och projekt har inte oändligt med resurser så de får helt enkelt överge delarna med färre användare för att öht hänga med.

Summerat kan man säga att om man uppskattar det gamla UNIX/BSD så är systemd det som delar *nix-världen i det gamla och det nya rent praktiskt. Det går inte att kombinera.

Och som vanligt när det kommer till anti-systemd propaganda så är det så mycket fel och missuppfattningar. T.ex så blandar du här ihop två saker, init-hanteraren systemd och systemd projektet. Den ena är enbart en ersättare till init och den andra är en radda med separata binärer som är tänkt att ge Linux en standardiserad grund av system-program.

Finns ingen desktop-del som har något beroende mot init-hantereraren systemd, dock har t.ex Gnome ett beroende av ett DBUS namespace som bla tillhandahålls av ett av programmen i systemd projektet, systemd-logind då den tillhandahåller funktionalitet som bla Gnome uppskattar (men fy på systemd utvecklarna att de gjort något som externa projekt uppskattar, sånt kan vi inte ha).

Och det där med att "tvingas använda nya verktyg" är ju direkt löjeväckande som motargument på en plattform där varje distribution traditionellt har använt helt olika verktyg. Det som har hänt nu är istället att majoriteten av distributioner har standardiserat till att använda samma verktyg för att hantera domännamn, dns-uppslag, tids-synkning, dhcp osv osv. Samtidigt kan du installera vilken 3e parts verktyg som du vill och stänga av systemd varianterna så just den här punkten är väl den som är mest löjlig av alla.

Systemd spottar visst ur sig text, vad du har blandat ihop det med är att systemd projektet samtidigt kom med journald som _lagrar_ loggar binärt, vilket den gör för att den inte bara lagrar själva loggtexten utan också en satans massa meta-data och en applikation som är skriver för journald kan använda detta till att även logga ren data förutom enbart loggtext. Men du kan konfa den att logga allt till rsyslog om du vill, t.ex Ubuntu gör ju fortfarande så så att den som får ont i magen av att använda journalen kan läsa i ren text via /var/log/syslog precis som tidigare.

Allt prat om unix-filosifi är också rent blaj för det är exakt så som systemd projektet är uppbyggt, det är en skara med oberoende program som gör en sak och du kan kombinera dem för att lösa komplexa saker. Dock har du här valt att benämna kombinering som "beroenden" för att det ska låta mer negativt.

Det skall också nämnas att de beroenden som de olika systemd programmen har är inte mot andra systemd program utan det är mot DBS namespaces, så vem som helst kan bygga 3:e parts ersättare för varje komponent om man tvungen inte vill använda sig av systemd, vilket t.ex elogind är till systemd-logind för att köra t.ex Gnome på system som inte har systemd.

Skrivet av jspider:

Att ngn hårdkodat mot Googles time servrar låter som ett ärligt och mycket lättfixat misstag. Dessutom lär ju funktionaliteten vara hundra gånger större hos systemd.

Skall ju kanske också nämnas att detta då enbart gäller systemd-timesyncd som är en frivillig komponent och är en sntp klient, många kör ju ntp eller chrony istället, finns inget som helst krav att köra systemd-timesyncd.

Visa signatur

|Ryzen 5800x3d|RX 7900XTX Hellhound|Asus Prime X370 Pro|32GiB Corsair 2400MHz CL16 Vengeance|Corsair HX1000i|Fractal Define R5|LG 45GR95QE|Corsair K100|Razer DeathAdder V3 Pro|Ubuntu 23.10|

Permalänk
Medlem
Skrivet av Sidde:

Det är rätt simpelt. Den gamla init-processen är en hög med shellscript vem som helst kan rätt lätt styra upp, och det finns inga externa beroenden. Medan systemd är en allt växande skara binärer med få möjligheter att modifiera beteendet över, och att de allt mer har beroenden till varandra. Dessutom finns det allt mer integration och beroenden mellan init-processen systemd och andra binärer som dbus, eller desktop-delar av systemet vilket gör att det blivit "allt eller inget".

Tyvärr har systemds komplexitet också lett till att man måste använda nya verktyg för att öht hantera sina maskiner och den gamla men väletablerade unix-filosofin har försvinnit.

systemd gör allt för många saker "samtidigt" och spottar inte inte ur sig text. Utan man måste ha andra binärer för att läsa loggar etc. Det är inte alls i enlighet med de gamla principerna.

Det har dessutom förekommit hårdkodningar mot t.ex Googles tidservrar i systemd-koden vilket leder till än mer "hat" mot hela konceptet. Det är helt enkelt något byggt av någon som inte bryr sig om idéerna bakom varför det öppna unix/*nix en gång i tiden skapades utan av helt andra ideal.

Utöver detta har det skapat en rejäl split mellan *BSD och Linux för att fler och fler desktop-miljöer kräver t.ex dbus som kräver systemd etc. Och projekt har inte oändligt med resurser så de får helt enkelt överge delarna med färre användare för att öht hänga med.

Summerat kan man säga att om man uppskattar det gamla UNIX/BSD så är systemd det som delar *nix-världen i det gamla och det nya rent praktiskt. Det går inte att kombinera.

Eh ... Va?

Vad för script är det man inte kan köra längre?

Jag kör mängder med skript i systemd som jag skriver själv.

Eller menar du det som motsvaras av HAL / Intrerupt 13? I så fall ska du nog börja bygga din egen UNIX / Linux-version från grunden.

Visa signatur

Server: Fractal design Define 7 XL | AMD Ryzen 7 5800X 8/16 | ASUS ROG CROSSHAIR VIII DARK HERO | 64GB Corsair @ 3000MHz | ASUS Radeon RX 460 2GB | Samsung 960 PRO 512 GB M.2 | 2x 2TB Samsung 850 PRO SSD | 6x Seagate Ironwolf Pro 10TB
WS: Phantex Entoo Elite | AMD Ryzen Threadripper 1950X 16/32 | ASUS Zenith extreme | 128GB G.Skill @ 2400MHz | ASUS Radeon HD7970 | 3x 2TB Samsung 960PRO M.2 | 6x Seagate Ironwolf Pro 10 TB
NEC PA301W 30" @ 2560x1600 | Linux Mint 21.3 Cinnamon

Permalänk
Medlem

Fanns lite barnsjukdomar med Systemd i början, är väl bara BSD-folk som avskyr Systemd i dagsläge.
Inte deras favorit-licenstyp, men för gcc går det tydligen bra att köra GPL...?

Visa signatur

How do 'Do Not Walk on the Grass' signs get there ?

Permalänk
Medlem
Skrivet av Dyluck:

Fanns lite barnsjukdomar med Systemd i början, är väl bara BSD-folk som avskyr Systemd i dagsläge.
Inte deras favorit-licenstyp, men för gcc går det tydligen bra att köra GPL...?

fast BSD kör väl mest med clang/llvm numera iofs. Tror inte heller BSD-folk avskyr systemd så mycket som de inte har en jäkla aning om vad det är öht samt att de inte i dagslägen kan implementera en klon för det saknas stöd i deras kernel (systemd utnyttjar ju en massa nya saker i Linuxkärnan som ingen direkt använde tidigare som t.ex cgroups).

Visa signatur

|Ryzen 5800x3d|RX 7900XTX Hellhound|Asus Prime X370 Pro|32GiB Corsair 2400MHz CL16 Vengeance|Corsair HX1000i|Fractal Define R5|LG 45GR95QE|Corsair K100|Razer DeathAdder V3 Pro|Ubuntu 23.10|