Den här intressanta artikeln beskriver hur man bygger en NAS som heter duga.
http://blog.backblaze.com/2011/07/20/petabytes-on-a-budget-v2-0revealing-more-secrets/
Det är företaget backblaze som visar hur de bygger sina servar för att kunna tillhandahålla billig lagring.
måndag 25 juli 2011
lördag 16 juli 2011
Problem with hard drive upgrade on Macbook Pro 2.53 GHz
Problem:
Macbook pro 2.53 GHz (unibody 15 inch, late 2009, macbook pro5,4) freezes and beachballs after upgrading to a larger harddrive.
The solution:
Force the harddrive to use SATA1, not SATA2. Put a jumper on the harddrive, locking it down to use the older SATA standard even if the drive and the computer handles SATA2 officially. This avoids the software bug in Mac Os X causing the problem.
The details:
I had a lot of problem with upgrading the hard drive from 250 GB to 750GB on my macbook pro 2.53 GHz (late 2009, macbookpro5,4). I got a lot of beachballing, freezes etc.. In fact, I had to install to a usb drive and then clone the installation. Running Ubuntu on the computer was no problem at all, which excluded hardware problem. Also, memtest86+ passed without remarks.
I contacted the store I bought the computer from, Apple support and two firms specialized in repairing Apple computers. None of them had ever heard of such a problem. In fact, they used hard drives of the same manufacturer when they upgraded clients computers.
Googling revealed that other users also had problems. Suggested solutions included disabling the shock sensor, adjusting the power scheme or downgrading the efi firmware. The last solution needs installing an unsupported file from some unknown source, which I am not willing to do.
The first two solutions made the situation better, but not good enough.
It turned out the problem is that this particular hardware version does not work with SATA2 and Mac OS X. The problem should really be fixed in Mac Os X, but Apple does not want to do that.
The support for SATA2 was added with the newer firmware, which unfortunately brings the bad behaviour.
Therefore, one has to somehow force the hard drive into using SATA1. Luckily, one can set a jumper on the hard drive which does just this. Problem solved.
The computer now works brilliant. Hopefully someone will google the same symptom, find this page and solve their problem instead of wasting time like I did!
Macbook pro 2.53 GHz (unibody 15 inch, late 2009, macbook pro5,4) freezes and beachballs after upgrading to a larger harddrive.
The solution:
Force the harddrive to use SATA1, not SATA2. Put a jumper on the harddrive, locking it down to use the older SATA standard even if the drive and the computer handles SATA2 officially. This avoids the software bug in Mac Os X causing the problem.
The details:
I had a lot of problem with upgrading the hard drive from 250 GB to 750GB on my macbook pro 2.53 GHz (late 2009, macbookpro5,4). I got a lot of beachballing, freezes etc.. In fact, I had to install to a usb drive and then clone the installation. Running Ubuntu on the computer was no problem at all, which excluded hardware problem. Also, memtest86+ passed without remarks.
I contacted the store I bought the computer from, Apple support and two firms specialized in repairing Apple computers. None of them had ever heard of such a problem. In fact, they used hard drives of the same manufacturer when they upgraded clients computers.
Googling revealed that other users also had problems. Suggested solutions included disabling the shock sensor, adjusting the power scheme or downgrading the efi firmware. The last solution needs installing an unsupported file from some unknown source, which I am not willing to do.
The first two solutions made the situation better, but not good enough.
It turned out the problem is that this particular hardware version does not work with SATA2 and Mac OS X. The problem should really be fixed in Mac Os X, but Apple does not want to do that.
The support for SATA2 was added with the newer firmware, which unfortunately brings the bad behaviour.
Therefore, one has to somehow force the hard drive into using SATA1. Luckily, one can set a jumper on the hard drive which does just this. Problem solved.
The computer now works brilliant. Hopefully someone will google the same symptom, find this page and solve their problem instead of wasting time like I did!
torsdag 16 juni 2011
Hur lång kan en lina vara innan den brister av sin egen tyngd?
I en intressant diskussion vid kaffeautomaten häromdagen väcktes min nyfikenhet. Vi diskuterade om man kunde bygga en pyramid oändligt hög. Eftersom vikten är proportionell mot höjden upphöjt till tre, som fördelas på basarean som är proportionell mot höjden upphöjt till två kommer materialbelastningen att öka linjärt med höjden. Alltså finns det en (ändlig) gräns där materialet inte kan bära en högre pyramid. Så nej, det går inte.
Relaterat är hur långt ett rep kan vara innan det går sönder av sin egen vikt (tänk till exempel på vajrar till en hiss i en gruva). Man brukar begränsa sig till att man har ett konstant tvärsnitt, dvs att linan är lika tjock hela vägen. Men om man tillåter arean att ändras utefter linans längd? Går det att göra på ett sådant sätt att man kan göra en längre lina?
Det visar sig att det går. Tänk att man låter arean variera som A(x)=A0*e^kx där A0 är basarean, k är en konstant och x är längden längs med linan. Volymen av linan från minus oändligheten till x är då rho*A0*e^kx/k där rho är linans densitet. Med homogent tyngdkraftsfält g fås då materialpåkänning sigma=rho*g/k som är konstant. Om man bestämmer sigma och känner till materialets densitet rho kan man då räkna ut vad k ska vara för att linan ska hålla. För kevlar, ett lätt och starkt material blir det k=4e-6 1/m om man sätter in brottgränsen.
Detta leder oss till rymdhissen! Det finns en ide om att man sätter en vikt ute i geostationär omloppsbana runt jorden, dvs att den ser ut att vara på samma ställe på himlen jämt. Om man sätter den tillräckligt långt ut är centripetalaccelerationen starkare än tyngdkraften. Tillräckligt långt ut inträffar vid R=1.7 GM. Om man sätter sin kevlarlina dit (och antar homogen gravitation vilket är ett värre fall än vad det egentligen skulle vara, centripetalaccelerationen och den minskade gravitationen högre upp inverkar positivt) så har den ca 980 gånger större tvärsnittsarea än vid jordytan. Det är alltså ca 30 gånger större diameter.
Tänk vad häftigt att kunna åka hiss upp i rymden. Kanske inte så kul när överdelen av linan träffas av en meteorit...
Att ha arean varierande exponentiellt är optimalt, eftersom jag visat ovan att man då kan få konstant påkänning utefter hela linans längd. Ingen del av linan är påkänd mer än någon annan. Men finns det någon annan funktion för lintjockleken som också gör att man kan uppnå oändlig längd?
Sen undrar jag om det finns en analytisk lösning för ovanstående även om man räknar med inverkan av gravitationens avtagande samt centripetalaccelerationen. Hmm.
Relaterat är hur långt ett rep kan vara innan det går sönder av sin egen vikt (tänk till exempel på vajrar till en hiss i en gruva). Man brukar begränsa sig till att man har ett konstant tvärsnitt, dvs att linan är lika tjock hela vägen. Men om man tillåter arean att ändras utefter linans längd? Går det att göra på ett sådant sätt att man kan göra en längre lina?
Det visar sig att det går. Tänk att man låter arean variera som A(x)=A0*e^kx där A0 är basarean, k är en konstant och x är längden längs med linan. Volymen av linan från minus oändligheten till x är då rho*A0*e^kx/k där rho är linans densitet. Med homogent tyngdkraftsfält g fås då materialpåkänning sigma=rho*g/k som är konstant. Om man bestämmer sigma och känner till materialets densitet rho kan man då räkna ut vad k ska vara för att linan ska hålla. För kevlar, ett lätt och starkt material blir det k=4e-6 1/m om man sätter in brottgränsen.
Detta leder oss till rymdhissen! Det finns en ide om att man sätter en vikt ute i geostationär omloppsbana runt jorden, dvs att den ser ut att vara på samma ställe på himlen jämt. Om man sätter den tillräckligt långt ut är centripetalaccelerationen starkare än tyngdkraften. Tillräckligt långt ut inträffar vid R=1.7 GM. Om man sätter sin kevlarlina dit (och antar homogen gravitation vilket är ett värre fall än vad det egentligen skulle vara, centripetalaccelerationen och den minskade gravitationen högre upp inverkar positivt) så har den ca 980 gånger större tvärsnittsarea än vid jordytan. Det är alltså ca 30 gånger större diameter.
Tänk vad häftigt att kunna åka hiss upp i rymden. Kanske inte så kul när överdelen av linan träffas av en meteorit...
Att ha arean varierande exponentiellt är optimalt, eftersom jag visat ovan att man då kan få konstant påkänning utefter hela linans längd. Ingen del av linan är påkänd mer än någon annan. Men finns det någon annan funktion för lintjockleken som också gör att man kan uppnå oändlig längd?
Sen undrar jag om det finns en analytisk lösning för ovanstående även om man räknar med inverkan av gravitationens avtagande samt centripetalaccelerationen. Hmm.
lördag 11 juni 2011
Hur en hårddisk fungerar
Otroligt häftigt att en hårddisk kan lagra så mycket, så tillförlitligt till en så låg kostnad. Den här videon berättar lite om hur det går till under skalet!
söndag 15 maj 2011
Slumpmässig information 7
lördag 14 maj 2011
Program för att organisera bilder
Nästan alla har massa digitala bilder. Själv har jag i storleksordningen tiotusen. De behöver organiseras!
Jag har en mappstruktur för att lagra bilderna vilket gör att det är lätt att hitta bilder efter datum. Jag kan se bilderna och bläddra snabbt med verktyg jag redan har. Strukturen är lätt att backupa och överblicka. Jag skulle nu vilja ha fler funktioner: tagga med position, bilder, nyckelord och att lägga till beskrivningar. En bild säger mer än tusen ord, men ibland gör ord att bilden kan förstås och beskriva allt roligt och intressant som ofta utspelar sig när man fotograferar. Det är just såna här uppgifter som ett bildhanteringsprogram kan utföra.
Jag använder idag finders inbyggda visning på mac os x respektive kuickshow på linux/kde. Båda dessa är väldigt snabba att visa foton med, det går väldigt fort att bläddra mellan foton.
Nu kommer det svåra: jag vill kunna organisera foton från flera datorer, från flera användare. Jag vill kunna byta program i framtiden. Och så vidare...
Jag läser på i digikams manual som har en hel del att säga om arkivering, format, varför metadata ska bäddas in i filer osv. Väldigt läsvärt! Hittas som pdf via "documentation"-länken på digikams hemsida. En intressant diskussion om huruvida metadata ska lagras i filer, databas eller båda finns här.
Verkar som att en approach där taggar etc lagras direkt i bilderna är vettig. Tyvärr betyder det att filerna ändras, jag hade hellre sett att en separat metadatafil skapades per bild.
Jag har några alternativ.
Picasa
Jag testar picasa på mac. Det går att köra både på mac, windows och linux. Det går att låta bilderna ligga där jag själv vill, dvs att programmet ej kopierar bilderna till sitt eget bibliotek. Det går att tagga, exportera album, lägga in personer, göra (virtuella) album.
Taggar hamnar i originalfilen, dvs filen ändras när man jobbar med taggning. Övrig information hamnar någon annanstans, skilt från fotokatalogen. Aj aj. Det blir inte bättre av att det finns buggrapporter om att redian existerande exifdata ej behålls korrekt i filerna.
Eftersom picasa ägs av google trodde jag att sökfunktionen skulle vara superb. Det är den inte. T ex lyckades jag inte leta fram foton från ett visst datumintervall, något av de viktigaste vad gäller sökning. Inte heller lyckades jag kombinera ihop sökningar, t ex en viss tagg och ett visst datum.
Proogrammet känns rätt segt, som att man inte kommit hela vägen fram. Det går inte att markera flera foton och utföra samma åtgärd t ex (på vissa ställen i programmet går det). Det känns inte som ett program som utvecklarna använder själv, helt enkelt. Det är mer krut lagt på antalet funktioner än perfekt funktion på det grundläggande. Gränssnittet är splittrat och känns rörigt, även om det är väldigt snyggt.
Ansiktsigenkänningen är helt fantastisk och riktigt häftig. Helt otroligt att kunna leta fram ansikten ur en fotosamling.
Det går också att exportera till statiska html-gallerier, en väldigt praktisk funktion.
Såvida det inte går att synkronisera metadata, är picasa inte ett alternativ. För att binda upp mig till ett program måste det vara sagolikt perfekt.
Shotwell
Jag testar Shotwell 0.6 via Debian Squeeze. Riktigt bra förstaintryck - lämnar originalen intakta, sparar informationen i en separat databas, smidig navigering, snabbt att jobba med. Snyggt interface, listning på olika sätt. Verkar mycket lovande!
Sen det dåliga.
Inget stöd för beskrivningar - varför inte? Kan det finnas i senare versioner? Utan det faller detta alternativ helt för mig.
Digikam
Jag testar Digikam 1.2.0 via Debian Squeeze. Första konfigurationen låter mig välja att skriva taggar etc i en separat fil och lämna originalen intakta. Bra! Programmet är väldigt komplext - mer komplext än picasa. Sökfunktionen är helt fantastisk och gör att man verkligen kan hitta det man vill (kombinationer av taggar, datum etc). Det går att lägga in beskrivningar av foton och sätta betyg. Export går bra.
Det går bra att låta bildfilerna ligga readonly på nätverk utan att digikam kopierar över filerna. Man måste bara avnända det som kallas nätverksenhet i digikam. Det går bra att bildkatalogen inte alltid finns. Det går bra att peka på en symbolisk länk. Det går däremot inte att ha en relativ sökväg.
Det dåliga:
tangentbodgensävarna är ett mysterium - hur ska man jobba effektiv om man behöver flytta fält med musen varje gång man vill skriva en kommentar? det verkar gå att konfigurera detta, får se om det går att göra något åt det.
Slutsats
Det får bli digikam och en skräddarsyd lösning för att synkronisera dess bilddatabas. Programmet är helt överlägset alternativen. Jag ska försöka beskriva lösningen i ett separat inlägg.
Jag har en mappstruktur för att lagra bilderna vilket gör att det är lätt att hitta bilder efter datum. Jag kan se bilderna och bläddra snabbt med verktyg jag redan har. Strukturen är lätt att backupa och överblicka. Jag skulle nu vilja ha fler funktioner: tagga med position, bilder, nyckelord och att lägga till beskrivningar. En bild säger mer än tusen ord, men ibland gör ord att bilden kan förstås och beskriva allt roligt och intressant som ofta utspelar sig när man fotograferar. Det är just såna här uppgifter som ett bildhanteringsprogram kan utföra.
Jag använder idag finders inbyggda visning på mac os x respektive kuickshow på linux/kde. Båda dessa är väldigt snabba att visa foton med, det går väldigt fort att bläddra mellan foton.
Nu kommer det svåra: jag vill kunna organisera foton från flera datorer, från flera användare. Jag vill kunna byta program i framtiden. Och så vidare...
- stöd för nyckelord, bildtext och beskrivningar
- synkroniserbart via filsystem: det sätt informationen lagras på ska vara möjligt att dela till flera datorer, t ex en databasfil som ligger någonstans i filträdet.
- bevarar befintlig mappstruktur, dvs kopierar inte foton till egen plats. Det ska organisera fotona, inte ta över dom.
- stöd för linux och mac, eller att det går att använda olika program för att hantera samma data
- data på ett format som går att exportera alt. använda, inför ett eventuellt byte av program
- ej kräva nätanslutning vid användning
- ingen begränsning på antal bilder eller storlek
- rimligt effektivt att arbeta med, ska inte behöva få musarm eller bli uttråkad av att det går segt
- sökning på tid eller nyckelord
- taggning med personer
- taggning av plats
- betygsättning, för att kunna plocka ut några riktigt bra bilder
- export till htmlgalleri
- open source
Jag läser på i digikams manual som har en hel del att säga om arkivering, format, varför metadata ska bäddas in i filer osv. Väldigt läsvärt! Hittas som pdf via "documentation"-länken på digikams hemsida. En intressant diskussion om huruvida metadata ska lagras i filer, databas eller båda finns här.
Verkar som att en approach där taggar etc lagras direkt i bilderna är vettig. Tyvärr betyder det att filerna ändras, jag hade hellre sett att en separat metadatafil skapades per bild.
Jag har några alternativ.
- digikam
- shotwell
- picasa
- "webbaserat" på lokal server (förslag?) eller kanske central server
- programmet gallery
- något av det på http://directory.fsf.org/category/pa/
- photo organizer
- http://coppermine-gallery.net/
Picasa
Jag testar picasa på mac. Det går att köra både på mac, windows och linux. Det går att låta bilderna ligga där jag själv vill, dvs att programmet ej kopierar bilderna till sitt eget bibliotek. Det går att tagga, exportera album, lägga in personer, göra (virtuella) album.
Taggar hamnar i originalfilen, dvs filen ändras när man jobbar med taggning. Övrig information hamnar någon annanstans, skilt från fotokatalogen. Aj aj. Det blir inte bättre av att det finns buggrapporter om att redian existerande exifdata ej behålls korrekt i filerna.
Eftersom picasa ägs av google trodde jag att sökfunktionen skulle vara superb. Det är den inte. T ex lyckades jag inte leta fram foton från ett visst datumintervall, något av de viktigaste vad gäller sökning. Inte heller lyckades jag kombinera ihop sökningar, t ex en viss tagg och ett visst datum.
Proogrammet känns rätt segt, som att man inte kommit hela vägen fram. Det går inte att markera flera foton och utföra samma åtgärd t ex (på vissa ställen i programmet går det). Det känns inte som ett program som utvecklarna använder själv, helt enkelt. Det är mer krut lagt på antalet funktioner än perfekt funktion på det grundläggande. Gränssnittet är splittrat och känns rörigt, även om det är väldigt snyggt.
Ansiktsigenkänningen är helt fantastisk och riktigt häftig. Helt otroligt att kunna leta fram ansikten ur en fotosamling.
Det går också att exportera till statiska html-gallerier, en väldigt praktisk funktion.
Såvida det inte går att synkronisera metadata, är picasa inte ett alternativ. För att binda upp mig till ett program måste det vara sagolikt perfekt.
Shotwell
Jag testar Shotwell 0.6 via Debian Squeeze. Riktigt bra förstaintryck - lämnar originalen intakta, sparar informationen i en separat databas, smidig navigering, snabbt att jobba med. Snyggt interface, listning på olika sätt. Verkar mycket lovande!
Sen det dåliga.
Inget stöd för beskrivningar - varför inte? Kan det finnas i senare versioner? Utan det faller detta alternativ helt för mig.
Digikam
Jag testar Digikam 1.2.0 via Debian Squeeze. Första konfigurationen låter mig välja att skriva taggar etc i en separat fil och lämna originalen intakta. Bra! Programmet är väldigt komplext - mer komplext än picasa. Sökfunktionen är helt fantastisk och gör att man verkligen kan hitta det man vill (kombinationer av taggar, datum etc). Det går att lägga in beskrivningar av foton och sätta betyg. Export går bra.
Det går bra att låta bildfilerna ligga readonly på nätverk utan att digikam kopierar över filerna. Man måste bara avnända det som kallas nätverksenhet i digikam. Det går bra att bildkatalogen inte alltid finns. Det går bra att peka på en symbolisk länk. Det går däremot inte att ha en relativ sökväg.
Det dåliga:
tangentbodgensävarna är ett mysterium - hur ska man jobba effektiv om man behöver flytta fält med musen varje gång man vill skriva en kommentar? det verkar gå att konfigurera detta, får se om det går att göra något åt det.
Slutsats
Det får bli digikam och en skräddarsyd lösning för att synkronisera dess bilddatabas. Programmet är helt överlägset alternativen. Jag ska försöka beskriva lösningen i ett separat inlägg.
Normalisering av Unicode
Det förträffliga programmet iconv stöder inte konvertering mellan olika normaliseringsformer, såsom (det också förträffliga programmet) convmv gör.
Det jag vill göra är att konvertera en text från unicode normaliseringsform D (mac os x) till normaliseringsform C (resten av världen:-). Det lättaste är att öppna filen i en texteditor och ta spara som, men det här är något jag ska göra i ett script så jag vill ha ett ickeinteraktivt program.
Lite undersökning av möjligheterna i perl pekar i riktningen Normalize. Perl är hyfsat väldefinierat vad gäller teckenkodning till skillnad från php som är besvärligt eftersom det inte brytt sig om teckenkodning förrän på senare tid. Tyvärr får jag inte Normalize att fungera som avsett!
Som tur är gav mig källkoden till convmv (som är skrivet i perl) en bra hint i en kommentar i texten. Vid närmare läsning visar det sig att det är lite si och så med buggigheten i perl vad gäller dessa funktioner. Eftersom jag kör lite olika perlversioner här och var tröttnar jag och vänder mig till php istället.
Såhär ser det ut på mac os x (med macports version av php, efter att ha installerat php5-intl via macports) (reservation för att vissa tecken äts upp av bloggeditorn)
Anledningen till att jag håller på med det här är att jag håller på att utarbeta ett system för att synkronisera bildorganiseringsprogram mellan flera datorer. Mac använder normaliseringsform D så det blir problem när filnamn inte stämmer.
Det jag vill göra är att konvertera en text från unicode normaliseringsform D (mac os x) till normaliseringsform C (resten av världen:-). Det lättaste är att öppna filen i en texteditor och ta spara som, men det här är något jag ska göra i ett script så jag vill ha ett ickeinteraktivt program.
Lite undersökning av möjligheterna i perl pekar i riktningen Normalize. Perl är hyfsat väldefinierat vad gäller teckenkodning till skillnad från php som är besvärligt eftersom det inte brytt sig om teckenkodning förrän på senare tid. Tyvärr får jag inte Normalize att fungera som avsett!
Som tur är gav mig källkoden till convmv (som är skrivet i perl) en bra hint i en kommentar i texten. Vid närmare läsning visar det sig att det är lite si och så med buggigheten i perl vad gäller dessa funktioner. Eftersom jag kör lite olika perlversioner här och var tröttnar jag och vänder mig till php istället.
Såhär ser det ut på mac os x (med macports version av php, efter att ha installerat php5-intl via macports) (reservation för att vissa tecken äts upp av bloggeditorn)
#!/opt/local/bin/php
$fp = fopen('php://stdin', 'r');
while($str=fgets($fp)) {
echo Normalizer::normalize( $str, Normalizer::FORM_C );
}
?>
Anledningen till att jag håller på med det här är att jag håller på att utarbeta ett system för att synkronisera bildorganiseringsprogram mellan flera datorer. Mac använder normaliseringsform D så det blir problem när filnamn inte stämmer.
Prenumerera på:
Inlägg (Atom)