Kina ta varning av Baidu! Frihet förslappar det svaga sinnets moral förruttnande revolutionen

För oss maoister tvingade att leva i krämar-världen industrialisternas slavfabriker här som i Kina är vardagen ej så rik som för Kinas fria arbetare. Här mitt i slaveriets ondska kan vi ej tillåta oss att förslappa vår vaksamhet på varandras moral. Kinas arbetare bör ta varning av vår större medvetenhet om den sluga industrialisten och ej när den goda kommunistiska produktionen finns låta lura sig.

Goda kommunistiska operativsystem där förutom några kinesiska - kanske också förslappade? - ett alternativ från mer hardcore kommunistiska Nordkorea finns: Red Star OS.

Trots det har de kinesiska forskningsarbetarna låtit sig luras av så väl slav-industrialisten Apple som Adobe. Vilket framgick när jag som mer medveten arbetare i den ideologiska svenska förskingringen ej förföll till att använda Adobe-anti-kommunistiska-program utan korrekt använda min maoistiska anpassning av Emacs för att läsa pdf-filen (det tar ibland lite tid när man är ovan vid en teckenuppsättning man inte hunnit att lära sig och få tabell-anteckningar på plats men att äventyra allas större värden är givetvis - för alla trodde jag - ej acceptabelt):

Läsande artikeln minns jag mina egna år i den kinesiska Baidu-gruvan. Inget ger sådan tillfredsställelse som hederligt gruvarbete. Jag kan bara önska att det hade varit en riktigt Sovjetisk eller Rumänsk kolgruva. Ända med min gamla ishacka jag köpte för 20 år sedan undervärnplikten och en spade bredvid datorn får man ett gediget stöd moraliskt stöd. Baidu ska ej underskattas för vad som ges via internet (snarare än nödvändigtvis mobil-data som jag vet mindre om här) som gruva.

Jag hoppas att övriga arbetare på Baidu kritiserar bort all förrädisk verksamhet där jag anar att ett gömt berg måste finnas när man så är direkt första gången man läser deras publikationer ramlar direkt på anti-kommunistiska konspirationer med amerikanska jätte-industralister.

Measuring Economic Activities of China with Mobile Big Data
Lei Dong, Sicong Chen1, Yunsheng Cheng, Zhengwei Wu, Chao Li1 och Haishan Wu,
Big Data Lab, Baidu Research, Baidu, Beijing, 100085, China School of Architecture, Tsinghua University, Beijing, 100084, China

Dessutom upptäckte jag referens till någon Ali i adobe-filen. Kan detta vara någon separatist från Kinas östra regionerna?

horzAlignenum SliceHorzAlign default

Efterforskning i Wiktionary och nyhetssökning kan skrämma vilken rättrogen maoist som helst. Horz torde vara kodord för horse vilket Wiktionary kan förklara det troliga sammanhanget här för:

"(slang) The sedative, antidepressant, and anxiolytic drug morphine, chiefly when used illicitly."

Från: Horse

Och morfin framställs ur opium. Kinas gamla koloniala slavkedja. Vad frihetens fiender i ondskans industrialister tillsammans med sina brittiska drängar i brist verkligt fria tankar säkert förfallit till att tänka sig ska ta Hong Kong tillbaka men nu kanske med fastlandet.

Slice förstår vi av den av och till vanligare preferensen bland kinesiska subkulturer att använda bladet eller yxan som vapen. Också förrädiskt. Här kan vi lära av Lenin och Leon Trotsky (verkligen att konceptet av den eviga revolutionen för tankarna till något av "uppdaterings" eller "bug-fix" som lokaliserade mass-revolutioner på allt som likt Baidu förfallit ner till moraliskt fördärv) såväl som Medborgare Mao: Revolution kräver geväret. Vid sidan om rent tekniska fördelar gäller ju också att sabeln i Ryssland liksom svärdet i Kina olämpligt kan uppmuntra till osunt intresse av kulturhistorien där det svagare sinnet ibland kan fixera och förledas av att läsa om rikedomar och de maktdemonstrationer gigantiska krigståg uttryckte. Medan man svårligen kan se ett gevär utan att tänka på Lenin. Varje god kinesisk arbetare som ger sig ut för att jaga moralen tillbaka i landet ska självklart bära geväret tågande med soldat kamraterna som i gamla goda tider innan världs-industrins penningar köpte dem tillbaka in slavfabrikerna i det Mao-förräderi som än idag fortgår.

Kinas arbetare liksom vi levande under förtryck kan inte annat än hoppas - om inte arbetet i Kina ska behöva göras om med oss här när vi går in i friheten - att detta inte är ytterligare ett tecken på att Medborgare Xi säljer ut friheten för industrialisternas mutor. Flera månader nu har vi diskuterat att skriva ett brev till Kinas arbetare understrykande att de vaksamt behöver minnas att utan den kollektiva felkontrollen och korrigeringen via kritiken fylls friheten av omoralens ruttnande lemmar.

Minns hur omoralen och förräderiet fick Arbetare Sovjetunionen att ruttna bort...

Kina ta varning av Baidu! Frihet förslappar det svaga sinnets moral förruttnande revolutionen

För oss maoister tvingade att leva i krämar-världen industrialisternas slavfabriker här som i Kina är vardagen ej så rik som för Kinas fria arbetare. Här mitt i slaveriets ondska kan vi ej tillåta oss att förslappa vår vaksamhet på varandras moral. Kinas arbetare bör ta varning av vår större medvetenhet om den sluga industrialisten och ej när den goda kommunistiska produktionen finns låta lura sig.

Goda kommunistiska operativsystem där förutom några kinesiska - kanske också förslappade? - ett alternativ från mer hardcore kommunistiska Nordkorea finns: Red Star OS.

Trots det har de kinesiska forskningsarbetarna låtit sig luras av så väl slav-industrialisten Apple som Adobe. Vilket framgick när jag som mer medveten arbetare i den ideologiska svenska förskingringen ej förföll till att använda Adobe-anti-kommunistiska-program utan korrekt använda min maoistiska anpassning av Emacs för att läsa pdf-filen (det tar ibland lite tid när man är ovan vid en teckenuppsättning man inte hunnit att lära sig och få tabell-anteckningar på plats men att äventyra allas större värden är givetvis - för alla trodde jag - ej acceptabelt):

Läsande artikeln minns jag mina egna år i den kinesiska Baidu-gruvan. Inget ger sådan tillfredsställelse som hederligt gruvarbete. Jag kan bara önska att det hade varit en riktigt Sovjetisk eller Rumänsk kolgruva. Ända med min gamla ishacka jag köpte för 20 år sedan undervärnplikten och en spade bredvid datorn får man ett gediget stöd moraliskt stöd. Baidu ska ej underskattas för vad som ges via internet (snarare än nödvändigtvis mobil-data som jag vet mindre om här) som gruva.

Jag hoppas att övriga arbetare på Baidu kritiserar bort all förrädisk verksamhet där jag anar att ett gömt berg måste finnas när man så är direkt första gången man läser deras publikationer ramlar direkt på anti-kommunistiska konspirationer med amerikanska jätte-industralister.

Measuring Economic Activities of China with Mobile Big Data
Lei Dong, Sicong Chen1, Yunsheng Cheng, Zhengwei Wu, Chao Li1 och Haishan Wu,
Big Data Lab, Baidu Research, Baidu, Beijing, 100085, China School of Architecture, Tsinghua University, Beijing, 100084, China

Dessutom upptäckte jag referens till någon Ali i adobe-filen. Kan detta vara någon separatist från Kinas östra regionerna?

horzAlignenum SliceHorzAlign default

Efterforskning i Wiktionary och nyhetssökning kan skrämma vilken rättrogen maoist som helst. Horz torde vara kodord för horse vilket Wiktionary kan förklara det troliga sammanhanget här för:

"(slang) The sedative, antidepressant, and anxiolytic drug morphine, chiefly when used illicitly."

Från: Horse

Och morfin framställs ur opium. Kinas gamla koloniala slavkedja. Vad frihetens fiender i ondskans industrialister tillsammans med sina brittiska drängar i brist verkligt fria tankar säkert förfallit till att tänka sig ska ta Hong Kong tillbaka men nu kanske med fastlandet.

Slice förstår vi av den av och till vanligare preferensen bland kinesiska subkulturer att använda bladet eller yxan som vapen. Också förrädiskt. Här kan vi lära av Lenin och Leon Trotsky (verkligen att konceptet av den eviga revolutionen för tankarna till något av "uppdaterings" eller "bug-fix" som lokaliserade mass-revolutioner på allt som likt Baidu förfallit ner till moraliskt fördärv) såväl som Medborgare Mao: Revolution kräver geväret. Vid sidan om rent tekniska fördelar gäller ju också att sabeln i Ryssland liksom svärdet i Kina olämpligt kan uppmuntra till osunt intresse av kulturhistorien där det svagare sinnet ibland kan fixera och förledas av att läsa om rikedomar och de maktdemonstrationer gigantiska krigståg uttryckte. Medan man svårligen kan se ett gevär utan att tänka på Lenin. Varje god kinesisk arbetare som ger sig ut för att jaga moralen tillbaka i landet ska självklart bära geväret tågande med soldat kamraterna som i gamla goda tider innan världs-industrins penningar köpt dem tillbaka in slavfabrikerna.

Kinas arbetare liksom vi levande under förtryck kan inte annat än hoppas - om inte arbetet i Kina ska behöva göras om med oss här när vi går in i friheten - att detta inte är ytterligare ett tecken på att Medborgare Xi säljer ut friheten för industrialisternas mutor. Flera månader nu har vi diskuterat att skriva ett brev till Kinas arbetare understrykande att de vaksamt behöver minnas att utan den kollektiva felkontrollen och korrigeringen via kritiken fylls friheten av omoralens ruttnande lemmar.

Minns hur omoralen och förräderiet fick Arbetare Sovjetunionen att ruttna bort...

Kina ta varning av Baidu! Frihet förslappar det svaga sinnets moral förruttnande revolutionen

För oss maoister tvingade att leva i krämar-världen industrialisternas slavfabriker här som i Kina är vardagen ej så rik som för Kinas fria arbetare. Här mitt i slaveriets ondska kan vi ej tillåta oss att förslappa vår vaksamhet på varandras moral. Kinas arbetare bör ta varning av vår större medvetenhet om den sluga industrialisten och ej när den goda kommunistiska produktionen finns låta lura sig.

Goda kommunistiska operativsystem där förutom några kinesiska - kanske också förslappade? - ett alternativ från mer hardcore kommunistiska Nordkorea finns: Red Star OS.

Trots det har de kinesiska forskningsarbetarna låtit sig luras av så väl slav-industrialisten Apple som Adobe. Vilket framgick när jag som mer medveten arbetare i den ideologiska svenska förskingringen ej förföll till att använda Adobe-anti-kommunistiska-program utan korrekt använda min maoistiska anpassning av Emacs för att läsa pdf-filen (det tar ibland lite tid när man är ovan vid en teckenuppsättning man inte hunnit att lära sig och få tabell-anteckningar på plats men att äventyra allas större värden är givetvis - för alla trodde jag - ej acceptabelt):

Läsande artikeln minns jag mina egna år i den kinesiska Baidu-gruvan. Inget ger sådan tillfredsställelse som hederligt gruvarbete. Jag kan bara önska att det hade varit en riktigt Sovjetisk eller Rumänsk kolgruva. Ända med min gamla ishacka jag köpte för 20 år sedan undervärnplikten och en spade bredvid datorn får man ett gediget stöd moraliskt stöd. Baidu ska ej underskattas för vad som ges via internet (snarare än nödvändigtvis mobil-data som jag vet mindre om här) som gruva.

Jag hoppas att övriga arbetare på Baidu kritiserar bort all förrädisk verksamhet där jag anar att ett gömt berg måste finnas när man så är direkt första gången man läser deras publikationer ramlar direkt på anti-kommunistiska konspirationer med amerikanska jätte-industralister.

Measuring Economic Activities of China with Mobile Big Data
Lei Dong, Sicong Chen1, Yunsheng Cheng, Zhengwei Wu, Chao Li1 och Haishan Wu,
Big Data Lab, Baidu Research, Baidu, Beijing, 100085, China School of Architecture, Tsinghua University, Beijing, 100084, China

Dessutom upptäckte jag referens till någon Ali i adobe-filen. Kan detta vara någon separatist från Kinas östra regionerna?

horzAlignenum SliceHorzAlign default

Efterforskning i Wiktionary och nyhetssökning kan skrämma vilken rättrogen maoist som helst. Horz torde vara kodord för horse vilket Wiktionary kan förklara det troliga sammanhanget här för:

"(slang) The sedative, antidepressant, and anxiolytic drug morphine, chiefly when used illicitly."

Från: Horse

Och morfin framställs ur opium. Kinas gamla koloniala slavkedja. Vad frihetens fiender i ondskans industrialister tillsammans med sina brittiska drängar i brist verkligt fria tankar säkert förfallit till att tänka sig ska ta Hong Kong tillbaka men nu kanske med fastlandet.

Slice förstår av den av och till vanligare preferensen bland kinesiska subkulturer att använda bladet eller yxan som vapen. Också förrädiskt. Här kan vi lära av Lenin och Leon Trotsky (verkligen att konceptet av den eviga revolutionen för tankarna till något av "uppdaterings" eller "bug-fix" som lokaliserade mass-revolutioner på allt som likt Baidu förfallit ner till moraliskt fördärv) såväl som Medborgare Mao: Revolution kräver geväret. Vid sidan om rent tekniska fördelar gäller ju också att sabeln i Ryssland liksom svärdet i Kina olämpligt kan uppmuntra till osunt intresse av kulturhistorien där det svagare sinnet ibland kan fixera och förledas av att läsa om rikedomar och de maktdemonstrationer gigantiska krigståg uttryckte. Medan man svårligen kan se ett gevär utan att tänka på Lenin.

Kinas arbetare liksom vi levande under förtryck kan inte annat än hoppas - om inte arbetet i Kina ska behöva göras om med oss här när vi går in i friheten - att detta inte är ytterligare ett tecken på att Medborgare Xi säljer ut friheten för industrialisternas mutor. Flera månader nu har vi diskuterat att skriva ett brev till Kinas arbetare understrykande att de vaksamt behöver minnas att utan den kollektiva felkontrollen och korrigeringen via kritiken fylls friheten av omoralens ruttnande lemmar.

Minns hur omoralen och förräderiet fick Arbetare Sovjetunionen att ruttna bort...

NoSQL med Rebel-AS: Berkeley DB prestanda optimerat i två kraftfullt enkla steg

Sammanfattat: 1. För-sortera (design pattern sort) stora chunk och 2. Stoppa in. Men glöm inte att stoppa in det sista datat.

Tidigare har jag haft stora problem Berkeley DB i att skapande av databaserna vid resp. 80 MB mängd databas gjord kom en stor tidskostnad. Längre ut kunde det i princip gå hur länge som helst. Av den orsaken hade jag tänkt ersätta det med något färdigt mer paketerat inkluderande mer av färdiga funktioner för dimensioner m.m. Men standardprodukter kommer ju med viss kostnad inlärning, legacy och för ex. MongoDB jag lutade åt att jag ogärna just nu vill installera om utvecklings-server från 32-bitar Ubuntu till 64-bitar (med 32-bitar är MongoDB ej meningsfull relativt vanliga hash-tabeller inlästa från fil därför att datat är väldigt litet).

Varför brytpunkt ligger där vet jag inte. Ev. är det just relaterat 32-bitars adressering i OS (jag har fått för mig att både den Berkeley DB jag använder, MongoDB m.m. alla normalt ej gör något mer underliggande eller långt ner i OS nära disk eller adressering utan använder ett färdigt anrop för stora filer att adressera likt minne i Linux). Det stämmer i alla fall ungefär i magnitud:

2³² (82 * 1024 * 1024) ~ 49.951

Men har alltid prövat det på samma filsystem (ej prövat det på mitt Ext3 - eller om det är Ext4 - jag prövar eller formaterat för att pröva i alla fall som tänkbart just för disk där NoSQL databaserna ska ligga längre fram: givet bl.a. ingen checksum m.m. passande för databaser där ej tänkt att ändras kontinuerligt och i behov av god prestanda relativt begränsad hårdvara - osäker om det gör praktiskt kommer göra märkbar skillnad eftersom jag egentligen aldrig varit i närheten av storleks-magnitud totalt data som kommer behöva hämtas kontinuerligt men anar att det kanske gör skillnad).

I Rebel-AS jag döpte en fortsatt egen legacy NoSQL jag byggt ovanpå just Berkeley DB har jag samma fördröjning som funktion av cirka 80 MB nedsläppt. Men nu mycket snabbt skapande av databasen. Ett natal GB med inlägg från bloggar och sociala media för fortsatt analys handlar om ett fåtal timmar eller kortare tid (satt ej och tog tid på det framför datorn).

Berkeley DB snabbt: Sätt dig ner och sortera nycklarna åt datan (likt programmera: människa gör det kostsamma - datan gör egentligen föga)

Och hela skillnaden i prestanda ligger i vad jag trots av och till utdragna - säg fyra timmar totalt - försök att hitta en förklaring och lösning ej hittade alls. Förutom mer av slump slutligen i en kort kommentar till en fråga svår-hittad både nu och tidigare (möjlig utgångspunkt: Berkeley DB Slow via sajt-sökning med Google).

I övrigt läsande på Stack overflow fick jag ut föga värde. De flesta verkar heller inte göra särskilt stora databaser. Exakt vad orsaken är eller varför det ev. är god vana vet jag inte. Databaser har aldrig särskilt intresserat mig och ingenting jag direkt önskar att lära något mer än nödvändigt om. Jag hade snarare föreställt mig att det logiska vore att om distans eller skillnad mellan nycklar som går in pre-expanderar man motsvarande fil mycket mer för att slippa flytta om datat senare alt. slippa hantera kollisioner via redundant för träffar nycklar eller pekare vidare till annan position.

Hans reflekterar vad han redan lärt och slutade lära cirka 2003 rörande databaser och tyckte sig inse att det räckte bra nog ändå: Datan gör ungefär samma fel varje år även om skärmen blivit skarpare och hårddisken större

Det är när jag spekulerar kreativt utåt bra att komma ihåg att min vetskap databaser snarare än hash-funktioner, kataloger (typ Open LDAP) eller för evigheter sedan fil-databaser via radnummer respektive:

LIST RANDNUMMER

på Commodore 64 någon gång i årskurs fyra när datorernas sanna små-defekta natur inte doldes lika smygande riskfyllt som idag: Ex. databas genom att lista "programkod" - lika gärna text eller annat data så länge man inte kör koden som BASIC II. Istället listade man programmet - eller en del av programmet där datat fanns men som ej kördes just för dom raderna. Ex. LIST 3210 - 40000. LIST liknar hemvant trevliga goto men var sundare strukturerat genom att utnyttja entydiga nummer istället för dom kvalitetsprobglematiska labels vi säkert alla gärna förfaller till likt abc, donxt, do_next en bit nedanför med svårbegriplig beräkning mellan förändrande värde, odd_erorr, debug_but_do_not_remove_it m.m.) syntax för att ta ut en datapost från dess början på rad enligt första numret till dess slut på den andra siffran - plus så klart för stora databaser behov av att ladda in grupper av poster från olika delar på kassetband utiliserande s.k. "spolning" / "att spola fram eller bak bandet§" - eller rent av krävande många kassetband) är så begränsad men dessa tre tillsammans gav mig en känsla av att jag sådant som Berkeley DB borde vara begripligt för mig. LIST är heller inte olikt hur många idag gör lookup från indikation vi vill fråga med (ex. URL eller sökord) till radnummer i enorm fil där själva datat för sökord eller URL ligger lagrat (och så klart snabbare i absolut-mening idag jämfört med C64 men inte mycket högre relativ prestanda).

Stora nycklar en aning mer kostnad ibland för-sortera men ev. högre prestanda skapande databas

Något besläktat - kanske relaterat implementation på vad - ges här också StackOverflow: BerkeleyDB - implications of incorrect sorting order? (via cache-Google: ibland når jag ej StackOverflow vilket jag trodde berodde på att jag råkat spindla deras kategorier hårdare än korrekt programmerat för statitistiskt analys av inlägg men ganska ofta fungerar den så ev. relaterat någon defekt på Stackoverflow kanske relaterat last så jag länkar indirekt istället och tror ej det tolkas av spindlande entiteter som problem prestanda eller tillförlitlighet med sajt länkad). Om det egentligen stämmer som skrivet ofta eller alls vet jag inte.

Vad jag märkt är emellertid att ingen kostnad för mig existerar av att använda större nycklear (undantaget ev. ökad risk för kollisioner och hantering av det: men jag vågar gissa att vettig hash-funktion används och om så troligt föga problem). Och längre nycklar om en mappning mellan nyckel och position (snarare än jag hade föreställt mig motsvarande MD5 - jag vill gissa att föregripande lookup-up till värden från nyckel finns och att hasching kanske ej görs till en redundans-reducerad form som för MD5) finns motsvarande "komplexiteten summerad" nyckel innebär det ju mer exakt vetskap om relativ positionering. D.v.s. kommer fler entiteter gå in och vi tar in dem i chunk vettigt urtagna innan sorterade föreställer jag mig att det kanske tvingar upp lite vettigare initial hantering föreberedande för att mycket kommer in. Jämför att sortera:

AAAAAB AABAAA br/> resp br/> AAAAAABAAAABBBBAAAA AAABAAABAAAABBBBAAAA Eller motsvarande mina nycklar datum och tid publicering, länk indikerad övergripande RSS eller ATOM "sajt", domän uttagen över inläggen för resp. länk till inlägg (d.v.s. kan vara annan än sajt), titel på sajt indikerad, titel inlägg, resp. hela sökväg feed där data hämtades (ej exakt i samma ordning mot mitten ev. samt inkluderande en till indikation om källa i URL-mening). Poängen längd ligger i att gå över alla nycklar utan hänsyn dimensioner för annan lookup för enklare förändringar, kontroller m.m. där allt nödvändigt för mycket finns direkt för varje nyckel (ex. för en del underhåll kontrollera om ett datum finns eller ex. som nyligen defekt-data ej önskat som läckte in: <![ eller liknande ibland förekommande i RSS-strömmar ev. för "sekundärt" data-relaterat innehåll (just här för sajt-länken för ganska många vilket missades vid skapandet).

I en värld där resp. två nycklar för de två grupperna egentligen motsvarar samma nycklar men där de första kommer ge fler kollisioner tvingande fram att append görs för resp. om plats finns, och när plats lokalt i filen där lagring redan skett saknas tvinga fram en pekare till nytt data allokerat på disken eller värre (ej kanske otroligt givet prestanda kostnaden jag fick tidigare) att data flyttas om ständigt görande att en ny växande jätte-fil behöver lagras gång på gång för varje 80 MB med exponentiellt växande tid för det eftersom komplexiteten att göra det ökar när resp. omflyttning kan inverka på nästa omflyttning. Om nu den Berkeley DB implementation jag fick via Perl (eller om den ligger ovanpå något i Linux) är riktigt dum kodad (elegansen i Berkeley DB är ju att det är enklaste tänkbara så mycket möjligt förväntas förståelse och ansvar hantering liggan ovanpå).

Tänkbart faktiskt en tids-kulturell-atavistisk företeelse. Berkeley DB har ju funnits så pass länge att problemen och utmaningarna när etablerad var mycket annorlunda: RAM-minne relativt litet (men kanske problem-baserat jämförbart) men förr var hårddiskar som nu inte mer eller mindre kostnadsfria om man inte behöver lägga på mer än några tera byte. Ev. lite default optimerad för att ej börja med att skapa en rimligt tilltagen fil (kanske konfigurerbart men jag såg det ej via Perl gränssnitt i DB FILE och utan att kontrollera konfigurations-loggar vet jag ej om jag installerade på något kompletterande).

Appendix A: Design pattern sortera nycklar i två enkla steg

Pre Berkeley DB power sorting:

1. Ta ut nycklar från mellan-lagring i Perl's vanliga hash-tabell. Exempel:

my @keys = keys %ldb

2. Sortera nycklarna. Exempel:

@keys = sort @keys;

Och stoppa in i Berkeley DB via lämpligt för det. Glöm inte att synkronisera mellan-lagrat data i sista steget. Vi antar att vi stoppar när överskridande viss storlek med målsättning att söka göra det med så stora chunk i taget som möjligt för att inte Berkeley DB ska allokera onödigt små-utrymmen i varje steg givet att om inte allt data redan är sorterat gäller att en del omflyttningar eller vad Berkeley DB nu gör behöva ske. För mig cirka 900 000 blogginlägg med RSS-meta översatt till trevlig CSV-fil (som vi i en rimlig värld hade haft direkt på webbsidan istället för SGML-rekursionens onödiga komplexitet praktiskt oavsett hur elegant språkteoretiskt). EFtersom blogginlägg kan komma från entiteter vid en tidpunkt efterföljande vad vi stoppar in idag okänd gäller att inlägg vi ska stoppa in ofta nog i perioder när tidskostnaden kan ha betydelse (d.v.s. spindlande ifatt internet där jag just nu ett tag expanderar antalet entiteter publicerande med cirka 50 000 till 100 000 per 24 - 36 timmar men räknar med att stoppa det om en eller ett par veckor) vara äldre och ej följande logisk ordning i övrigt samtidigt som jag tyckte det mindre tilltalande att försöka lägga till en bokstavsräknare initialt eftersom jag gärna vill kunna ta ut alla nycklar optimerat i meningsfull ordning att se ungefär var saker befinner sig i tiden vid underhåll o.s.v. via snabbtitt skärm.

Betryggande nog när vi står kvar på en robust gammal välkänd komonent är den välanvänd av andra gamla lösningar man känner igenom sedan snart 20 år. Ett fåtal från Wikipedias längre lista:

"MySQL database system – Prior to v5.1, MySQL included a BDB data storage backend.
OpenLDAP – A free/open source implementation of the Lightweight Directory Access Protocol (LDAP)
Postfix – A fast, secure, easy-to-administer MTA for Linux/Unix systems"

Även om det får erkännas att min lilla praktiska erfarenhet av MySQL och Postfix var en brutalt plågsamt fascinerande verklighet: Så slött saker kan bli med eller utan på det Apache resp. karttjänster ovanför. Men OpenLDAP är ju bra även om det var ett antal år sedan jag gjorde något med den. Och menar - det kan kanske diskuteras - Wikipedia dessutom något färskare news-fresh:

"Bitcoin - A distributed peer-to-peer open source digital currency."

Fortfarande lite små-coolt att skapa stabila stengolv med Berkeley DB hellre än något vulgärt IKEA-färdigt golv som limmas eller nitas. Riktiga värden som håller många år byggs med stenhacka och förståelse av problemen man vill lösa med att bygga golv.

Tidigare från samma domän av stegvis kreativt skapande för undvikka samma välkända strunt-problem i datan nu som på 1980-talet

Som Rebel-AS levererar sin lösning till:

1. Steg I: Behovet av praktisk big-data utan mina enkla ganska brutala ta in och ut ur minnet läsande data uppdelat i mindre filer resp. den gamla Berkeley DB lösningen där ingen databas praktiskt gick att ta större än 80 MB (d.v.s. samma problem praktiskt ungefär: många fil-accesser, opraktiskt att strukturera, och ordentligt med extra-logik i koden). Men eftersom vi är i domän av databaser blir det ändå segt eftersom jag varken kan eller vill lära mig teorin för dem. Varande så inarbetat sedan år borde det tycker man bara fungera.... Likt hash-funktionen i Perl.

• NoSQL och Sun's och övriga hårdvaru-inriktades problem att orka med dom teoretiska utmaningarna vi alla behövt sedan år (2013-09-02)

Plattform jag reflekterade som tänkbar lösning: Mongodb.org. Huvudsakligen därför att den av flera indikerades snabb och endast i föga läsande dokumentationen verkade ha "överdrivna databas" relaterade funktioner: enkel och begriplig närmare hash-funktioner jag ju redan tycker mig kunna. Mindre risk onyttig inlärning. Och startade smidigt dessutom. Men hade fodrat ny installation Ubuntu om praktiskt funktionell vilket just nu ett tag är opraktiskt på utvecklingsservern.

Och diverse små-tester, läsande m.m. resulterar slutligen i att jag väljer samma teknik-plattform som tidigare förutom att skärande cash-logiken för parallell också utan Berkeley DB (användes uteslutande för similarity beräkningar mellan koncept där cirka 900 MB - 2 GB förberäknade värden fanns mellan koncept vars similarity oftare var efterfrågade eller förväntades vara det: dessa tar annars upp till för värsta tänkbara om gjord med hög exakthet närmare 20 minuter - och för aktuell version Blue light gällande i denna lösning fanns cirka om jag minns rätt 10 miljoner relationer bedömda troliga över cirka 140 000 existerande koncept jämfört med nu några miljoner koncept och ett okänt antal relationer troliga att återkommande behöva ta ut likhet m.fl. operationer applicerade för inkl. nu att fler resp. större andelar av vikter använda ska beräknas kontinuerligt uppdaterade vilket expanderar upp data tvingat via cash än mer så att det kan göras u bulk ett par gånger pe rdag - hence att databas-problem blev löst trots databas-fobi).

• Riktad sampling Blogger för ökad tillförlitlighet (och pågående unikt problematiskt internet från min accesspunkt) (2014-04-21) (och Google: Feedburner, Youtube och Feedproxy.)
• Resultat spindling efter RSS- och ATOM-strömmar (2014-04-27)

Mycket typisk mänsklig problemlösning i den ena av två grova grupper kreativitet vi kan se. Här stegvis-förändring sökande behålla värde vi har (eller ofta nog slippa lära något nytt). Äldre mer erfarna kan prestera väl i företagsutveckling i denna domän. Vanligt i antal nya företag ovanför detta är konsultverksamhet byggande på upparbetad vetskap om en form av problemlösning eller förståelse av en verksamhet. Den andra domänen är innovation i emergence skapande något radikalt nytt.

Säger vi att emergence är kontextuellt beroende utifrån ett perspektiv - här jag om tvingad att behöva lära något externt system nytt för mig resp. behöva plåga mig med att sätta upp nya version Ubuntu och ett ganska komplext legacy-system liggande ovanpå: ny kunskap, nya komponenter adderade och inte otroligt nya värden svåra att förstå från Berkeley DB perspektivet - har vi ex. när en metod från ett annat expertområde inses optimera i ett annat eller när en upplevt ny upptäckt kommer (för vilka ofta gäller att olika individer oberoende i vad ytligt uppenbart gör samma upptäckt ungefär samtidigt i tiden d.v.s. latenta faktorer existerar). Tidigare diskuterat många gånger även nyligen i år Emergence relationer - Emergence demokrati (2014-04-21). Innovation via emergence är ibland oftare lättare för yngre: de kan ju föga från början och har inte lärt sig hur det ska gå till att hämta upp data lagret (kanske inte ens hört talas om X.500, LDAP eller MD5).

Lite som att redan förstå varför allt i datat alltid ställer till med små-problem och hur vi ungefär löser det. Relativt att söka en ny givet viss tid mellan inlärt problemen och nutid möjligt bättre lösning kanske genom att elt undvika problemen.

• Minimalistiskt sido-algoritm-skiss beräknande läsare nyhetsmedier (2014-04-30)
• Minimalistiskt sido-algoritm-skiss beräknande läsare nyhetsmedier II: Algoritm omvandlande tidskostnad referera nyhet till förtroende publicist (2014-04-30)
(Och mer kompletterande de sista snarare än just relaterat lösning i problem-domänen för mig varande vad inarbetade algoritmer med föga behov förändring finns för: arbetet här och relaterat har mer att göra med att ta saker större i antal koncept vi förstår och ser, mängden statistik relationer, antalet publicister hanterade, antalet "skrivande läsare" analyserade o.s.v. för vikter diskuterande rörande ungefär emotionell intensitet: Att välja mellan kontext och känsla vid betraktande av "minnen" (2014-04-20) i mening att göra referensen begriplig ungefär vad avsett).

Mycket stora mängder data: MongdoDB tycks mycket stark och trygg inför det IT-kaos framtiden kan tillföra

Mycket tilltalande att se att konceptet av hash-tabeller jag alltid använt vid sidan om kataloger växt till NoSQL med starka lösningar. MonggoDb känns som det starkare alternativet för mig och vad jag tänker pröva när jag kastar ut en del enkla ad-hoc-lösningar (inte minst för att ge bättre administration såväl som bättre prestanda).

Av allt att döma redan utvecklad med brett stöd för enterprise indikerar att den troligt lever kvar utvecklande framåt. Flera större entiteter som använder den såväl som många mindre indikerar det samma såväl som värden. Bland dessa ex. New York Times, SourceForge och eBay (fler exempel: MongoDB - Production deployments | Wikipedia).

Tidigare prövade jag en lösning för att fil-databas som fungerande tillräckligt och acceptabelt när filerna är byggda. Men oerhört långsam att skapa (användande färdiga api:er snarare än att skriva filen åt det). Kom ganska snart någonstans vid säg 60 till 80 MB. orsaken känner jag ej men den var konfigurerad som hash-tabeller så ev. något där (möjligen relaterat att jag dumt nog byggde min Linux till utvecklingsdatorn 32-bitar. Och relaterat MongoDB och 32-bitar noterar vi Criticisms). Men egentligen helt orimligt slött från allt jag lärt om hash-tabeller resp. indexad access hoppande i filer genom åren. En ganska snabb variant jag gjorde för många år sedan för att slå upp om jag kommer ihåg rätt hash-värden från MD5 var med en för-4enklad variant av MD5 med reducerad säkerhet givetvis men istället för snabbare och hade få kollisioner (över en större mängd hash av MD5 givetvis relativt MD5 märkbart men här var mängden relativt liten och knappt någon alls).

Och också om den kostnaden ev. finns här tror jag knappast den är väsentligt större med klient på samma dator och där kan man lika gärna givet en så väsentlig kostnad se till att få fullt stöd i övrigt för allt som kan underlätta resp. behövas för framtida anpassningar eller utvecklingar.

Mer MongoDB:

Perl client-driver: metacpan.org/pod/MongoDB.

GEO-världens centralitet är svår att skatta (utanför Stockholms enkla svar)

Sveriges mindre forsknings- och utbildningsorter skiljer ut sig ibland - åtminstone retoriskt i ögonblickets upplevelse - genom att ställa frågor hellre än att leverera någon litet beställt resultat en åldrad professor behöver till en 40 år gammal intellektuell argumentation med en kollega i andra delar av världen. Och om nu utbildning inte är ett av Gävles större värden ligger vad annat det kan vara långt utanför min Gävle-vetskap (om vi lämnar rena efectos especiales som att bränna julbocken vilket självklart föga utanför de verkliga storstäderna kan mäta sig med). Med ett fint illustrativt citat just noterat:

"Geospatial analysis is very much dominated by a Gaussian way of thinking, which assumes that things in the world can be characterized by a well-defined mean, i.e., things are more or less similar in size. However, this assumption is not always valid. In fact, many things in the world lack a well-defined mean, and therefore there are far more small things than large ones."

Från: Geospatial Analysis Requires a Different Way of Thinking: The Problem of Spatial Heterogeneity
Bin Jiang
Department of Technology and Built Environment, Division of Geomatics
University of Gävle, SE-801 76 Gävle, Sweden

Om jag nu för att bestämma mina medelvärden samplar ex. pressmeddelanden, nyheter, wikipedia eller liknande uppslagsbok, e-post-spam m.m. kan nu för ex. en företags-entitet orten EN_PÅHITTAD_EX_ORT aldrig förekomma eller ytterst sällan trots att den är basalt självklar för företaget för den som känner den lokala kulturen och nutidshistorien för företaget.

Kanske någon tråkig avfolkningsbyggd i Sverige där man har ett par viktiga fabriker inom ett teknikområde därför man en gång i världen var tidens föregångare till skogsbolag innan man gav sig in i telekom. Men det är kanske ej vad upplever tillför värde att diskutera i samband med produkter och tjänster.

Emellertid blåser det upp till den Historiskt unikt gigantiska stormen utanför LÄMPLIGT_NAMN_PÅ_VÄDERFENOMEN_SMHI_BRUKAR_REFERERA_VI_ANNARS_ALDRIG_HÖR_TILL kanske någon väderkunnig maskin-intelligens - eller oftare med dåligt geo-samplingsdomän människa - dra slutsatser om att träd kommer rämla ner träd, byar som sköljs bort (m.m. av dom svormod vi lär från lokala orters referade sorg rikspolitiskt varnade oss alla från att låta avsaknad av vägar, tåg, sjukvård m.m. förstöra från ev. investeringar).

Detta är en egenskap i geo-koncept när vi söker få mätvärden att hantera jämfört med många andra koncept. Om nu Jian, i Gävle, avser ungefär samma får jag reflektera när jag läser den annat än i mer uttryckta delar.

Emellertid upplever jag egentligen inte att GEO nödvändigtvis särskiljer sig här. Vi har en hel del domäner med mycket liknande rent allmänt. Common sense strukturer är ett försök att hantera det även om dessas breda blandning av allt man kan påstå sig veta är nog (IS) och jämförbart för blicken från den egenskap ibland möjlig uppenbar i GEO (om än långt ifrån alltid meningsfull att fokusera på): en gemensam "common sense" för hur man resonerar om distanser d.v.s. möjlighet att "fara" från A till B, den tid det tar, och som gemensamma variabler oavsett fordon o.s.v. avstånd i flygplans-sträcka och tid.

I den mening har vi samma utmaning - eller kanske möjlighet till förenkling med samtidigt bättre funktionellt resultat än statistisk smoothing i ngram-modeller - för många kunskapsområden. Ev. oftast (alltid som jag representerar vetskap) funktionell att beskriva i grafer. För grafer med uteslutande geo-koncept kanske vi representerar platser något kan ha att göra med som noder och avstånd mellan noder som variabler vilka parametriserar funktioner indikerande tid att fara mellan dem och hur mycket ansträngning en lokal-engagerad by-bo bör investera på att förklara för tåg-fientliga rikspolitiker betydelsen av att göra mer infrastruktur. En konstnär - eller oftare idag mer vetenskapligt lagt resp. än mer standard-förestående kartograf - kan sedan rita en bakgrund med skog, sjöar, vägar o.s.v. så har vi för en given mängd värden av alla parametrar till funktionerna en karta (d.v.s. motsvarande bilkartor m.m. som individen med sin biologiska kognition utnyttjar för att applicera parametrar man upplever sig veta värdena för eller som någon längs vägen påstått sig veta svaret på).

D.v.s. utan att riktigt läst allt håller jag både med och avviker något i den tolkning jag läser in i ett stycke citat av sammanfattningen. Det är förvisso så men bäst bör vi se det som ett problem vi löser i bäst på bättre medan vi uppmuntrar avbygdens medborgare att uttrycka data rörande samband mellan kart-noder (och alla andra noder) i språk såväl som gps-utrustning monterade på cyklar m.m. Kanske utiliserande Wikipedia, Facebook m.m. kombinerat med tävlingar, coola-hemsidor där deras cyklande märks m.m. man kan sampla för ungefär samma algoritmer som annat data om än normaliserat in för the brutal world defining import skalande bort individen, allt kul o.s.v. och få ut något nyttigt användbart av det.

Ett till område jag inte vågar säga särskilt mycket om därför jag har inte försökt det seriöst tolkande själva datarepresentationen utan hellre väntat på något närmare händelse-relaterat eller mer språk-association-mellan-koncept uttryckt är dataformaten för kartor kombinerat med data från när refererade i praktiska sammanhang ex. och aktuellt för ex. när de efterfrågas via gränssnitt där kartorna kan sökas (om jag inte blandar samman något liknande enklare med vad jag ser som optimalt i ej otroligt priseffektivt). Mycket troligt bäst refererar man för området Openstreetmap (där både format, själva problem-området såväl som numera diverse aktiva eller avstannade projekt på olika nivåer samlats genom). Jag tog nyligen ut data från något mer färskare där man tror det i alla fall som jag fick ut det är ganska lågt i ort-detalj-densitet (en myckenhet i subkulturella karttermer finns och jag hittar på en här uteslutande för att uppmuntra läsaren till att lära alla och ej därför att jag ej har en mycket gedigen förståelse och vetskap om den både på latihund och longitud d.v.s. för dem det är nya begrepp för vertikalt resp. horisontellt eller lodrätt och vågriktigt).

En försvarlig mängd inlägg rörande GEO finns från åren bakåt jag hoppas ska räcka när kombinerat referenslitteratur, landsbygdens goda kreativ och hemmets datorer för att skapa en större mer värdefull infrastruktur om dom statliga anslagen till vägar och tåg helt försvinner (möjligen - vet ej i närheten av säkert - ett byte både stadems och landets folk kan vinna på: ett bättre bredband med inspirerande blogginlägg men mindre väg och föga tåg). Några ämnen att starta från:

• Geonames
• GEO
• GEO-data
• Navigering (värdet och relevansen i datat)
• OpenStreetmap
• GEO-SEO (två grupper av samverkande "dimensioner" jfr att navigera med bil eller cykler för att köpa matta resp. en tidning)
• Common sense

Externa resuser:

• 10’000 km of Ways added in 10 Months – New OSM Road Length Statistics for Switzerland | sosm.ch Och så ovanligt för föredömen användbart även om man inte följer föredömet och som här cyklar runt en massa.
• Potential Datasources | Openstreetmap Openstreetmap oavsett geo eller annat kunskapsområde är här ett föredöme: att datakällor vettigt förs samman mer färdigt att imponera från en källa med färre övriga är närmast unikt för geo. Jag bugar för det hela och hoppas att det tunga kompetens samlat här scarce i övrigt kanske en dag känner sig modiga nog att försöka samma sak för museumföremål (allt vi hittar på museum och kan finnas i deras katalog och/eller vara utställt med relevant meta-data)... En del har försökts men föga med den kraft och korrekt inkluderande alla viktiga domäner för ett sådant projekt helt unika erfarenhet dom viktiga kulturbärare i Openstreetmap besitter. Utan dem inget eller föga bra kommer. Kanske går det rent av få in någon mätutrustning som gprs eller liknande ev. med värde för turister också om jag inte riktigt ser poängen för vad som mer intresserar mig.

Tennis-, Kalle-plan och Bollebyggden och alla andra bortglömda orter står mig aldrig längre bort än att jag kan finna glädje också kalla vinter-nätter när jag mediterar över deras tröstlösa kamp mot hungern och kylan

I löst relaterat går det givetvis att mena att jag roar läsaren - och stärker mitt självförtroende och vetskap om mitt värde - genom att trycka ner landsbyggdens folk och deras äldre kanske bättre traditioner och verklighet. Men samtidigt ser jag dem och jag tror de kvarståendens största utmaning idag är att de försinner i ett mörker i urskogen de flesta idag inte vill eller kanske vågar besöka ens för att söka ett kulturellt värde att i komik-gruva hämta ut till Sveriges flertals värde av och till tillförande den motivation så många behöver adderade för komma sig för att lära sig allt om GEO-världens tunga men viktiga utmaningar.

Bäst tror jag inte att det är fel att jag i språket beger mig ut i svårare lidande värld mindre just för att gör mig rolig åt dem och mer för att vi alla behöver våga se dem, deras infrastruktur-svält och det rättmätiga hatet mot stor-butolermas itsigamde av den locala ICA-butiken. Att det nu kan ge mig lite bättre självförtroende därför att jag blir tryggare i mig själv såväl som att läsaren kanske skrattar är ju bara en drivkraft för att svårmodet inte ska glömmas bort.

När nära nog alla titar bort vågar jag väcka debatt och tankar genom att skapa glädje. Tycks jag inkorrekt hånfull är det endast för att jag vill naturens folk och deras kultur väl. Vi ska ju ej förglömma att de är nära nog kritiska för att sampla upp kartorna och få in alla koncept relaterade kultur och geo så att det kan mätas upp kostnadseffektivt (som vattenkraften men med naturfolken snarare än vattnet för värde).

Kina största nation när det gäller handel? Kommer DARPA ge oss svaret?

Rörande följande:

• China rejects status as world's biggest trader | The Miami Herald

Resp. tidigare uppgifter om att Kina är störst är hur man normaliserat valutorna inte oviktigt. Och om man klarat att hålla sitt big-data sunt utan datafel som propagerat.

Jag noterade nyligen i nyheter men har inte läst rapporten att man värderat om Kinas handelsöverskott med ca 25%:

THE Organisation for Economic Cooperation and Development (OECD) and the World Trade Organisation (WTO) released intriguing results of their joint Trade in Value-Added Initiative last month.
The study analysed "the value added by a country in the production of any goods or service that is then exported".

[...]

That is the reason China's trade surplus with the United States was estimated to be 25 per cent lower than using the conventional exports-minus-imports measure, indicating "the high level of foreign-sourced content in Chinese exports".

Från: Trade talks take one small step | New Straits Times

Min erfarenhet av den sorts statistik sådana här rapporter och analyser bygger på är att man går uppåt från en mängd detaljer till sammanfattade slutsatser som blir görliga. På den vägen är dock risken för att datafel ska propagera väldigt stor (precis som att det motsatta också kan vara möjligt d.v.s. att datafel försvinner långa perioder av "slumpmässiga" orsaker för att sedan plötsligt få betydelse). Kan man för sin applikation acceptera en felmarginal på ca 25% har vi ju åtminstone ett exempel på att det inte ställer mindre krav än datat orkar.

Problematiken är absolut ingenting unikt för ekonomiska uppgifter utan jag har genom åren när jag importerat från olika organisationer, datarepresentationer för universitet, grupper m.m. kunnat konstatera dem i det mesta från ontologier, Wikipedia-extraktioner till ekonomisk statistik.

Ett exempel diskuterades i:

• Kvalitetsproblem i Världsbankens statistik för Internet (2010-12-16)

Särskilt intressant med Världsbanken som ex. vilket ej tas upp är att datat de sammanställt kommer från en mängd källor. Det illustrerar väl en sida av dessa problem. Datafelen kan vara i data som du har dålig kontroll över rörande hur en annan organisation arbetar med quality assurance. Ett test man praktiskt kan göra själv när det har betydelse är att leta rätt på tydliga fel (finns alltid att hitta i den här typen av data) och testa organisationen genom att rapportera det. Jfr. exempel som med Wipo och PRV:

• Antal patentansökningar och varumärkesansökningar: Möjliga datafel mellan Världsbanken, WIPO och PRV (2010-12-11)

Där jag inte såg några särskilda indikationer från WIPO på att de då hade färdiga rutiner för att hantera indikationer på datafel.

En del idéer rörande dom här frågorna från landet med världens största krigsmakt och (kanske) näst-största handelsnationen trots modigt importerande inte minst från Europa och Kina har vi ett ganska färskt Darpa-projekt:

"The XDATA program aims to meet challenges presented by this volume of data by developing computational techniques and software tools for processing and analyzing the vast amount of mission-oriented information for Defense activities. As part of this exploration, XDATA aims to address the need for scalable algorithms for processing and visualization of imperfect and incomplete data."

Från: XDATA | Darpa.mil

Ett mycket starkt paradigm i detta område när det är möjligt är att se datakvalitet och datarelevans som i vilken utsträckning det för ett praktiskt värde klarar att prediktera framtiden. Det gör att man slipper i big-data när det handlar om väldigt varierat data mycket problematiska beräkningar och kontroller, och antagligen inte oviktigt för en krigsmakt eller underrättelsetjänst klarar det att hantera att värdet i datat kan variera över tiden bl.a. styrt av förmågan att klara att ställa rätt frågor.

Egentligen ska jag inte skämta över Darpa eftersom jag tror att jag ligger bit (inte otydligt) före dem för saker jag har skäl att tro blir aktuellt att handla upp längre fram något besläktat med detta. Men eftersom fallstudie: humor pågår är det svårt att låta bli. Nedan har vi Darpa's pressbild illustrerande big data:

Kanske hur Darpa upplever och känner runt det big-data de möter idag på jobbet?

Nedan har vi en av projektets viktigaste målsättningar:

"DARPA's XDATA program was launched to create tools to assimilate and process mountains of data that come in disparate types and sizes, and then provide visualization tools to allow users to analyze trends and glean value from the data."

Från: EXTRACTING RELEVANCE FROM MOUNTAINS OF DATA | Darpa.mil

Vi inser varför de köper in kompetens över ett antal projekt från olika företag och organisationer (och antagligen egna myndigheter och funktioner). Jag menar jag ser som inte ens vad det är för sorts big-data de har i sin bild? Binära-siffror. Ett vanligt stolp-diagram skulle säga mer. En geografisk karta tror jag kan fungera bra både för soldater och skeppare.

Också på temat datakvalitet berör ju vår förmåga att bedöma och förstå vad det är för data vi egentligen extraherar från en källa. Just Google har jag egentligen aldrig praktiskt använt för NGRAM-frekvens eller association (förutom Google NGRAM), och oftare har jag tittat på specialiserade datakällor (och en del som test också Microsoft bredare). Diskuterat närmare slutet i:

• Google googlar med Google-NGRAM: Antalet indexerade sidor fel (2013-02-10)

Ovan vad är definitionen av ett koncept som sökord "konc ept" avseende antal dokument instanser. Och hur jämför det med ex. "konc"? Kan vi få fler träffar "konc ept"? Är det inte dokumenterat vad mätvärdet egentligen avser och användningen radikalt skiljer sig från vad det är avsett för blir det upp till oss att försöka bedöma.