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 |
10 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
Karin Fribergs blogginlägg Övervakningsskälvan häromdagen fick ganska många att reagera. Själv nöjde jag mig med att twittra ett påpekande om att en av hennes grundkriterier var falskt (övervakning leder inte till varken minskad brottslighet eller något annat). Efter en massa kommentarer så verkar hon förstå problemet, vilket är bra. Karin är intelligent, så det var inte så oväntat.
Oscar Swartz skrev sedan ett inlägg om att han var trött på att alltid behöva börja om från början med de här diskussionerna. Jag förstår att Karin kanske känner sig lite påhoppad. Tyvärr är det inte alltid så lätt att ge den vänliga hjälp som hon eftersöker, eftersom både övervakning, upphovsrätt, fildelning och allting därikring nu har debatterats i flera år, med resultat från studier i ett antal länder, osv. Alla argument och bieffekter har prövats, vägts, och bemötts. Resultatet är att det inte längre finns någon debatt, eftersom det bara finns ett svar. Det är inte som att fundera på vad som är godast av hemkokt hallonmarmelad och skolans leverbiffar, för där kan man faktiskt ha två olika åsikter.
Karin twittrade till mig “Jo, men vi som ligger lite efter måste ju också få vara med och göra vår tankeutveckling”. Jag visste inte riktigt hur jag skulle kunna svara på det utan att verka nedlåtande, men en video med Richard Dawkins och Lawrence Krauss som jag såg häromdagen, kanske kan hjälpa till att förklara problemet. De diskuterar framför allt evolution, och det tragiska i att nästan hälften av USA’s befolkning inte tror att evolutionen är sann, utan tror på intelligent design, flygande spaghettimonster och vad det nu är.
När det gället evolutionen så finns också en “debatt”, och precis som i fallet med piratfrågorna så finns bara ett svar. I videon jämför Richard Dawkins det med debatten om var barn kommer från. På ena sidan finns det de som hävdar att de är resultatet av en sexuell aktivitet, och på andra de som hävdar att de kommer med storken.
Ibland är argumenterandet för en uppdaterad upphovsrätt och fri komunikation lika skoj som att i flera år diskutera med en vuxen människa som på allvar tycker “min moster hade ofta storkar på tomten, och de har fler barn än alla andra i släkten”. Man gör studiebesök på BB runt om i världen, förklarar biologin i hur däggdjur förökar sig, visar röntgenbilder, men det enda man får tillbaka är “men min moster…”. Att anledningen till att just hennes moster fick så många barn, är att hennes man blev sexuellt upphetsad av just storkar, anses för absurt. Argumentet att det faktiskt föds barn på platser där det inte finns några storkar ignoreras friskt, möjligen med motargumentet att det kanske finns andra fåglar där.
Under tiden stiftas lagar för att säkerställa storkarnas möjlighet att bo överallt i landet, barnafödande tas bort från läkarnas utbildningar, och kvinnor där i barnsäng eftersom ingen längre förstår vad som händer.
Där, ungefär, ligger piratfrågorna nu. Några få personer är övermänskliga och lyckas fortfarande vara både trevliga och pedagogiska utan att vara nedlåtande. Samtidigt är många pirater tekniker, och tekniker är problemlösare. Det här problemet är löst, och därmed inte längre intressant. Nu vill vi gå vidare och jobba med nästa problem. Som att faktiskt skriva en ny upphovsrätt, t.ex.
Läs även andra bloggares åsikter om fildelning, internet, fra, politik, säkerhet, teknik, sex, karin friberg, oscar swartz, richard dawkins, lawrence krauss, evolution.
October 29th, 2009
Posted by
Daniel Brahneborg |
blogg |
no comments
Det här den långa versionen av första punkten i inlägget “Saker som suger” från i somras.
Att köpa ett interkomsystem till min motorcykel var enklare sagt än gjort.
I höstas läste jag om Cardo Scala Rider Q2. Enligt specifikationerna ska den klara av att ha kommunikation mellan två enheter på flera hundra meters avstånd, skicka vidare ljud från ens MP3-spelare samt kommunicera över bluetooth med både ens telefon och GPS-enhet. De recensioner jag läste (t.ex. sporthoj.com, motorcycle.com) var mycket positiva, även om det verkade finnas något problem med att få den att prata med både en telefon och en GPS. Jag fick intrycket att det trots allt inte var mer komplicerat än att man behövde para ihop den med den ena före den andra i någon speciell ordning. Verkligheten skulle visa sig vara långt mycket värre.
I våras övningskörde jag privat med två handledare. För att utnyttja tiden maximalt köpte jag ett Q2-set från CDON, där de tog 2500:- för två enheter inklusive mikrofon, hörlurar, osv. De flesta andra tar 3500:- för samma paket, så jag kände mig väldigt nöjd. Det fungerade till en början hur bra som helst. Jag kunde ställa frågor till handledaren när jag var osäker på hur jag skulle köra, och kunde få omedelbar feedback. Att sätta på och ta bort mikrofon och hörlurar från handledarnas respektive hjälmar gick på någon minut.
Interkom mellan enheterna prioriteras lägre än GPS-kommandon, vilket gör att man kan prata med sin handledare, medförare eller passagerare och då och då bli avbruten av ett “sväng till höger om 200 meter”. Några sekunder senare kommer interkom-delen automatiskt tillbaka. Detta fungerade i en knapp timme, och sedan blev GPS’en i min mobil, en Nokia E66, helt tyst. Jag försökte starta om GPS-rutten och manuellt återansluta från telefonen, men den lyckades aldrig återfå kontakten med min Q2.
Jag skickade tillbaka min Q2 till CDON och fick ett nytt exemplar. Det visade sig att den nya betedde sig precis likadant. Jag fick GPS-instruktioner i en knapp timme, och sedan var den död. Nyfiken som jag är så började jag då experimentera lite. Det visade sig att om man tog bort Q2′n från telefonen och gjorde en helt ny ihopkoppling, fungerade det igen. I en knapp timme.
Jag ringde Cardo, som gav följande information: Inte nog med att vissa funktioner inte stöds på vissa telefonmodeller, som t.ex. röstuppringning, att kunna ta emot GPS-instruktioner från mobiltelefoner hade de inte testat. Killen jag pratade med hade aldrig ens hört talas om någon annan som hade fått det att fungera. Han visste bara att det fungerade att ta emot GPS-instruktioner från en Zumo 550 (som är på utgående) eller 660, i det senare fallet om den körde minst version 3.1 av mjukvaran. Garmin Nuvi fungerade definitivt inte alls, eftersom den skickade sina instruktioner på något ovanligt sätt.
I samma veva befann jag mig hemifrån, och skulle använda Nokiatelefonen som modem till min MacBook, också via bluetooth. Det var bara att para ihop dem, lägga in “online.telia.se” som APN, och så var jag online. I en knapp timme. Sedan dog uppkopplingen, och det gick inte att få tillbaka den. Efter samtal till supportavdelningarna hos både Telia, Nokia och Apple upptäckte jag att om jag tog bort bluetoothkopplingen helt, återställde alla filer i katalogen /Library/Preferences/SystemConfiguration/ från en sparad kopia och sedan la in den igen, gick det att få tillbaka uppkopplingen. I en knapp timme.
En kille hos Nokia, som verkade ha specialiserat sig på bluetooth, lyckades till slut komma med en trolig förklaring. Det finns fyra företag som skriver och säljer bluetoothstackar, nämligen Microsoft, Toshiba, Broadcomm och Widcom. Nokia använder den från Microsoft, och Apple den från Broadcomm. Att alla är “2.0″ är ointressant, för i det här läget har de utvecklats så mycket åt varsitt håll att de är bitvis helt inkompatibla. Enklare saker som t.ex. röstsamtal fungerar, men mer avancerade saker som GPS-instruktioner och röstuppringning fungerar antingen bara ibland eller inte alls. Jag ringde Cardo som tyckte att leverantören av bluetoothstack var “proprietary information” och vägrade svara. Telefoner från LG, Motorola och Samsung skulle förmodligen fungera bra. Jag ringde Samsung för att fråga vilken stack de använde, men de skulle behöva skicka frågan vidare till Korea, och var tveksamma till om jag skulle få något svar.
Att få något företag att byta bluetoothstack känns orimligt, utan det enda man som konsument nu kan göra är att undvika bluetoothprodukter helt och hållet tills dess att de här fyra har pratat ihop sig och skapat en gemensam standard som faktiskt fungerar. Att alla företag som tillverkar saker som sägs kunna prata bluetooth ändå vägrar ta något ansvar för att de fungerar med något annat än företagets egna produkter, är därför förmodligen på grund av att de olika varianterna på bluetooth faktiskt inte är så bra på att prata med varandra. Det finns trots allt både trådbaserade headset och sladdar för att koppla mobilen till datorn.
Om man ändå vill ha ett komsystem till sin motorcykel är läget värre. Hos MC-varuhuset säljer de ett system från Motosonic, men som bara klarar något dussin meters avstånd. Oanvändbart om man har varsin hoj, med andra ord. De har också en sladdbaserad lösning, men som kräver fast installation på hojen, och tydligen kostade så mycket pengar att jag inte ens kunde få en prisuppgift. Det ska även finnas ett system som heter Interphone, men att hitta någon som sålde det här i Sverige var enklare sagt än gjort. Det fanns också ett par system som bara fungerade med en viss hjälmtyp. De vettiga alternativen till Cardo är alltså inte så många.
Till slut så hittade jag Interphone F4, som är den senaste modellen från Cellular Line, hos MC-varuhuset här i Stockholm. De gick på 2290:- / styck, så de var lite dyrare än Cardon. De hade inga exemplar inne, utan fick specialbeställas. Cardon åkte därmed tillbaka till CDON, som skickade tillbaka mina pengar inom några dagar. Strålande.
Interphone-systemet har märkbart mycket stabilare blåtand än Cardon. Att para ihop de två jag köpte, min och flickvännens, gick klockrent. Varje enhet kan paras ihop med två telefoner, så sammanlagt är de två enheterna nu parade med tre olika telefoner av helt olika årgång och modell. Att ta emot samtal har vi testat med två av telefonerna, och det fungerar perfekt. GPS-instruktionerna kommer fram utan problem, timme efter timme. Mjukvarumässigt är den som en modern Linuxserver, där Cardon mer liknar Windows 95.
Hårdvaran är däremot inte lika kul. Cardon hade en lång bom-mikrofon som satt fast i hållaren som man skruvade fast i hjälmen, vilket gjorde den väldigt stabil. Mikrofonen på Interphone sitter på ena hörluren, vilket gör det mycket vingligare. När man har hjälmen på huvudet så är det ju svårt för hörluren att ramla av, men ändå. Hörlurarna är dessutom mycket tjockare än Cardons, vilket gör att de lätt skaver mot öronen om de inte sitter helt perfekt. För slutna hjälmar har de en version där mikrofonen sitter med en tejp, vilket verkar fungera lite bättre. Istället för den inbyggda kontakt som Cardon hade mellan enheten och hjälmfästet, sitter paketet med mikrofon och hörlurar till F4 via en liten sladd som man trycker in på undersidan. Den är inte heller jättebra gjord, vilket gör att det då och då knäpper och brusar lite när det glappar.
Om man har en Zumo och förmodligen inte använder telefonen när man kör, så är nog Cardon ett bättre val. Själv är jag mest glad att det faktiskt fanns en konkurrent med stabilare mjukvara.
Läs även andra bloggares åsikter om mc, motorcykel, datorer, teknik, blutooth, cardo scala rider, interphone f4, headset.
September 14th, 2009
Posted by
Daniel Brahneborg |
blogg |
no comments
Jag fick ett mail från Nokia om en undersökning som de ville att jag skulle svara på. Jag klickar…
Första sidan:
“Klicka på nästa knapp för att slutföra undersökningen.”
Ja, det finns en knapp där det står “Nästa”, men ändå. Ska jag slutföra undersökningen redan innan jag har hunnit svara på några frågor? Skumt.
Sida två:
“Jobbar du inom någon av följande branscher?”
Sedan följer några branscher, inklusive “Ingen av dessa”. Nej, “Ingen av dessa” är inte någon bransch.
Kul också att knappen för att backa bara har texten “<<”, medan den för att gå framåt har “Nästa”. Konsekvent och fint.
Sedan skärpte de sig lite, som tur var. På slutet kom en fråga om man använde sin mobil som en modeaccessoar. Jo, men tjena. Jag orkade inte ens fråga vilka färger modellen fanns i när jag köpte en ny mobil i våras.
Läs även andra bloggares åsikter om teknik, internet, nokia.
September 3rd, 2009
Posted by
Daniel Brahneborg |
blogg |
no comments
Efter ett litet missöde för några veckor sedan så vägrade servern boota. Jag lyckades få liv i den igen genom att koppla hårddiskarna till en annan dator, men på det hela taget så blev det inte så vackert.
Efter att ha köpt en antistatmatta så var det då idag dags att flytta över allting till det chassi där servern hör hemma. Det har rejält med plats för hårddiskar, ett bra nätaggregat, lufthål överallt, plats för massor med fläktar, och är allmänt bättre. Jag rensade lite bland kablarna, så nu ser det lite vettigt ut igen. Ja, det är helt tomt uppe till vänster eftersom jag inte har några dvd-spelare eller dylikt. Jag skulle dessutom gärna vilja ha plats för en stor fläkt mellan de två staplarna med hårddiskar, men det verkar fungera bra ändå.
När jag kommer på en bättre affärsidé och får in massor med nya pengar, så ska jag köpa ett nytt moderkort som inte är ett par år gammalt, lite nya hårddiskar och så, men det här får duga ett tag till.
Läs även andra bloggares åsikter om datorer, teknik.
August 30th, 2009
Posted by
Daniel Brahneborg |
blogg |
4 comments
På jobbet hamnade jag i en situation som skulle kunna göra att våra stackars kunder skulle få tusentals samtidiga uppkopplingar till sin MySQL-databas. Tio kanske är ok, i bästa fall hundra, men därefter tror jag inte att databasen blir så glad längre. Alltså behövdes en “connection pool”, så att det bara behövdes så många uppkopplingar som faktiskt användes samtidigt. Om det behövdes för många uppkopplingar, fick de trådarna helt enkelt ställa sig på kö. Så långt var det det ju inget konstigt.
Tyvärr är vår applikation skriven i C, så alla färdiga paket för sådant här, som nästan alltid är skrivna i Java, går inte att använda. Istället för att ägna halva dagen åt att leta upp något existerande som gick att använda från C, bedöma om licensen gjorde det användbart, fundera över prislappen, anpassa till vår produkt osv, så satte vi oss ner och skissade på en egen implementation.
Först behövs en struct för poolen.
- int size // antalet skapade resurser (uppkopplingar)
- int maxsize // det maximala antalet tillåtna resurser, typiskt 10 eller så
- lock // lås, så att inte flera trådar försöker komma åt poolen samtidigt
- list available // lediga resurser
- list waiting // lås för trådar som väntar på en ledig resurs
- creator // funktion som skapar en ny resurs
Sedan behövs två små algoritmer. Först den för att hämta en resurs ur poolen.
- Lås pool.lock.
- Om det finns något i available-listan:
- Plocka ut första objektet i available-listan.
- Annars, om size < maxsize, dvs vi kan skapa fler resurser:
- Anropa creator-funktionen, och låt det objektet bli det som ska returneras.
- Räkna upp size.
- Annars:
- Hämta trådens lås från treadlocal.
- Lås trådens lås, och lägg det sist i waiting-listan.
- Lås upp pool.lock.
- Om vi ska vänta:
- Lås trådens lås igen, vilket gör att tråden hänger.
- När låset släpps, börja om från början.
- Returnera resursen.
Det behövs självklart också en liten algoritm för att lämna tillbaka resursen när den inte längre behövs.
- Lås pool.lock.
- Lägg tillbaka resursen i available-listan.
- Om waiting-listan inte är tom:
- Plocka ut första låset ur waiting-listan, och lås upp det.
- Lås upp pool.lock.
Om det finns lediga objekt krävs därför bara ett lås, annars två. Eftersom man plockar ut låsen ur en ordnad lista, är den helt rättvis. Det sker ingen busywait. Det skulle enkelt gå att öka maxsize i ett körande system, och med ett litet tillägg vid återlämnandet kan maxsize även minskas. Själva implementationen, inklusive några justeringar av algoritmen, var klar strax efter lunch.
Läs även andra bloggares åsikter om datorer, programmering, teknik, databas, mysql, connection pool.
August 26th, 2009
Posted by
Daniel Brahneborg |
blogg |
no comments
Just nu är det inte mycket på den tekniska fronten som fungerar som jag vill.
Mitt komsystem till hojen fungerar inte med gps’en i mobilen. Alternativ 1 är en separat gps för 6000 spänn, alternativ 2 ett annat komsystem för närmare 5000. Kul. Återstår att se om jag kan få tillbaka pengarna för det gamla, om jag nu väljer en sådan lösning. Det är miljarder gånger roligare att åka hoj med passagerare om man kan prata med varandra under tiden.
Nallen går inte att använda som modem till datorn, om man inte använder en sladd som jag inte vet var den ligger.
Databasen på RSS/Ping-servern, som även kör min blogg, klagade på något korrupt entry. Nu startar inte datorn alls. Hårddiskarna är dock ok, och kan förhoppningsvis flyttas lite diskret, men jag vet inte när den kan vara uppe igen.
USB-hårddisken går inte att använda från min Linuxdator.
Linuxdatorn fungerar inte i grafiskt läge, och i textläge får jag inte liv i nätverkskortet.
Ett lösenord som jag har glömt bort, ligger i en fil på servern som inte startar.
Å andra sidan är jag fullt frisk, det schysst väder, och jag kan ta min älskling på små hojturer. Sådant kompenserar ju lite grand.
Kopierat från en Facebook-notering, från när servern var offline.
Läs även andra bloggares åsikter om datorer, teknik, internet, mc.
August 5th, 2009
Posted by
Daniel Brahneborg |
blogg |
no comments
« Äldre |
