För något år sedan lyckades jag tappa Alldeles För Många Oersättliga Filer, framför allt nästan allt av runt 2 års foton. Det var inte jätteskoj.
Visserligen tar jag backup från min vanliga dator till min server, men eftersom de står i samma lägenhet så är det inte en så bra lösning. Med diskar på 1-2 TB som har överkomlig prislapp och internetanslutningar som faktiskt är lite fart på, skulle jag vilja göra så här:
- Jag och Person X köper varsin disk. USB om det funkar i Linux (lite enklare hotswap), annars SATA som dessutom är lite billigare (per GB).
- Konton skapas på respektive burk, för ssh-access med den nya hårdisken som loginbibliotek. Med chroot, så blir det ännu bättre.
- Jag synkar mina saker till Person X, och Person X synkar till mig.
- Ett konto hos dyndns.com gör att domännamnet kan ändras automatiskt när man får en ny IP-adress.
- Med crontab kan backuper göras godtyckligt ofta, och med “
rsync --bwlimit” kan man hålla nere bandbredden lite grand.
Så, är det någon här som har samma behov, och har lust att vara denna Person X?
June 23rd, 2010
Posted by
Daniel Brahneborg |
blogg |
4 comments
I höstas bytte jag ut min Cardo Scala Rider Q2 mot en Interphone F4, på grund av problem med blutoothkopplingen till mobilen. Interphone är väldigt mycket duktigare, och kräver inte att man ständigt parar om apparaten med mobilen, så jag var nöjd och glad. Tills i lördags.
Tja, eller tills i mars eller så när det visade sig att ena luren var död, men det var lätt åtgärdat genom att lämna in den på service. Garanti ftw.
I lördags skulle vi iväg några stycken på utflykt till Sigtuna. Jag och sambon åkte först på hojen, och de andra bakom i bil. Jag knappade in adressen till restaurangen i mobilens GPS, aktiverade dialogläget med sambon, och började köra. Minutrarna gick, men det kom aldrig några körinstruktioner från GPS’en.
Då visade det sig att dialogläget tar prioritet, så GPS-instruktionerna kommer aldrig fram. Stänger man av dialogläget så funkar det precis som det ska. Jätteskoj.
Cardon gjorde tvärtom, vilket var ofantligt mycket trevligare. Då kunde man sitta i dialogläget hela tiden, och då och då bli avbruten av ett “sväng höger om 300 meter” då och då. Tyvärr slutade telefonkontakten fungera helt och hållet efter en timme, men ändå.
Sista biten fick jag därför stänga av kommunikationen med sambon, för att kunna höra vad GPS’en hade att säga. Det här ser jag som ett rejält konstruktionsfel, men knappast något som jag lär kunna få några pengar tillbaka för efter nästan ett år.
Nu har det dykt upp en Scala Rider G4, med ett par ändringar. Framför allt är blutoothversionen ändrad från 2.0 till 2.1, vilket visar att de faktiskt har gjort någonting på den fronten. Sedan klarar den kommunikation över längre avstånd, men det spelar ju ingen roll så länge man sitter på samma hoj. Å andra sidan är den inte gratis, och jag kan inte hålla på och köpa nya komsystem hela tiden. Det är bara jäkligt störande att aldrig få något som faktiskt fungerar som det ska, utan bara strular på det ena eller andra sättet.
Rekommendationen blir därför, just nu:
- Om du kör ensam och bara vill ha koppling till mobil och GPS, köp en Scala Q2 eller G4.
- Om du har en Nokia, köp istället en Interphone F4.
- Om du vill kunna prata med din passagerare eller kompisen på en annan hoj, prova Scala G4.
Att kunna snacka samtidigt som man kör är faktiskt väldigt trevligt. Speciellt för mig som är så obotligt snacksalig. *host*
June 14th, 2010
Posted by
Daniel Brahneborg |
blogg |
2 comments
Efter ganska många försök lyckades jag ju fixa en e-legitimation på min Mac förra året, så jag kunde deklarera på nätet. Nu börjar det ju bli dags igen, så jag surfade iväg till Skatteverket, och försökte logga in med “Bank-ID”. Programmet “Personal” drar igång, men dropdownen där jag ska välja certifikat är tom och disablad. Jaha, det gick ut i mars i år. Skumt.
Enligt den fina broschyren skulle det gå att logga in via någon kod som skulle stå högst upp på deklarationsblanketten. Jag letade ett tag, men den fanns helt enkelt inte. Lite läsande avslöjade att det var på grund av att jag har en enskild firma, så då är de lite bråkigare.
Jag surfade då iväg till SEB för att den vägen skapa en ny e-legitimation. Logga in, knappa in kod nr 2, och så iväg till Telia. Där fick jag ett felmeddelande om att jag inte hade installerat “Net ID”. Say what? Det fanns en liten länk, så jag laddade hem det och installerade. Iväg till Telia igen, varvid den gnällde på samma sak igen.
Ok, omstart av Firefox, in på SEB, verifiera med kod nr 2, och så till Telia igen. Det gick fortfarande inte, så jag ringde Telias support, som snällt nog hade öppet sent på kvällen. Efter att ha plockat bort alla Telias cookies så gick det bättre, men jag kunde fortfarande inte skapa något e-leg.
Killen där rekommenderade mig till slut att köra ett script som han mailade, starta om datorn, och installera Net ID en gång till. Då skulle det fungera bättre. Sinnesjukt.
Någon dator startade jag inte om, men jag startade om Firefox i alla fall. Genom att starta Net ID via Findern och inte direkt från kommandoraden, fick jag faktiskt upp en flik i Firefox med lite inställningar och annat. Framsteg!
Sedan iväg till SEB igen, och vidare till Telia. Se där, nu slutade den gnälla på att Net ID inte fanns. Jag fick något ytterligare felmeddelande som jag har glömt bort, men efter att ha tagit bort något tillfälligt “token” i Net ID och försökt igen, gick det bättre. Ett par felmeddelanden senare, och några ytterligare hopp mellan Telia och Net ID-fliken, så hade jag faktiskt fått min e-legitimation!
Tillbaka till Skatteverket. Och se där, jag kom in!
I helgen ska jag ta reda på vilka siffror jag ska skriva in. Ingen brådska.
Läs även andra bloggares åsikter om datorer, ekonomi, säkerhet, teknik, deklaration, e-legitimation, SEB, Telia, Firefox.
May 1st, 2010
Posted by
Daniel Brahneborg |
blogg |
5 comments
Lördag eftermiddag tillbringades på BMW Welt. Jisses. Det var inte så himla många räta linjer och vinklar där, inte. Riktigt häftigt hus. De hade till och med speciella visningar där de bara pratade om arkitekturen. Vi hade bokat en guidad tur som gick igenom det mesta.
En stor del av utrymmet utgjordes av en öppen “parkeringsplats”. Där stod de bilar som skulle hämtas ut, efter att köparna hade fått äta lite god mat, se lite föreläsningar om vad bilen egentligen kunde, och fått provköra bilen i en simulator. Med rätt registreringsskylt osv, så klart. Därefter togs kunden ned för en trappa, där bilen stod på en snurrande platta, upplyst av diverse spotlights. Där någonstans hade köparen slutat lyssna, och blev okontaktbar.
Det är utlämningsplatsen till höger (där man även ser trappan i profil), utställning utmed vänsterkanten, och en massa detaljer om tekniken nere till höger. Nedfarsrampen hade de fått göra flera meter bredare än den egentligen var tänkt, för att inte folk skulle köra in i kanten med sina nya bilar. Vi såg några som lämnade ställen medan vi var där, och de var minst sagt lite nervösa på gasen.
Om det nu är så att man ska köpa en ny bil, och det råkar vara en BMW, så är det ju så här det ska gå till. Den version som jag fick när jag köpte en Skoda och senare en Audi, som var ungefär “här är nyckeln, där är dörren, tack för dina pengar, hejdå”, var inte riktigt lika kul.
Eftersom svaret på frågan “men behöver du en bil?” är “nej”, så får nog det här köpet vänta ett tag till. Tur att man har karaktär att motstå att spontanshoppa en bil i alla fall. Vuxenpoäng!
Läs även andra bloggares åsikter om teknik, bmw, bmw welt, münchen, arkitektur.
April 7th, 2010
Posted by
Daniel Brahneborg |
blogg |
one comment
I helgen var vi i München, och hade bokat boende på hotell Maritim. Det såg schysst ut, och det fanns internet. Dessutom låg det nära centralstationen, och var inte så dyrt.
Och jo då, det fanns en liten sladd på skrivbordet. Tyvärr så visade det sig att det kostade 150 spänn per dag. För tre dagar skulle det bli lite mycket.
Så jag kollade runt bland de trådlösa nätverken, och hittade en T-Mobile hotspot. Sisådär, 300 spänn för en hel månad, dvs 2/3 av hotellpriset. Upp med Visa-kortet, bara.
Glad i hågen gick jag sedan till wlan-ikonen för att dela ut datorns nätverk till älsklingen, varvid den raskt kopplade ner T-Mobile. Att ta emot signaler i ett nätverk och skicka ut dem över ett annat, på samma antenn, var tydligen lite för mycket överkurs även för en Mac. Fan också.
Som tur var så loggar man in med användarnamn och lösenord, så det går lätt att turas om att internetta, men ändå. Jag blir ändå lite trött. 150 spänn för lite internetaccess, när man dessutom bara kommer utnyttja det en stund på morgonen och en stund på kvällen? Sanslöst. Det verkar som om de har hittat en ny inkomstkälla nu när hotelltelefonin förmodligen inte är så poppis längre.
Lärdom: Kolla inte bara efter “internet access in the rooms”, utan kolla gärna priset också.
Läs även andra bloggares åsikter om internet, teknik, wlan, mac, münchen, t-mobile.
April 6th, 2010
Posted by
Daniel Brahneborg |
blogg |
no comments
Jag blev ombedd att skriva något om www.whr.se, gjord av Per Renemark på PR-Web.se.
Det finns till att börja med en lista med de olika webhotell som finns i Sverige. Både priser, max trafik och lite annat finns i en enkel tabell. Några av hotellen har sedan blivit utsedda till “Bästa bloggwebhotell”, “Bästa budgetwebhotell” osv, för att göra urvalet lite enklare. Väldigt praktiskt.
Dessutom finns lite spridda artiklar, som t.ex. en grundkurs i HTML. Tyvärr gör öppnandet av de här artiklarna att hela vänstermenyn ändrar utseende, vilket är väldigt förvirrande.
Det blir inte bättre av att en del saker i menyn går till enskilda artiklar och andra till hela kategorier.
Så, sammantaget finns det en hel del bra information där, och skulle jag behöva ett externt webhotell skulle jag nog ta en titt på de recensioner som finns. Däremot skulle sajten behöva en liten omstrukturering, en sökruta, osv.
Läs även andra bloggares åsikter om blogg, internet, teknik, webhotell.
March 27th, 2010
Posted by
Daniel Brahneborg |
blogg |
one comment
Mamma hade köpt ett trådlöst nätverkskort som jag skulle hjälpa till att sätta i och få igång. Burken var en Dell, vilket gjorde att det varken krävdes några verktyg för att öppna chassit eller för att ta ut och sätta i PCI-kort. Mycket smidigt.
Det Sweex-kort hon hade köpt hade en tillhörande CD-skiva med drivrutiner. Den sattes i, drivrutinen installerades, och relativt snabbt kom det upp en lista på tillängliga nät. Jag valde deras nät, skrev in lösenordet, något man dessutom var tvungen att göra två gånger (#puckon!), väntade en liten stund, och så hände ingenting. Det blev ingen ip-adress där inte.
Jag provade flera gånger, kollade att jag inte såg fel på 0 (noll) och O (stor olof) osv, men kortet var lika ovilligt att kommunicera som en upphovsrättsjurist hos Sony.
Som tur var har de en dator till, där jag genom att söka på chippet (realtek 8185, som gick att se genom att gräva lite i kontrollpanelen) hos Google hittade en annan drivrutin. USB-minnen är bra att ha, apropå det. Den installerades, och snabbare än den tid det tar att ladda hem en mp3 från Pirate Bay hade datorn nu fått en ip-adress. Vi förstod varför säljaren hade frågat om hon skulle få hjälp med att installera det här kortet.
Å andra sidan har jag ett trådlöst nätverkskort till min server som kör Ubuntu Linux, och det har jag aldrig fått att fungera. Den kan hämta listan på nätverk, men att koppla upp sig mot något av dem fungerar inte. Eller jo, det fungerar med nätverk som inte har något lösenord, men det gör att den blir lite för sårbar för min smak.
Så sammanlagt står det faktiskt 1-0 mellan Windows XP och Ubuntu Linux. *mutter*
Både min MacBook och Nokianalle kunde, inte helt oväntat, prata med det här trådlösa nätverket utan några problem vid första försöket.
Trådlösa nät är praktiska, men de är inte direkt någon barnlek att få att fungera.
Läs även andra bloggares åsikter om datorer, internet, teknik, wlan, realtek 8185, windows xp, ubuntu.
March 7th, 2010
Posted by
Daniel Brahneborg |
blogg |
11 comments
Jag upptäckte ju tidigare att Berkeley DB inte klarar av att det är mer än kanske max 100 trådar som samtidigt anropar funktioner i det, utan att prestanda rasar ner till löjliga nivåer. I mitt fall löste jag det genom att samla ihop anropen till 10 trådar med en connection pool, men det kändes mer som en pinsam workaround än en korrekt lösning. Oracle fick därför en fråga om varför det var på det här sättet.
Efter att ha skickat mina testprogram och skruvat på massor av parametrar för att förbättra prestandan, fick jag till slut ett tydligt svar. De höll med om att min pool var ett bra sätt att lösa det hela på.
The slowdown is not caused by a linear search, but by the low-level latching primitives provided by nearly all existing instruction sets. We use these primitives (e.g., test-and-set or locked compare and exchange) to implement mutexes and shared latches. As the number of threads “fighting” for a mutex increases, there is more overhead, both down in the CPU chip’s cache coherency system as well as in the operating system and BDB software above it.
De använder tydligen posix mutexar för den här synkroniseringen. Min pool är gjord med pthread, som uppenbarligen skalar bättre. Det är lite konstigt att de inte redan stödjer pthread i Berkeley DB, men det kanske kommer i en senare version.
Allt det här gäller i Linux, som jag har för mig har just en ovanligt bra pthread-implementation. Saker kan vara annorlunda i andra unixar.
Läs även andra bloggares åsikter om datorer, programmering, teknik, berkeley, oracle, connection pool, linux, pthread.
February 24th, 2010
Posted by
Daniel Brahneborg |
blogg |
3 comments
Igår var det en tjej bakom mig som pratade i telefon med sin mamma, som tydligen hade haft besvär med samtal från någon oönskad person. Enligt vad jag kunde förstå så hade hon satt en lapp på baksidan av sin telefon eller något sådant med det här numret. Dottern fnissade rejält, undrade varför hon bara inte la in numret i telefonboken på namnet “Svara Inte”, och utbrast sedan “Men mamma, du är så himla analog!”.
Skillnaden i hur man ser på teknik är ibland ganska stor.
February 16th, 2010
Posted by
Daniel Brahneborg |
blogg |
one comment
För några veckor sedan lyckades jag ju isolera ett problem med Berkeley-databasen. Den blev helt enkelt lite missnöjd med livet när det var för många trådar som accessade den samtidigt. I början så lyckades ju Oracle återskapa problemet, så det såg ljust ut. Tyvärr visade det sig vara en bugg i mitt testprogram, och när det var rättat så försvann krascherna. Attans.
Tyvärr fungerade det fortfarande inte helt bra, men det var inte helt tydligt var felet låg. I testsetupen till den riktiga applikationen så är det två andra program inblandade, och det var inte helt säkert att det inte fanns problem där också. Vissa buggar hittade jag faktiskt, men det var länge väldigt osäkert vart tiden egentligen tog vägen. Det gick bara ofantligt långsamt efter ett tag.
Till slut hade jag i alla fall lyckats mutera det lilla testprogrammet så pass mycket att det började visa upp samma symptom som det riktiga. Efter en massa testande och skruvande på parametrar stod det då klart att Berkeley DB börjar få problem när det är mer än något dussin trådar som samtidigt försöker skriva i databasen. Prestanda rasar, det blir deadlocks som gör att massa operationer måste göras om från början, och emellanåt så kraschar den helt och hållet.
Jag testade att sätta ett stort lås runt alla Berkeley-operationer, så att det alltid bara skedde en operation i taget. Först när allting var klart så fick nästa tråd göra någonting. Prestandan blev ju inte så jättebra eftersom det var så många trådar som inte gjorde något annat än att vänta, men det var i alla fall stabilt. Jag drog slutsatsen att det var antalet aktiva trådar som var det besvärliga. Ändå ville jag inte dra ner det till en enstaka tråd. Berkeley ska trots allt vara trådsäkert, och om trådarna jobbar på olika filer eller i olika delar av en fil, så borde det ju inte vara något problem.
De hundratals trådarna, i vissa fall uppåt två tusen stycken, behövde därför kokas ner till kanske 10 stycken. Alltså behövdes en datastruktur och algoritmer för att låta 10 trådar få passera samtidigt, men den 11:e skulle få vänta till någon av de 10 hade blivit klar. Jag behövde inte leta så länge innan jag hittade den perfekta lösningen: Min connection pool som jag skrev till MySQL-drivern! Den var skriven för att vara helt oberoende av vilken resurs som den hanterade, så det krävdes inte en enda ändring.
Några testkörningar senare så var det tydligt att testprogrammet inte brydde sig det minsta om antalet trådar som använder poolen, det gick lika fort ändå. Antalet deadlocks var inte noll, men ytterst få. I början fick jag deadlocks på varannan operation, och nu var jag nere på ensiffrigt av 100.000 poster. Det såg ljust ut.
På grund av hård refaktorering behövde jag bara ändra i tre små funktioner för att lägga till poolen i riktiga applikationen. Även där var prestandan nu helt stabil, oavsett hur många tusen poster den hade hanterat. Den ska få gå i mer full fart och lite längre tid i morgon, men det verkar som att problemet är löst.
För att använda Berkeley DB i en intensivt multitrådad applikation, behöver man alltså använda någon form av filter så att antalet samtidiga operationer maximeras till runt 10. Har man färre trådar än så behöver man självklart inte göra någonting, men det är vi högre upp på skalan som får problem. Oracle har fått en ny buggrapport.
Läs även andra bloggares åsikter om datorer, programmering, teknik, berkeley, oracle, race condition, connection pool.
February 9th, 2010
Posted by
Daniel Brahneborg |
blogg |
8 comments
« Äldre |
