Systemd

Dels fordi de skal lære en masse nyt og fordi det ødelægger alle deres scripts og workflows og ting og sager de har opbygget igennem mange år.

Og så selvf. fordi systemd (endnu?) generelt er buggy og umoden og bare ikke "smooth".

Endelig spiller det måske også en lille rolle at openSUSE endnu ikke har fået omskrevet samtlige init-scripts til systemd unit-filer, hvilket gør at man i nogle tilfælde skal gøre brug af kompatibilitetslag med sysvinit og andet bøvl.

Samtidig med at der for manges vedkommende ikke er nogensomhelst nævneværdig gevinst som kompenserer for alt bøvlet... (udover at Lennart ikke eksperimenterer med alt muligt andet så længe han eksperimenterer med systemd, selvom han selvfølgelig har fået sovset ganske mange ting ind i systemd).

Du skal tænke på at mange openSUSE-brugere har brugt Linux i mange år og er professionelle serveradmins osv. som er vant til et produktivt og funktionelt system. Fedora-brugere er nok mere indstillet på en tilværelse som forsøgsdyr.

#1 Jeg bøjer mig i støvet for dit fornuftige svar.

Kan godt se at det er et problem at skifte i den sammenhæng.

#2
Kan se du er Arch bruger og vil måske her være interesseret i følgende links:

http://archlinux.me/brain0/2012/09/10/yet-another-systemd-comment/
http://allanmcrae.com/2012/09/replacing-systemd-in-arch-linux/

Lidt omkring erfaring fra en Arch udvikler:
http://allanmcrae.com/2012/08/switching-my-laptop-to-systemd/

I hele diskussionen omkring systemd har der været en del trolls. En af historierne kan læses her:
http://jasonwryan.com/blog/2012/08/18/trolls/

Og sidst har der været en del snak om Arch Linux er på vej i en forkert retning som også kommer ind på systemd:
http://allanmcrae.com/2012/08/are-we-removing-what-defines-arch-linux/

#3 har læst de fleste allanmcrae posts.

The only other daemon left is my custom fan control. For that, I need to write my own service file. It is a very simple daemon, so has a very simple service file:
[Unit]
Description=Allan's MacBook Pro Fan Control Daemon

[Service]
ExecStart=/usr/bin/mbpfan

[Install]
WantedBy=multi-user.target
Much better than the 70 line monstrosity for the the old rc.d script.
The final daemons I used to launch manually were php-fpm, mysqld and nginx to run WordPress locally when I want to draft a blog post. I heard that you could easily customize service files so I wanted to add a dependency on php-fpm and mysqld to nginx so I only need to launch one thing. That was as simple as creating /etc/systemd/system/nginx.service with:
.include /usr/lib/systemd/system/nginx.service

[Unit]
Requires=mysqld.service php-fpm.service
Everything was running

Dette er også en af de grunde jeg undre mig over folks "brok" over systemd.

Edit: vil tilføje jeg selv køre pure-systemd arch setup og det spiller bare for mig.

#4
Synes også meget af det brok der kommer er ubegrundet. Jeg vil godt indrømme at det er anderledes og kræver en anden måde at tænke på men jeg synes ikke det er umuligt at lære og det har en del nice features. Mangler stadig at sætte systemd op på den primære Arch maskine men det kommer jo nok til at ske indenfor kort tid. :P

#5 Min konklusion er at folk råber før de har prøvet/undersøgt de nye ting, præsis som folks holdning til gnome 3.* men lad nu dét ligge.

Jeg mener bestemt det er fremtiden, og det bør være et hvert distros mål.

Selvfølgelig er det fremtiden. Det har Lennart jo bestemt. Og bare rolig, distros har stort set intet valg, for Lennart og co. er godt i gang med at tvinge systemd ned i halsen på alle uanset de vil have det eller ej.

Men historisk har mange af RedHats eksperimenter jo en relativt kort levetid - så man kan da ikke føle sig alt for sikker på at de ikke smider det hele ud med badevandet og skriver noget nyt fra scratch i næste måned.

#7 Tja, der er absolut intet eller noget der tvinger en distro til noget - de vælger selv. Så synes din formulering er lidt i overkanten. Har ikke brugt linux længe nok til og kende til kortvarige redhat eksperimenter. Men fordi noget nyt er udviklet behøver alting jo ikke gå i stå, det giver plads til fornyelse og forbedringer - oneway or another.

Når systemd bliver bundet sammen med udev og alskens ting og sager på kryds og tværs, så er valgfriheden noget begrænset.

Men jeg må da sige at på openSUSE 12.2 har jeg nu kørt med PulseAudio i næsten uge uden at det har irriteret mig, så måske vil systemd også holde op med at være irriterende efter 3-4 års yderligere udvikling. Så må vi bare se om der er nogen Linux-brugere tilbage til den tid, eller om de sidste er blevet jaget over på OSX.

Hvor kommer al den mistillid fra cb300f? Du er måske allerede selv hoppede over på OSX?.. Undre mig bare over dine ordvalg og konklusioner.

#8: Og bare rolig, distros har stort set intet valg, for Lennart og co. er godt i gang med at tvinge systemd ned i halsen på alle uanset de vil have det eller ej.
Du er tæt på at lave en BG :D
#0 & #4 Godt at høre at i er rykket over til systemd ;-)

Jeg er måske blevet lidt mavesur på mine gamle dage fordi GNU/Linux har mistet tonsvis af (power-)brugere (primært til OSX) i de sidste 3-4 år, pga. en tilsyneladende endeløs række af den type eksperimenter, som er blevet kastet i hovedet på brugerne alt, alt for tidligt.

Retfærdigvis skal det dog siges at det ikke kun er RedHat/Lennart/GNOME/FDO der er ansvarlige, men Canonical og KDE har også et par stykker på samvittigheden.

Men forhåbentlig har vi nået bunden nu, så der er en chance for at tingene kan begynde at gå fremad igen...

En hel anden ting jeg kan undre mig over, er hvorfor er det skrevet i python og ikke C - Ville det ikke køre hurtigere og mere stabilt i C? Ved godt det er svære og vedligeholde C kode end python.

#12 Okay så forstår jeg :) Ja igen har jeg ikke været inden for linux længe nok til og kende til de problemer, ud over jeg aldrig har brudt mig om KDE. Men lad nu det ligge og lad os se frem - synes der sker rigtig mange spændende ting pt. både på mainline kernel og intel grafik drivere m.m.

#12:
Men forhåbentlig har vi nået bunden nu, så der er en chance for at tingene kan begynde at gå fremad igen...

Jeg nåede kun lige at skrive ovenstående før jeg læste de første indikationer på at Gstreamer 1.0 bliver det næste mareridt i rækken for applikationsudviklere, packagers og brugere.

... Og packagekit 0.8 har åbenbart også store api-ændringer.

Så kan jeg lære det.

#13: En hel anden ting jeg kan undre mig over, er hvorfor er det skrevet i python og ikke C - Ville det ikke køre hurtigere og mere stabilt i C? Ved godt det er svære og vedligeholde C kode end python.Huh? Hvor får du den idé fra? Systemd er skrevet i C. Muligvis også stadig med noget Vala.

#16 var det ikke python i starten da? Men kan da godt se jeg tager fejl her på freedesktop fks.

#17:
Jeg har kigget på koden, og alle filerne har ".c"-endelser. Om de brugte Python i starten ved jeg ikke, men i så fald har det nok bare været som en prototype.

Har man arbejdet med et bestemt system i mange år, vil det at skifte til et system, der virker på en anden måde, og kræver nye rutiner, være en hurdle i sig selv.

Samtidig er har folk generelt en tendens til at acceptere begrænsninger i det man nu end har at gøre med, så selvom der er fundet smartere måder gøre en give ting på (her kunne det være logsystemet), vil der være mange, der har fundet ud af at klare sig uden de nye funktioner, og som derfor føler de er uvæsentlige.

Så uanset om en ny ting (her systemd) er perfekt, uden bugs (og her at der findes og distribueres unit/service-filer til samtlige programmer der i dag behøver init scripts) og 100 % bagudkompatibelt, vil der altid være folk der hellere vil bruge det system de kender bedst

-----

Og så er der jo den frivillige tvang ved at bruge software som andre vedligeholder. Man er afhængig af, at nogen vedligeholder det software man helst vil bruge, og her bliver problemet at finde nogen, der vil vedligeholde en stak software, der ikke indeholder systemd, d-bus eller hvad man nu ikke kan lide.