NSA: Romantisk datamining av Hans möjlig via Google+ (och accepterat)

Oavsett hur man ser på NSA-frågorna i övrigt var Snowden-incidenten en god indikation på att NSA hanterat intern-säkerhet långt ifrån väl, och en hel del specifikt som blivit känt har demonstrerat att deras hantering av den interna säkerheten varit dåligt skött. Ett exempel är medarbetarnas romance mining i data man samlat in: NSA Officers Spy on Love Interests.

Men problem kan ibland ha värde. För hela Snowden-incidenten givetvis stimulans bland media-entiteter genererande säkert god utökad trafik. Och om vi vågar spekulera att The Big Government möjligen utövat tryck på Google kanske följande önskan att få min sociala status i domän romance indikerad ett tecken på att någon - i min erfarenhet från likartade domäner inte sällan flera - statistiskt troligare kvinna hos NSA finner mig intressant. Antagligen en stereotypisk matematiker utnyttjande sociala verktyg mer naturliga för en sådan inriktad mot data mining - som här öppet-data - att se:

Eller kanske några kvinnliga Google medarbetare? Just nu i alla fall upplever jag som en insight indikerande förändrad syn på NSA's romance-mining och konceptet rent allmänt. Det kanske inte är så fel egentligen? För öppna datakällor i alla fall kan det tänkbart vara en prisvärd löne-förmån att få söka runt mig eller andra med NSA's verktyg. Jag ser heller inte alls ett problem att uppmuntra p.s.s. gärna vackra och konceptuellt-tydliga Google-medarbetare (ex. indikerat via storlek options-program eller liknande men givetvis för tydlighet snarare än något ekonomiskt intresse) att göra romance-mining på mig.

D.v.s. jag lutar nog åt att romance mining ej är ett problem när det sker i en väldefinierad policy. Relaterat där kan jag ex. tänka mig att etablera en datakanal till kvinnlig medarbetare NSA (ex. web-cam) men först efter att fått möjligt att godkänna "avlyssningen".

Sveriges OS-seger imponerar inte: Vanskötta symboler reducerar effekt möjlig

Av en slump råkade jag passera förbi teve visande just en svensk OS-seger i skidor (stafett kallades varianten). Tråkigt nog kändes det inte alls välskött:

• Klädsel hade föga naturligt uttryck för Sverige i färger. Mängden gult så begränsad att jag spontant hade gissat på Finland.
• Flagga segraren skidade runt med var genererande liten. Också om möjligen reglerat finns givetvis inget problem praktiskt med att behändigt tillföra en egen flagga planerande lite efter vägen.

Nu vet jag egentligen hur stora summor vi som samhälle investerar i idrott från föreningar för barn och ungdomar upp till stöd kring tävlingar m.m. Jag tycker mig minnas att åtminstone delar av polis-organisationernas insatser numera är vad man tar betalt för mig.

Gissningsvis kostar det hela dock ganska mycket pengar. Värde folkhälsa översätter ju väl till besparingar men sådana systematiska värden känns inte som en ursäkt att inte ha god kontroll över möjlighet till andra värden ex. brand building.

Här även om segern inte känns genererande och pinsam så i alla fall onödigt anonymiserad mot andra länder. Andra nationer behöver få stort uttryck av de svenska symbolerna för att de ska ge något systematiskt adderande överhuvudtaget. Där enligt principer för relativa uttryck (vad jag ibland kallar Webber information)) är ju ev. reglering av flagg-storlek för segrare praktiskt en god möjlighet till att få ett större avtryck av en korrekt - men regel-divergent - flagga rörande storlek. Och om nu ej reglerad konkrett miss-management.

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.