Tag Archives: tips

apt-get update

Et kort lite tips hvis du bruker apt-get mye: hvis du bruker en relativt ny utgave av distroen din kan du sannsynligvis bruke apt istedenfor. Apt er fire tegn kortere å skrive og fungerer som forventet for alle de vanligste valgene:
apt-get updateapt update
apt-get dist-upgradeapt dist-upgrade
osv.
Som en ekstra bonus viser apt teksten i ulike farger for å indikere fremgang.

Så hvis du sitter på Ubuntu 14.04 eller nyere, kan det være kjekt å gå over til apt fremfor apt-get.

Jeg er usikker på om apt vil ta over/pakke inn all funksjonaliteten til apt-get på sikt, men inntil videre er det fortsett et par valg som kun finnes i apt-get. Det jeg har merket mest er at jeg fortsatt må kjøre apt-get autoremove, men det er ikke noe jeg gjør ofte nok til at det er plagsomt.

Ukens kommando: df -i

For en stund tilbake støtte jeg på et sært problem. Jeg forsøkte å installere noe, men Ubuntu fortalte meg at det ikke var mulig siden harddisken var full. Det hørtes veldig rart ut, siden jeg kunne se at harddisken hadde mer enn nok ledig plass. Jeg lurte på noe kanskje rapporterte feil mengde ledig plass, så jeg dobbeltsjekket med nautilus og df -h som viste de samme tallene. (For de som ikke kjenner den fra før, kommandoen df viser størrelse, brukt og ledig plass på harddiskene. Jeg bruker flagget -h for å få med benevning som er litt enklere for mennesker, feks. M for Megabyte, G for Gigabyte, så jeg slipper å regne sammen bytes selv.)

Etter å ha tenkt på hva dette kunne skyldes en stund kom jeg på inoder. Hva er en inode? Kort fortalt er en inode metadata om et område på disken. Den vil typisk inneholde informasjon om filstørrelse, eierskap, rettigheter og lignende. Hver fil eller mappe har en tilhørende inode som peker til den og holder på metainformasjonen om den.

Det jeg husket jeg hadde hørt om inoder var at det er et gitt antall av dem. Hvis man legger til mange nok (spesielt små) filer vil man før eller senere gå tom for inoder for å holde orden på disse. Denne situasjonen hørtes veldig teoretisk ut, så jeg hadde ikke tenkt over det som en reell problemstilling. Likevel, det kunne jo muligens forklare feilmeldingen jeg fikk.

Etter litt søking fant jeg ut hvordan jeg kan se hvor mange inoder som er i bruk. Det viste seg fort at df også har støtte for dette; df -i vil vise antall, brukte og ledige inoder. Maskinen som rapporterte full disk viste seg å ha mye ledig plass i Gigabytes, men kun et fåtall tilgjengelige inoder for å kunne opprette nye filer. Aha! Så varslet om full harddisk betydde i dette tilfellet egentlig for få inoder til å legge til nye filer (som jo forsåvidt betyr at den er full).

Nå som jeg visste hva problemet var, fjernet jeg fjernet en del eldre pakker som jeg ikke lenger trengte. Dette frigjorde flere inoder, som jeg verifiserte med df -i, og jeg kunne gå videre med installasjon av programmene jeg ønsket. Så hvis du får feilmeldinger om at harddisken er full, selv om det ser ut til å være mye ledig plass på den, kan det være en ide å sjekke om det er ledige inoder som er problemet.

PS. Det er ingen garantier for at dette blir en ukentlig spalte, men jeg likte navnet idet jeg skrev overskriften.

Hvordan få fine farger i git

Mange prosjekter bruker git til versjonskontroll, så de fleste utviklere har brukt det på et eller annet tidspunkt. Dessverre (og til min irritasjon) ser det ut som standardinnstillingene til git-klienten bruker samme farge på all utdata. Den har heldigvis innebygget støtte for bruk av flere farger der det er hensiktsmessig, som er noe av det første jeg slår på når jeg setter opp git på et nytt system.

Med farger får vi blant annet tydeligere markering av hvilken gren vi står på, men den viktigste fordelen er at differ (både endringer som ikke er commitet og eldre) blir fargekodet. I eksempelbildet ser vi klart hvilke linjer som er fjernet, lagt til eller forblir uendrete siden de er merket henholdsvis rødt, grønt og hvit (standard). Dette gjør det mye klarere og lettere å få oversikt sammenlignet med å manuelt forsøke å se hva som fjernes eller legges til i et sett med endringer der alle er listet med samme farge .

Eksempel på git med fargerSå som en huskelapp til meg selv og andre, kjør:

git config --global color.ui true

for å  slå på farger i git-klienten. Det er også mulig å spesifisere mer detaljert i hvilke situasjoner du ønsker farger og ikke, se dokumentasjonen for detaljer.

 

Hjelp, hva gjør jeg hvis en virtuell maskin bruker alt minnet mitt?

Jeg liker å kunne bruke virtuelle maskiner (fortrinnsvis Virtualbox), siden de gir meg mulighet til å teste ut forskjellige programmer eller andre ting uten at det forstyrrer oppsettet på maskinen jeg jobber på til vanlig. Dette gjør det enklere å eksperimentere mer fritt, og enklere å gå tilbake til slik det var før hvis noe går skeis.

Men, fra tid til annen, har jeg hatt problemer med at jeg har startet en virtuell maskin for mye. Enten fordi jeg hadde tenkt å se hvordan de virtuelle maskinene oppførte seg i nettverk eller rett og slett fordi jeg glemte jeg hadde andre kjørende. Særlig hvis det er lite minne (RAM), er det lett å ende opp i situasjoner hvor ting går såpass tregt at de tilsynelatende fryser vertssystemet. På dette tidspunktet er det selvfølgelig mulig å slå maskinen av og på igjen, men da mister jeg alt jeg har lagret, samt det tar ekstra tid. I tillegg er det ikke nødvendig, siden det er fullt mulig å bruke VirtualBox via kommandolinjen.

Si du kjører Ubuntu (eller en annen Linux-distro) og du nettopp har startet en ny virtuell maskin som sammen med de andre tar opp mesteparten av minnet og tilsynelatende fryser systemet dit. Trykk Ctrl+Alt+F1 for å komme til en annen virtuell terminal (hvordan du kommer tilbake igjen, tar vi for oss senere). Der vil du bli møtt av en svart skjerm med hvit skrift der du kan logge deg inn med brukernavn og passord. Etter en vellykket innlogging, vil du ha tilgang til en kommandolinje der du kan skrive inn kommandoer.

VirtualBox har en ypperlig klient for kommandolinjen som så vidt jeg vet kan gjøre alt det samme som det grafiske programmet. Kjør vboxmanage for å se alle mulighetene som er tilgjengelig. Det vi er interessert i nå er muligheten til å liste hvilke maskiner som kjører. vboxmanage list runningvms vil skrive ut en liste over de maskinene som kjører for øyeblikket. F. eks.
"maskin1" {masse-tall-og-bokstaver}
"maskin2" {masse-tall-og-bokstaver}

Vi har dermed navnene på de to maskinene som kjører. La oss si vi ønsker å pause den første, “maskin1”. Dette gjøres ved å kjøre følgende kommando: vboxmanage controlvm "maskin1" pause. Hvis du kjører vboxmanage controlvm ser du hvilke andre endringer du kan gjøre med maskinen, så lenge du oppgir navnet eller iden på maskinen der endringene skal gjøres. For å gå tilbake til det grafiske skrivebordet der vi kom fra, trykk Ctrl+Alt+F7. (Husk vi brukte Ctrl+Alt+F1 for å komme hit, og det er lignene terminaler fordelt på de forskjellige F-tastene).

Tilbake på skrivebordet bør ting fungere litt bedre siden den virtuelle maskinen som ble pauset opptar mindre av minnet i bruk. Du kan nå velge å stoppe maskinen helt, eller om du vil lukke andre programmer for å kunne kjøre ting samtidig. (Husk forøvrig at når du er ferdig bør du logge ut fra terminalen på Ctrl+Alt+F1 ved å bruke kommandoen exit.)