Permalänk
Medlem

systemd init - vad tycker ni?

Nu har jag gått över till systemd på två av mina fyra Arch-Linux installationer (jag kör dessa två med XFCE skrivbord). Tydligen är systemd "the shit" när det gäller initsystem på Linux, bland annat kommer Gnome 3.6 ha beroenden till systemd. Först var jag skeptisk men nu när jag själv provat så är jag mestadels positiv. Det är ganska smidigt när man väl börjat använda det. Kan inte påstå att datorn bootar mycket snabbare (kanske för att jag har SSD-disk så det går snabbt ändå) men det funkar bra. Jag gillar särskilt funktionerna att automontera nätverksshares när de blir tillgängliga och med timeout om de försvinner så nu kan jag använda fstab istället för autofs även för NFS, samba och sshfs.

Ubuntu har valt att fortsätta med upstart (åtminstone i 12.10) så de verkar välja ett eget spår. Men det är väl bra att det finns alternativ tycker jag. Men många andra distar går över till systemd verkar det.

En del kritiker hävdar att man går ifrån UNIX-principerna (som innebär att man ska dela upp saker och ting i många små specialiserade program istället för att ha en stor blaffa som sköter om allting). Andra hävdar att man måste anpassa det till dagens teknik och linuxkärnan i sig är ju en stor blaffa den också. Hursomhelst jag tycker det verkar fungera bra och det verkar inte slöa ner systemet heller (tanken är att den ska kunna starta saker parallellt och endast när de behövs istället för att alltid hålla allting igång i bakgrunden). Jaja, jag kan inte alla tekniska detaljer...

Många går väl och irriterar sig på Lennart Poettering som är lite väl självsäker av sig och tycker att de som inte använder systemd är dumma i huvudet. Även om han har goda argument om hur bra det är så kan man kanske vara mer ödmjuk av sig...

Eftersom Arch Linux nyligen officiellt har systemd som default och guiderna på deras wiki uppdateras i rasande takt att endast inkludera hur man ställer in saker i systemd kände jag mig tvungen att byta för att inte bli helt utdaterad. Men bytet är inget jag ångrar nu när jag väl gjort det. Visst det gamla initsystemet funkar och man kan köra mix av det gamla och det nya om man vill men man får ingen support längre för sysvinit. Jag tycker ändå det är bra att man tar radikala beslut och inte hänger kvar vid gammalt omodernt som är dömt att bli utdaterat.

Att använda systemd för systemet känns ungefär som att använda ZFS för lagring tycker jag. Visst det är en stor blaffa som sköter om mycket, men det förenklar också administrationen av systemet.

http://www.freedesktop.org/wiki/Software/systemd
http://en.wikipedia.org/wiki/Systemd
http://www.youtube.com/watch?v=TyMLi8QF6sw

Permalänk
Medlem

systemd fungerar bra. Men allt är inte 100% ännu. Automounts med cifs i fstab fungerade ett tag, nu har det slutat fungera för mig.
Men det är inte så jobbigt att köra sudo mount -a efter man bootat

Det fina med systemd är ju att systemet bootar på 5-10 sekunder istället för minuter!

Permalänk
Medlem
Skrivet av =JoNaZ=:

Det fina med systemd är ju att systemet bootar på 5-10 sekunder istället för minuter!

Jag upplever iofs att mitt os tar typ 5-10 sekunder på sig att komma ihåg när väl bios är klart, även jag kör arch linux på en SSD, fast jag har inte bytt till systemd ännu. Då har jag iofs ingen autostart på X, så jag får logga in och skriva startx, men det tar ju inte många sekunder för openbox att hoppa upp. Systemd känns intressant, ska läsa på lite mer om det innan jag byter dock (även om det börjar bli dags, eftersom arch utvecklas så snabbt åt det hållet just nu).

Visa signatur

Jobbar som IT-konsult och driver https://datarymden.se med internet- och colocationtjänster i Umeå. Erbjuder hosting av servrar till rimliga priser, både tower och rackmonterade.

Permalänk
Medlem
Skrivet av =JoNaZ=:

systemd fungerar bra. Men allt är inte 100% ännu. Automounts med cifs i fstab fungerade ett tag, nu har det slutat fungera för mig.
Men det är inte så jobbigt att köra sudo mount -a efter man bootat

Det fina med systemd är ju att systemet bootar på 5-10 sekunder istället för minuter!

Hur ser mount-raden ut i fstab?

För att montera min filserver via NFS har jag denna rad:

filserver:/mnt/lager /mnt/nfs/filserver/ nfs4 defaults,noatime,noauto,x-systemd.automount,x-systemd.device-timeout=10 0 0

(ip-adressen till filserver har jag lagt in i /etc/hosts)
Har än så länge inte haft några problem med automount men å andra sidan har filservern varit igång hela tiden. Har inte testat med cifs ännu.

Permalänk
Medlem

Har också bytt till systemd på alla mina burkar, kan inte heller påstå att jag märker någon märkvärd prestadaskjuts vid start. Tycker det går lika snabbt/långsamt som tidigare, att låsa upp alla krypterade partitioner är fortfarande det långsammaste momentet.

Något jag däremot märkt att det går sjukt mycket fortare att stänga av burken, från säg 5-10 sek till typ 1-2 sek.

Visa signatur

WS: Fractal Design Pop Silent | Seasonic Prime G12 GC 550W | Gigabyte B650 Eagle AX | Ryzen 7 7700 | Corsair 64GB DDR5 | Asus Xonar DX | Arch Linux (x86_64) | Eizo EV2795
HTPC: Philips 50PUS8804, Kodi samt extern usb-disk
Server: Raspberry Pi 4 | 8GB RAM | HDD 750GB | Arch Linux (armv7h)

Permalänk

Tycker både uppstart och avstängning har blivit snabbare med systemd.

Permalänk
Medlem

Ett tips är att köra systemd-analyze blame för att se vad som tar tid under en boot:

[root@jonaz ~]# systemd-analyze blame
8960ms network.service
282ms systemd-modules-load.service
273ms avahi-daemon.service
216ms bluetooth.service
169ms lm_sensors.service
161ms console-kit-log-system-start.service
155ms colord-sane.service
146ms systemd-logind.service
143ms systemd-udev-trigger.service
120ms sys-kernel-debug.mount
113ms systemd-sysctl.service
106ms hwclock.service
96ms systemd-udevd.service
96ms dev-hugepages.mount
87ms systemd-vconsole-setup.service
84ms systemd-user-sessions.service
83ms dev-mqueue.mount
80ms ntpd.service
79ms rc-local.service
46ms colord.service
41ms systemd-remount-fs.service
39ms systemd-tmpfiles-setup.service
32ms console-kit-daemon.service
19ms rtkit-daemon.service
13ms boot.mount
8ms upower.service
8ms udisks.service
4ms home.mount
3ms tmp.mount
0ms sys-fs-fuse-connections.mount

Permalänk

Jag hade precis lärt mig rc.d i Arch och allt, så kommer systemd där och leker tuff... Nä tack, ogillas.

Visa signatur

oniichaNj@rizon, freenode, oftc, m.fl

Permalänk
Medlem
Skrivet av =JoNaZ=:

Ett tips är att köra systemd-analyze blame för att se vad som tar tid under en boot:

[root@jonaz ~]# systemd-analyze blame
8960ms network.service
282ms systemd-modules-load.service
273ms avahi-daemon.service
216ms bluetooth.service
169ms lm_sensors.service
161ms console-kit-log-system-start.service
155ms colord-sane.service
146ms systemd-logind.service
143ms systemd-udev-trigger.service
120ms sys-kernel-debug.mount
113ms systemd-sysctl.service
106ms hwclock.service
96ms systemd-udevd.service
96ms dev-hugepages.mount
87ms systemd-vconsole-setup.service
84ms systemd-user-sessions.service
83ms dev-mqueue.mount
80ms ntpd.service
79ms rc-local.service
46ms colord.service
41ms systemd-remount-fs.service
39ms systemd-tmpfiles-setup.service
32ms console-kit-daemon.service
19ms rtkit-daemon.service
13ms boot.mount
8ms upower.service
8ms udisks.service
4ms home.mount
3ms tmp.mount
0ms sys-fs-fuse-connections.mount

Testa att köra med statisk ip istället för dhcp så bootar du fortare. Verkar ta lång tid att få igång ditt nätverk. Eller kör du trådlöst? Jag kör statisk ip med netcfg net-auto-wired.service.

Ett annat tips för att få en snygg bild av det hela är

$ systemd-analyze plot > plot.svg

Tydligen bootar jag min desktopdator på 4,25 sekunder.

Permalänk
Avstängd

Visst kanske man går ifrån Unix principerna med Systemd, men denna Linux teknik verkar ju som vanligt, vara en klon av Solaris teknik, och eftersom Solaris som är ett riktigt Unix använder sin SMF, så är väl Systemd ok?

Tydligen pratar skaparen av Systemd ganska mycket om Solaris SMF, precis som Systemtap gänget pratar om Solaris DTrace, och BTRFS skaparen pratar om ZFS.
http://0pointer.de/blog/projects/systemd.html

Permalänk
Medlem

Ja alla verkar låna idéer från varandra. Själv gillar jag när man tänker nytt och försöker göra det bättre. Sedan är det lite synd att licensregler "tvingar" folk att uppfinna hjulet på nytt. Å andra sidan kanske man kommer på något nytt och kanske bättre, även om det tar tid att få det färdigt.

Det är väl något gammalt tänk det där att i UNIX så har man många små program som dedikeras för var sin uppgift och gör denna uppgift bra. Men ibland kan ju alltför stor uppdelning medföra att det bli dålig prestanda eller dålig integration. Exempelvis ZFS som istället för att dela upp lagring i en massa olika lager tar ett helhetsgrepp om det hela kan göra det hela mera effektivt, är det att gå ifrån de gamla unix-principerna? De som klagar på "layer violations" tycker väl det.

Permalänk
Medlem
Skrivet av ronnylov:

Nu har jag gått över till systemd på två av mina fyra Arch-Linux installationer...

Jag tycker systemd är mycket intressant, själv kör jag min egen LFS baserad dist där jag bytt ut sysvinit med systemd.

Det som är bra är att jag slipper skriva egna init scripts (jag gillar BSD init, inte LFS standard init) eftersom systemd har sådant klart

Det jag tycker är nackdelen är att det är mindre anpassningsbart jämfört med tidigare shell script. Jag har iof inte lärt mig allt än.

Men ta min egna LFS dist som exempel, min tanke är att (lite FreeBSD inspirerade) alla extra saker som installeras på systemet skall installeras i /usr/local. Det gäller även alla inställningar (ej inställningar för användare så klart) och uppstartsfiler för varje paket. Detta ska i slutändan göra så att jag ska kunna installera allt som ligger på root partitionen sedan bara behöva konfigurera in vilken parition som monteras på /usr/local (ev. /opt också eftersom folk värkar gilla att stoppa saker där), sedan ska allt vara som vanligt utan att behöva göra något mer. På samma sätt ska man kunna få ett ominstallerat system genom att helt enkelt köra rm -rf /usr/local/*
Problemet jag har funnit med systemd är att paket installerar sina systemd uppstarts filer i /usr/bla/bla/bla (minns inte exakt ) istället för /usr/local/bla/bla/bla det har jag ännu inte fixat (har andra problem att brottas för tillfället )

EDIT: En annan sak är att den väntar på nätverket, som tidigare skrev att det går fortare med statisk IP, vilket är delvis onödigt så länge man inte har root eller något viktigt filsystem på nätverksdisk. dvs. Kan den boota upp till desktop utan att vänta på nätverket tycker jag att den autmatiskt ska göra det och när nätverket är uppe så startas dom tjänster som är beroende av nätverket.

Visa signatur

Desktop: Ryzen 9 3950x | RTX 2060 | 16Gb RAM | 512Gb + 256Gb SSD
NAS: HP Microserver Gen8 | 8GB Ram | 3x2Tb ZFS | FreeNAS
SRV: HP ML350p Gen8 | 64GB Ram | 2x E5-2630v2 | ESXI

Permalänk
Medlem

Nu är tredje datorn (filservern) konverterad till systemd. Det är bara htpc-datorn kvar men den har jag ändå tänkt uppgradera och installera om till 64-bit så det känns inte lika angeläget att konvertera den installationen.

Det kanske går att konfigurera att starta nätverket senare om man vill? SSH-tjänsten kan man konfigurera så att den startar vid första anrop. Gör man så med alla tjänster som beror på nätverket så skulle den inte behöva vänta på nätverket vid uppstarten. Nu startar det så snabbt ändå tycker jag så jag har inte brytt mig om att tweaka mer.

Permalänk
Medlem

User session

Testade precis systemd user sessions. Jag använder det numera att starta min lokala mpd server som jag vill kunna styra och köra med user rättigheter.
Det var bara att stoppa en service fil för mpd i

/etc/systemd/user/

sen kör man

$ systemd --user

i något skript när användaren loggar in. Sedan går det start programmet med med

$ systemctl --user <star/stop/enable/disable> mpd

som vanligt men utan att ha några systemrättigheter.

Permalänk
Medlem
Skrivet av Rist:

Testade precis systemd user sessions. Jag använder det numera att starta min lokala mpd server som jag vill kunna styra och köra med user rättigheter.
Det var bara att stoppa en service fil för mpd i

/etc/systemd/user/

sen kör man

$ systemd --user

i något skript när användaren loggar in. Sedan går det start programmet med med

$ systemctl --user <star/stop/enable/disable> mpd

som vanligt men utan att ha några systemrättigheter.

Smidigt!

Det fanns en servicefil för xbmc märkte jag. Har inte testat den men tror man kan använda den på liknande sätt för att auostarta xbmc på liknande sätt.

Permalänk
Medlem

Nån som har koll på hur man kan få systemd att INTE rensa skärmen innan login prompten visas?

Visa signatur

Desktop: Ryzen 9 3950x | RTX 2060 | 16Gb RAM | 512Gb + 256Gb SSD
NAS: HP Microserver Gen8 | 8GB Ram | 3x2Tb ZFS | FreeNAS
SRV: HP ML350p Gen8 | 64GB Ram | 2x E5-2630v2 | ESXI

Permalänk
Medlem

En renodlad ny init-daemon med mer aggresiv parallellisering hade väl absolut varit intressant att ta en titt på. Däremot gillar jag inte utvecklingen alls med att eländet ska ta över en massa annat istället för att vara just en init daemon, så därför är systemd inget jag vill använda och supporta. Ja, jag tycker faktiskt att det är att gå ifrån Unix-principerna på ett negativt sätt. Trådskaparen slår ju huvudet på spiken med just "blaffa".
Jag tycker inte att förespråkarnas jämförelser med själva Linuxkärnan är riktigt väsentlig. Visst är kärnan monolitisk och visst har den vuxit med åren, men den har alltid varit monolitisk och är samtidigt i allra högsta grad anpassningsbar.

Visa signatur

Gentoo Desktop: Ryzen 3600X | 32 GB
Server: Intel G7400T
Commodore 64C + 1541u2

Permalänk
Medlem

Efter att kört ett tag nu så tycker jag det känns ganska bra med systemd. Det som jag fortfarande tycker är lurigt är hur man bestämmer ordningen på när saker ska startas. Visst parallellisering är bra men det blir svårare att få full kontroll känner jag. Ibland startar en deamon för tidigt och så blir den fail och funkar inte. Startar man den sedan manuellt igen så funkar den. Jag vet att man kan sätta villkor på hur saker och ting beror på varandra men jämför man med den gamla rc.conf som fanns förut i Arch Linux så har det ändå blivit krångligare med att få saker att starta i rätt ordning (förr startades bara en sak i taget i en viss ordning så det var förstås lättare att styra det, men det gick långsammare). Men jag kanske behöver sätta mig in mer i hur det fungerar.

Jag är på det hela taget ändå positiv till systemd och hoppas detta blir framtidens standard på Linux. Ubuntu har som sagt var valt en annan väg och det är lite trist tycker jag för många utvecklare gör så att det bara funkar i ubuntu och så struntar de i resten. Ett exempel är xbmc som om man kör det standalone på Arch Linux så funkar inte avstängningsfunktionen. Detta beror på att xbmc-utvecklarna ser det som "distributionsspecifikt" bara för att det funkar på ubuntu och därför struntar i problemet. Det är ju snarare ubuntu som valt gå en annorlunda väg och är distributionsspecifika... Samma sak med utvecklarna av "zfs on Linux". De ser också bara till att det funkar på ubuntu och struntar i att skapa en systemd service för zfs. Jag kör med rc.conf just för denna demonen men gillar det inte. Kanske är det att Arch Linux ligger lite före andra distar? Eller kommer systemd att bli en flopp? Verkar som många användare av Arch Linux ändå är nöjda numera även om det finns en del som klagar på bytet. Vi har liksom inget val om vi vill fortsätta använda Arch för de kommer officiellt sluta supporta det gamla initscipts och endast stödja systemd i framtiden.

Permalänk
Medlem

Körde in arch på min jobblaptop strax efter de bytte till systemd, glatt ovetande om att de bytt ens :). Är främst nöjd över hur trevligt det blev med arch även om det tog lite tid att få till allt som man ville.

Men kan inte påstå att det är bättre eller sämre för det jag använder laptopen till, däremot startar den snabbt (3 sekunder, ssd). Det som är bra med systemd är standardisering när det gäller konffiler och annat. Gillar inte att journalen sparas i binära filer (även om det är lätt att plocka ut texten).

Visa signatur

CCNP

Permalänk
Medlem
Skrivet av Schnitz:

En renodlad ny init-daemon med mer aggresiv parallellisering hade väl absolut varit intressant att ta en titt på. Däremot gillar jag inte utvecklingen alls med att eländet ska ta över en massa annat istället för att vara just en init daemon, så därför är systemd inget jag vill använda och supporta. Ja, jag tycker faktiskt att det är att gå ifrån Unix-principerna på ett negativt sätt. Trådskaparen slår ju huvudet på spiken med just "blaffa".
Jag tycker inte att förespråkarnas jämförelser med själva Linuxkärnan är riktigt väsentlig. Visst är kärnan monolitisk och visst har den vuxit med åren, men den har alltid varit monolitisk och är samtidigt i allra högsta grad anpassningsbar.

Gnu core utils distribueras ju också i en klump av olika binärer vanligtvis. Är de också ej unix?
För det är ju inte så att allt i systemd är en binär utan det är ju en mängd småprogram varav många kan användas även utanför systemd. När du ska suspenda kör ju systemd mestadels de specifika binärerna parallellt.
I teorin skulle ju distributionen kunna splitta ut dessa binärer i separata paket (som vissa redan gör med udev) gör det systemd mindre av en blaffa eller är det bara en lek med ord?

Permalänk
Medlem
Skrivet av ronnylov:

Efter att kört ett tag nu så tycker jag det känns ganska bra med systemd. Det som jag fortfarande tycker är lurigt är hur man bestämmer ordningen på när saker ska startas. Visst parallellisering är bra men det blir svårare att få full kontroll känner jag. Ibland startar en deamon för tidigt och så blir den fail och funkar inte. Startar man den sedan manuellt igen så funkar den. Jag vet att man kan sätta villkor på hur saker och ting beror på varandra men jämför man med den gamla rc.conf som fanns förut i Arch Linux så har det ändå blivit krångligare med att få saker att starta i rätt ordning (förr startades bara en sak i taget i en viss ordning så det var förstås lättare att styra det, men det gick långsammare). Men jag kanske behöver sätta mig in mer i hur det fungerar.

systemd har väll funktionalitet att avgöra när daemons är redo antingen genom fork, notify, eller ett dbus call. Men får systemd inte detta när det är nödvändigt så blir det ju problem.
En alternativ lösning är väll att använda unit socket filen för att få ett implicit beroende istället. Kanske kan det åtminstone gå runt problemet?

Citat:

Jag är på det hela taget ändå positiv till systemd och hoppas detta blir framtidens standard på Linux. Ubuntu har som sagt var valt en annan väg och det är lite trist tycker jag för många utvecklare gör så att det bara funkar i ubuntu och så struntar de i resten. Ett exempel är xbmc som om man kör det standalone på Arch Linux så funkar inte avstängningsfunktionen. Detta beror på att xbmc-utvecklarna ser det som "distributionsspecifikt" bara för att det funkar på ubuntu och därför struntar i problemet. Det är ju snarare ubuntu som valt gå en annorlunda väg och är distributionsspecifika... Samma sak med utvecklarna av "zfs on Linux". De ser också bara till att det funkar på ubuntu och struntar i att skapa en systemd service för zfs. Jag kör med rc.conf just för denna demonen men gillar det inte. Kanske är det att Arch Linux ligger lite före andra distar? Eller kommer systemd att bli en flopp? Verkar som många användare av Arch Linux ändå är nöjda numera även om det finns en del som klagar på bytet. Vi har liksom inget val om vi vill fortsätta använda Arch för de kommer officiellt sluta supporta det gamla initscipts och endast stödja systemd i framtiden.

Arch är ju extremt tidiga med att switcha helt till logind, inte ens
fedora har väll gjort det än?

Sen är ju inte sådana problem unika för systemd. "Upstart" skaparen (jobbar för google numera och inte Canonical) bloggade ju för ett tag sen om problemen med mjukvaru raid på ubuntu orsakade av att ingen maintainade de upstartspecifika patcharna.
http://netsplit.com/2012/10/30/goodbye-ubuntu/

Permalänk
Medlem

Synd att det ska bli sådan fragmentering i Linux världen. Hoppas canonical ändrar sig och byter de också.

Permalänk
Medlem
Skrivet av Rist:

Gnu core utils distribueras ju också i en klump av olika binärer vanligtvis. Är de också ej unix?
För det är ju inte så att allt i systemd är en binär utan det är ju en mängd småprogram varav många kan användas även utanför systemd. När du ska suspenda kör ju systemd mestadels de specifika binärerna parallellt.
I teorin skulle ju distributionen kunna splitta ut dessa binärer i separata paket (som vissa redan gör med udev) gör det systemd mindre av en blaffa eller är det bara en lek med ord?

Coreutils får väl antas vara unix, eftersom de är så etablerade som de är, men visst... personligen hade jag föredragit en uppdelning. Samtidigt får jag erkänna att jag är av åsikten att GNU/Hurd är det ultimata operativsystemet i teorin och i det sker ju uppdelningen (enligt principen "allt är en fil") närmast till absurdum.
Ja, jag får nog säga att en uppdelad paketering av systemd hade gjort det mer acceptabelt enligt mig och mindre blaff-aktigt. Uppenbarligen har du bättre koll på systemd än mig, men vad jag förstått utifrån det jag läst mig till så bidrar systemd till sämre möjligheter till full systemkontroll och anpassningar. Det anser jag är än värre än att ta ett steg från unix-principerna. Huruvida du tycker det stämmer får du gärna berätta, det är väldigt intressant med åsikter från någon som är lite mer insatt!

Visa signatur

Gentoo Desktop: Ryzen 3600X | 32 GB
Server: Intel G7400T
Commodore 64C + 1541u2

Permalänk
Medlem
Skrivet av Meto:

Synd att det ska bli sådan defragmentering i Linux världen. Hoppas canonical ändrar sig och byter de också.

Jag tycker det är bra att de defragmenterar. Fragmenterat har det varit alldeles för länge.

Permalänk
Medlem
Skrivet av saddam:

Visst kanske man går ifrån Unix principerna med Systemd, men denna Linux teknik verkar ju som vanligt, vara en klon av Solaris teknik, och eftersom Solaris som är ett riktigt Unix använder sin SMF, så är väl Systemd ok?

Tydligen pratar skaparen av Systemd ganska mycket om Solaris SMF, precis som Systemtap gänget pratar om Solaris DTrace, och BTRFS skaparen pratar om ZFS.
http://0pointer.de/blog/projects/systemd.html

UNIX(TM) inte UNIX... Solaris är ett riktigt Unix(TM) men inte ett riktigt Unix. Unix är en filosofi, unix är en tanke, unix är ett system. Unix(TM) är påse med pengar och "specifikation" som inte följer unix som filosofi.
Så nej, systemd är inte ok i unix men i unix(tm) så är det säkert guld och gröna skogar.

Visa signatur

Plan9 fan. In glenda we trust.

Permalänk

Jag tycker mig se att jag kan logga in tidigare på min fil/backup-server efter uppstart. Är fortfarande inte så insatt i systemd men det verkar i grunden vettigt och lättanvänt, så hittills tycker jag bra om det.

Permalänk
Avstängd

vem_stänger_av_sin_dator? Kör min på 24/7 nu i ca 130 dagar, inga problem.

Visa signatur

Student, Webbutvecklare, Dj - Macbook Air i7
Nexus 7: Paranoid - 4.2.1 - M-Kernel - (500/700 GPU/LP) -200mv UV

Permalänk
Medlem
Skrivet av aekblom:

vem_stänger_av_sin_dator? Kör min på 24/7 nu i ca 130 dagar, inga problem.

Det är väll ganska självklart att man stänger av sin dator när man inte använder den. Att slänga ut tusenlappar på ström är inget jag tycker är roligt iaf.
Då är det bra ifall den bootar på 5 sekunder med alla fönster man hade igång uppe igen!

Håll dig till topic?

Permalänk
Avstängd
Skrivet av =JoNaZ=:

Det är väll ganska självklart att man stänger av sin dator när man inte använder den. Att slänga ut tusenlappar på ström är inget jag tycker är roligt iaf.
Då är det bra ifall den bootar på 5 sekunder med alla fönster man hade igång uppe igen!

Håll dig till topic?

Känns som detta är topic. Läs TS inlägg.

Visa signatur

Student, Webbutvecklare, Dj - Macbook Air i7
Nexus 7: Paranoid - 4.2.1 - M-Kernel - (500/700 GPU/LP) -200mv UV

Permalänk
Medlem

Använd hibernate, så återställer du systemet utan att förbruka ström. Det och sleep är förövrigt ytterligare något som går snabbare med systemd i och med parallelliseringen av processerna