Visar inlägg med etikett Oracle. Visa alla inlägg
Visar inlägg med etikett Oracle. Visa alla inlägg

Mer av Oracle's teknik-komik hade gjort att jag hellre oftare skrivit om Cisco

2015-09-30

Förvisso har en del anmärkningsvärda defekter (i mening väldigt onödigt att information om problem inte är vad kunder gjorts medvetna om för evigheter sedan särskilt som de tycks tämligen enkla att identifiera d.v.s. troligt kan ha missbrukats ganska länge för en del) möjligen i sig vad som motiverar en liten komplettering till:



Men hur mycket bättre hade en sådan komplettering varit om den för Cisco hade inkluderat följande nyhet jag fel-mindes som Cisco:



Den typen av information som tar något att passera i min och säkert mångas bild Oracle nedanför vad man sorterar som helt seriöst i säkerhet. Spekulativt (och jag har aldrig försökt skatta detta för något någonsin) kan sådana problem i ett specialistområde som säkerhet kanske indikera jämförbara problematik i andra när som här inte otroligt indikerande problem i kultur hos medarbetarna.


Om Oracle nu inte skämtade med sina kunder så att dom ska bli glada och inte ska kännas överdrivet tråkiga när deras säljare ringer. Jag kan tänka mig att det är ett skämt. Det känns som ett skämt.


Det här var också ganska komiskt:



Mer allmänt i mening än juridiskt tydliggjort i Wiktionary:


"A fraud or swindle; an illegal scheme for profit.
They had quite a racket devised to relieve customers of their money."


Från: Racket | Wiktionary


Jag kan verkligen inte bedöma något alls relaterat Oracle rörande strategi intäkter men rent allmänt rörande större IT-företag har jag ibland genom åren fått en känsla av att de försökt svindla sina kunder. Eller åtminstone kortsiktigt utnyttjat deras okunskap för ökad försäljning ex. genom att sälja dem en lösning byggd från sämre kunskap till p.s.s. sämre prestation per krona kostnad.


Jämfört med dom större IT-företagens clown känns Cisco tråkig. Men vi har i alla fall en del blandade utmaningar bland Cisco-produkterna från sista månaderna (alla väldigt tråkiga utan något av Oracles stand-up-comedy):



IP-spoofing gör särskilt konto med lösenord funktionellt (eller något liknande till att bedömt betrodd: kanske inte ens det) och därefter kan själva OS-förändras genom att ladda upp någon form av fil (eller något liknande får jag för mig att jag läste för ett antal månader sedan).


Jag vet inte om det körs routrar med Linux i och runt det kinesiska internet i censur-skärningen? Jag hade löst för mig att läst något pekande ditåt nyligen men hittade just ingenting när jag sökte runt på internet nu. Hela området att identifiera plattformar implicit är ju minst sagt utmanande även när omedelbara enkla svar mycket bredare ges och i komplexitet långt utanför vad jag själv någonsin har upplevt mig kunnat något alls om förutom färdigt stöd i diverse applikationer för grov kontroll av host eller nät. Syn-ack och allt annat.


Hur som helst tycks en lätt komisk nersida av censuren finnas i begränsning på förutsättningarna för analys av publikt tillgängligt data på nätet:


" have a problem when reading the book Mining the Social Web because I live in China and we can't access Twitter due to government internet filtering.

I got stuck when testing this example in chapter 1-3:

[...]

It stops here.

I tried a Twitter API proxy, but still couldn't get the data using the Twitter Api."

Från: Use Twitter API in China | Stachoverflow.com

Berkeley DB i Perl

2013-05-31

Väldigt nöjd med hur Berkeley DB när byggd fungerat via DB FILE i Perl. En verklig välsignelse att inte behöva sitta och vänta för varje debug-körning flera minuter och indirekt p.g.a. ibland skjutande på integration av delar.


Vad som förvånande och oroar mig lätt var att bygga DB-filen för inte mer än cirka 350 - 450 MB common sense jag lät den referera på enklaste möjliga sätt som sträng utifrån första CSV-fältet (och sätter resp. struktur korrekt under körning första gången efterfrågad) tog flera timmar. Överdrivet duktig på att frysa via file access övriga processer att komma åt aktuella partitioner och föga påverkad av nice-level på det.


Det oroande är att jag vill ha samma lösning för allt sådant här där den största datastrukturen är för similarity-operationer. Där är det även för få entiteter efterfrågade tydligt långsamt att göra operationer så datarepresentation av färdig-beräknade värden är mycket trevligt oavsett situation. Samtidigt tror jag att den totala mängden färdigberäknade värden ligger på över 100 GB. Lösningen har redan idag en handbyggd lösning som läser en in uppdelade "mindre" filer och vid behov enligt konfiguration också avlägsnar dem hur minnet för att hindra hela datorn att kräva kallstart.


Egentligen tycker jag att det är underligt att den behöver så pass enorm tid för att bygga databas-filerna. Jag spekulerar att diverse databas-optimeringar relativt anrop hanteras jag egentligen saknar behov av och inte brytt mig om att notera.


Det blir gissar jag nödvändigt att sätta något meta ovanpå Berkeley DB i sig för similarity om det alls ska klara att ta sig igenom similarity datat på mindre tid än normala boot-perioder på några veckor. Uppdelat per första tre bokstäver (varande minsta orden jag accepterad utanför den semantiska parsern d.v.s. avseende koncept i Blue light eller common sense) bör kanske ge rimligt stora filer. Eller förhoppningsvis over-kill jag inte behöver göra (varande något jag önskade slippa med Berkeley DB för att slippa lära mig något färdigt och när det fungerar sunkigt skriva det själv) hasha begreppen ovanpå och reducera till mindre underrum - ett par fil med koncept (krävs det är man ju i princip upplever jag där man lika gärna kan koda det hela själv eller använda den befintliga similarity-cashe-lösningen).


Ett mer generellt tänk jag med mer faktisk erfarenhet i LDAP och X.500 än i SQL (jag kan oerhört lite SQL) är att låta naming motsvara hur vi adresserar koncepten där ett mellan-lager kan hantera vad som är aspekter av koncept resp. är ett koncept adresserat strukturerat enligt en ordning. Men praktiskt tror jag väldigt opraktiskt med mindre än att 99.99% av allt är fryst.


Rörande det licens-tekniska ska noteras att man åtminstone utanför debug-användning troligt bäst licenser kommersiellt från Oracle.