[18:31] Hva i Ubuntu er det som senker internett hastigheten? Prøver jeg speedometer i Win7 får jeg 3-4 ganger raskere ned- og opplasting- [18:31] . [18:33] helt sikkert en dårlig driver. [18:33] hva slags nettverkskort er det du har? [18:34] dw-140 [18:34] dwa* [18:34] usb [18:35] ah... Dlink er jo nokså konsekvent grusomt. [18:35] jeg hadde egentlig lyst til å bruke et annet ord enn grusomt der.. :) [18:36] surfingen er blitt gale uten at jeg har gjort noe [18:37] så det finnes ingen løsning for meg enn å bruke win7 ? [18:38] jo, du kan vel for eksempel bruke driveren for Windows med ndiswrapper. Mange som har hatt gode erfaringer med det. [18:38] det vet ikke jeg noe om. kan du hjelpe meg? [18:39] ikke akkurat nå. Jeg er litt opptatt. Men dette er velkjent, så du finner mye bra på wikien og det er sikkert noen her som vet. [18:40] jeg kommer tilbake senere [19:58] http://www.piware.de/2011/11/12-04-testing-ftw/ :D [20:55] noen her som burker empathy og kobler seg til msn, som ikke kommer inn der? Jeg får ikke koblet meg til lengere. [20:55] før kunne jeg drepe telepathy-butterfly og så koble til, nå går ikke det [20:55] mistenker at msn har endra noe i protkollen igjen? [21:06] virker i bitlbee [21:41] xt\: Nå driver vi noe bra crack her. === xt\ is now known as xt [21:41] xt\: Migrering av en maskin med libvirt og kvm, med disk på drbd. [21:41] har prøvd med disk på nfs [21:42] tryna pga ulik cpu [21:42] og korruperte fs [21:42] men fekk redda fint [21:42] Funker fint med drbd! [21:42] Bruker _masse_ nett, da (-: [21:42] virka som den ikkje hadde graceful recover om det gjekk åt skogen [21:42] Og relativt like CPUer i hver ende og slikt. [21:42] Med Debian squeeze mot wheezy og alt. [21:43] trur eg prøvde frå intel => amd [21:43] utan å tenke meg om [21:43] men fekk ingen warning da [21:43] bare kjørte på [21:43] og tryna gjesten då det ikkje fungerte [21:43] Det burde jo funker, sånn egentlig. [21:43] Dette er amd64 i alle ender, med Intel-CPUer på vertene (men ikke samme CPUer). [21:48] er litt skilnad på intel sin vt og amd sin [21:49] trur eg [21:49] Det er mulig. [21:49] korleis drbd-oppsett? [21:49] klone på to maskiner? [21:49] Japp. [21:49] RAID1 med dual-master. [21:49] er det gøy? [21:49] Det er ganske gøy. Det føles veldig… crack. [21:49] korleis er IO? [21:49] Treigt. (-: [21:50] Men den ene maskinen er opptatt med backup og slikt samtidig. [21:50] finst vel betre fs [21:50] Begge maskinene har et LVM-volum på et stort RAID hver som target for brbd. [21:50] brbd er ikke et filsystem, dog. [21:50] Det gir deg en blokkenhet. [21:50] ja [21:50] var litt upresis [21:51] Sånt slår vi hardt ned på! [21:51] "No virtualization platform allows cross vendor migrations today, normally you get blocked during the setup stage, so you don't get crashed VMs. [21:51] except I didn't :) [21:51] Normally (-: [21:51] and got crashed VM [21:52] Does KVM support live migration from an AMD host to an Intel host and back? [21:52] Yes. There may be issues on 32-bit Intel hosts which don't support NX (or XD), but for 64-bit hosts back and forth migration should work well. Migration of 32-bit guests should work between 32-bit hosts and 64-bit hosts. If one of your hosts does not support NX, you may consider disabling NX when starting the guest on a NX-capable system. You can do it by passing "-cpu qemu64,-nx" parameter to the guest. [21:52] ok, om du limiter CPU-set [21:52] så kan du [21:52] Du vil typisk ha NX, da. [21:52] Men hallo, du har tamme CPUer om de ikke gjør (-: [21:52] som det står [21:53] trenger bare skru av om av dei ikkje har [21:53] eg får prøve på nytt med qemu64 [21:53] joda [21:53] mister sikkert litt perf av det [21:53] må jo skru av alle slike ss4 osv [22:15] sitter og leser om MongoDB-dramaet, og tenker at egentlig har eg kanskje lyst på litt nosql i prosjektet [22:15] lurer på om eg ikkje jukser og lagrer litt json som tekst rett i mysqlen nå [22:16] Drama? [22:16] HVA ER GALT MED SQL? [22:16] Folk lagrer visst serialisert json i Postgresen. [22:17] http://archives.postgresql.org/pgsql-hackers/2010-11/msg00481.php - tydeligvis litt hit og dit med jsonen. [22:17] feil kanal! [22:17] min feil! [22:17] OI! [22:17] Du har jo samme farge og alt. [22:18] få deg ein moderne irc-klient så har eg samme farge i alle :) [22:18] xt: (= [22:18] xt: Jeg må bare orke! [22:19] 256 farger. [22:19] Mus-støtte! Minesweeper! [22:19] :P [22:19] …mus. [22:19] Er ikke et salgspunkt for meg. [22:19] derfor eg sa det [22:20] Minesweeper er, da! [22:23] Berge: http://dev.weechat.org/post/2011/10/02/Game-Minesweeper [22:24] xt: Nesten like bra som tetris i zsh. [22:24] weetris finst! [22:25] ! [22:25] /weeget install weetris [22:25] Med pakkehåndtererr! [22:25] jepp [22:25] Det er hipt for tiden. [22:25] alle må ha! [22:25] Hver sitt! [22:25] ja [22:25] ! [22:25] irc-klient med pakkehåndterer? [22:25] irssi har òg det [22:25] dog. [22:26] jajo [22:26] det falt meg ikke helt inn, men ok. [22:26] Men du har også aptitude install irssi-scripts, og det er ca. det du trenger. [23:02] Berge: A DBA walks into a NoSQL bar, but leaves because he can't find a table.... [23:02] RoyK: (= [23:04] :D [23:23] ja, sett isolation level "read uncommited" og gogo json rett inn .. ser ikke problemet :> [23:24] (..eller i PG så falller den vel tilbake på commited, men joda) [23:25] ups, transaction retry samtidig som jeg gjorde I/O der .. så det ble 3 L'er [23:30] jeg forstår ikke helt hvorfor det er en fordel å dytte json inn i en SQL-database istedenfor å bruke en database som er designet for nettopp det. [23:30] jo-erlend: Det tviler jeg ikke på. [23:30] vil du forklare? [23:31] Du ser ikke poenget med relasjonsdata, selv om du tilfeldigvis trenger datatypen json? [23:31] Man trenger jo gjerne datatypene int, text og xml også. [23:31] Hvorfor ikke json? [23:32] jojo, hvis det er relativt små mengder json og relativt store mengder med relasjonsdata, så skjønner jeg det. [23:32] Du kan f.eks. mislike XML, som vi alle gjør. [23:32] Ta Store norske leksikon (hvis database jeg ved et uhell ble DBA for). [23:32] det ville være enda vanskeligere å overbevise meg om at det er lurt å dytte XML inn i en relasjonsdatabase. [23:32] Leksika er soleklare kandidater for relasjonsdataq. [23:33] Artikkelteksten er i XML, i et felt i en tabell kalt articles. [23:33] hvorfor det? [23:33] Hvorfor ikke? [23:33] articles har masse annet nyttig, som en id som fremmednøkler hit og dit. [23:34] hva slags fremmednøkler? [23:34] XML er fint (i den grad det er fint) for strukturering av tekst. [23:34] Eh, til kategori, f.eks.? [23:34] Og artikkeltype. [23:34] Og forfatter. [23:34] Og utdypningsartikler. [23:34] jo-erlend, "se også .. blabla" [23:34] Og oppslagsverk. [23:34] forfatter, tittel, artikkeltype er alle statiske informasjonsbiter, er de ikke? [23:34] Statiske? [23:34] Det er relasjonsdata. [23:34] De relaterer. [23:35] artikkeltype bør normaliseres [23:35] Dette er omtrent nøyaktig det relasjonsdatabaser ble designet for. [23:35] hvorfor skal de ikke være en del av dokumentet istedenfor å være i en egen tabell? [23:35] lnostdal_: 3NF! Alt bør normaliseres. (-: [23:35] jo-erlend: Hils på mister normalisering. [23:35] Fordi det er relasjonsdata. [23:35] Du vil f.eks. slå opp alle artiklene en forfatter har skrevet. [23:35] jeg er godt kjent med Codd. [23:35] Berge, ja? Det er jo ikke noe problem å ha lenker mellom dokumenter på webben? [23:36] …web? [23:36] What? [23:36] jo-erlend: når mesteparten av data er relasjonsdata, og bittelitt er json, så er det meir effektivt å ha alt i samme database, i staden for å ha eigen databaseserver osv, myyyykje meir vedlikehold/overhead/adminisstrasjon dill dill dill [23:36] Derfor. [23:36] Men ok, om dette var et vanskelig konsept, tror jeg ikke jeg klarer å forklare det på noen bedre måte. [23:36] xt, ja, det er jeg enig i. [23:37] og databaser er laga for json [23:37] Berge, hvorfor er det så galt å ha en liste over lenker i et dokument? Hvorfor må det være SQL? [23:37] hugs det. [23:37] Json er tekst. Databaser lagrer tekst ganske bra. [23:37] jo-erlend: SQL er et språk. [23:37] Akkurat hvordan du spør databasen, er ikke relatert, reint formelt. [23:38] (Postgres hadde sågar ikke SQL-støtte i hine, hårde dager.) [23:38] Må nok ha det i CouchDB, som DOKUMENTER [23:38] da blir livet så meget bedre. [23:38] mhm, det er veldig slitsomt å snakke med deg. Istedenfor å beskrive idéer, så må man passe veldig nøye på å ikke ha en kommafeil, etc. [23:38] jo-erlend: neida, det er _deg_ det er slitsomt å snakke med :) [23:38] pretty sure. [23:38] No offense! [23:38] jo-erlend: Beklager, men jeg klarer altså ikke å forklare konseptet bedre. [23:39] Såklart kan du lagre leksika i andre strukturer enn i relasjonsdatabaser. [23:39] det jeg lurer på, er hvorfor lenker til andre dokumenter som er tilgjengelig over HTTP ikke kan lagres i en vanlig liste i et json-dokument, men må lagres i en relasjonsdatabase med sine egne tabeller? [23:39] Men jeg forsøker å si at relasjonsdatabaser er velegnet. [23:39] Jeg forstår ikke hva du mener. [23:40] ok. Det virket som at xt mente at hans tilfelle passet godt til NoSQL, mens du ville at han skulle tvangsfôre det inn i en relasjonsdatabase isteden. [23:40] Jeg ser ikke hvordan dette er tvangsfôring på noe plan. [23:40] Det er ideelt for relasjonsdatabaser. [23:40] javel. Jeg vet ikke hva det er prosjektet hans går ut på. [23:40] Ikke alle problemer er, men dette er altså. Og det er nyttlig å lagre XML og JSON og andre datatyper i relasjonsdatabaser. [23:41] Ikke jeg heller, jeg forsvarer bare JSON-datatypen i Postgres. [23:41] (Som rett nok ikke finnes ennå, men dog (-: ) [23:42] overdreven normalisering er skikkelig destruktivt. [23:42] jo-erlend: kva db ville du hatt lekikon i? [23:42] jo-erlend: det spørs. [23:43] ingen fasit på det der [23:44] (Nå skal det kanskje nevnes at akkurat SNL-databasen ikke er spesielt velnormalisert, men det er under fiksing.) [23:45] xt, mtp at et leksikon er en samling av selvstendige dokumenter, ville jeg ha vurdert å bruke en dokumentdatabase. [23:46] sharepoint? :) [23:46] :) [23:46] De er ikke selvstendige. [23:46] De relaterer til ting. [23:46] er de ikke? [23:47] Nei. Se backlog for ting de relaterer til. [23:48] men jeg er ikke enig i at det er relasjoner. Jeg mener at det er en del av dokumentet. [23:48] jeg skjønner at du _kan_ se på det som relasjoner, men da overnormaliserer du. [23:54] det eneste jeg synes er interessant m.t.p. nosql er lettvinnt skalering i bytte mot presisjon der dette er o.k. .. m.t.p. documentstore og json (eller xml for all del..); er det virkelig noe galt i lagre xml/json direkte i en kolonne, for så lagre noen av feltene i egne kolonner senere for raskere søk (indexering)? [23:54] jeg mener... Ta en artikkel fra wikipedia som eksempel. Alle bilder er vedlegg. Lenker er en liste med lenker. Hvis jeg kopierer en artikkel lokalt, så er den artikkelen nøyaktig like brukbar, selvom referansene naturligvis ikke er like nyttige hvis nettverket faller ned. [23:55] (xml/json feltene, da) [23:55] lnostdal_, prøver du å si at relasjonsdatabaser nødvendigvis er raskere enn en dokumentdatabase? [23:55] lnostdal_: Skalering? [23:56] jo-erlend: Han sier vel det motsatte. [23:56] egentlig ikke [23:56] jo-erlend: Jeg skjønner ikke hvorfor du snakker om lister med lenker. [23:56] lettvinnt skalering betyr ikke at motparten ikke kan skalere [23:56] (Lenker er lagret i XMLen i SNL.) [23:57] noen her som bruker zfs/openindiana? [23:57] Berge, ja, da høres det jo enda mer ut som om artikkelen er en selvstendig samling med data. [23:57] jo-erlend: Artikkelteksten er. [23:57] Men jeg skal ikke gjenta at det altså relaterer data til den. [23:58] Berge, men ikke lenkene, navnet på forfatteren, etc? [23:58] Jeg skal heller gjøre noe produktivt, som å forbedre søket (-: [23:59] jeg mener... Hvis det du beskriver er en relasjonsdatabase med én kolonne for ID og en annen kolonne for json med alt annet, så høres det ut som at du misbruker verktøyet.