LDA och LSA med Noise-Kohonen: Samt buffer-overflow-outing Ubuntu's CM för 32- vs 64-bitars kompilering

Efter att det blev av att betrakta närmare PCA - Kohonen jämförelsen - att se Kohonen som en mot en stream men i övrigt kanske onödigt tidskrävande variant av PCA om man egentligen vill göra det - fick jag min anpassning av Kohonen (som jag alltid gör linjär - endimensionell, och numera med 300 double per tillstånd längs linjen - att göra intressantare något som otvetydigt kan konvergera och normalt gör så mot LDA resp. mindre intressant p.s.s. som jag tycker PSA kopplingen är det LSA).

Intressantare och antar jag trivialare för något som arbetar fel kring sådant här. Och med fel menar jag att tänka sig att man i metodik börjar med att sitta och härleda något runt matematiska relationer som när implementerade är triviala, snarare än att börja med att för enkla ekvationer testa igenom alla uppenbara varianter av dem som inte gör beräkningarna relevant mer komplexa. Så slipper man fundera över varför en av de mest effektiva composition operatorerna för semantiska vektorer ej mer beräknings-komplex än egentligen addition och multiplikation tillsammans ej berörs i publicerat om det nu inte är därför att p.s.s. sätt varför den blir blandningen av linjärt och icke-linjärt så lär den vara direkt smärtsamt svår att bevisa samband för eller rörande icke-bevisad konvergens referera till alla tusen artiklar refererande detta för Kohonen allmänt (för jämförelse snarare än just relevant composition oftast) är att jag ändrat default formen för min tidigare Kohonen-anpassning.

I princip för exempel betraktande min 300-WW variant d.v.s. ord vektorerna vilka är cirka 300 000 st (medan 300-CC och 300-FF över flergram är ett antal miljoner) för ord i indata och tänkande oss att vi tränar något där vi önskar antingen konvergens för tillstånd mot tematiska cluster eller POS. För de senare är min erfarenhet för mina 300-WW (minns ej hur det var i mina 400 stokastiska LSA vektorer de gjordes av) att få konvergens mot POS är en fråga om förhållandet mellan L1 och L2 (med 300-WW dim. reducerade via min Kohonen från 400 dim LSA i sista steget klara görande en kvadrat på varje sim värde mot resp. tillstånd och därefter L2-normerande dem, och ej betraktande normal skew för allt neuralt eller gradient som vad jag behöver hantera saknande annat än undantagsvis negativa värden med rymden efter kvadrat ungefär med medelvärde SIM på 0.5, konkret görande just kvadrat som jag senare fick gå tillbaka att verifiera eftersom det slog mig att kvadrat istället för X * abs (X) kanske inte är helt bra för värden fördelade möjligt [-1,1]) utnyttjar jag noise.

Se det så här. Clustrande eller dimensions-reducerande med Kohonen accepterar vi givet med problemet en ökad mängd smoothing / inexakthet eller hur vi vill se det. Vi får en centralitet utryckande ex. ett ämne allmänt potentiellt istället för en mängd enskilda vektorer. Lite som att se det som att vi skär en mängd decimaler. Med mina 300-vektorer gjorda Kohonen är varje dimension meningsfull att betrakta för människa. Och för något där som också var en vinnare (emedan jag för 300 dimensionerna färdiga ej hanterar vinnare annorlunda - bara likheten mellan 400 tillstånd concept och 400 tillstånd utnyttjas) inser vi att det samlade similarity värdet kan ta en försvarlig mängd slumpmässighet upp eller ner i relativ mening mot det absoluta värdet (så mycket som 10% gör relevant skillnad för vem som vinner bara för en mindre andel när vi är nära i tid - säg sista 20% av tiden d.v.s. för 300-WW cirka 2 veckor men absolut att det går att göra snabbare men jag hade 10 - 20 liknande processer som gick).

Men det är ej noise på sim jag arbetat med utan noise på hur tillståndsvektorn flyttas. Men jag vill gärna se detta jämförbart. Vi har ett utrymme runt resp. troligt korrekt tilldelad vektor som normalt oftast också är en korrekt tilldelning. Genom att addera in noise som slumpmässigt hamnar någonstans i detta utrymme täcker vi också in detta.

Säg att jag utnyttjat detta när jag gjorde mina 300-WW. Jag har cirka 300 - 400 000 400-dimensionella vektorer in och gör ungefär lika många 300-WW. Varje ord (samt en hel del URL:er också för den delen samt säg 50 - 100 000 flergram faktiskt skapat med bindestreck då jag tyckte det var lika bra praktiska skapande topics samt härledande konstanter för composition som jag trodde ev. behövdes) som finns i denna värd är en vektor så vad skulle värdet vara? Värdet är att blandningar av ord uttryckande ex. en nyhet eller ett ämne blir bättre. Det existerar en oerhörd mängd vektorer som ej är existerande ord som kommer förekomma praktiskt.

Två idéer förklarande värdet (lämnande att hindra överträning vilket ej varit en fråga för mig förrän nyligen) jag reflekterat men ej metod-defekt begått misstaget att sitta och matematisera är att:

1. För 300-WW kan vi tänka oss att ett cluster väsentligt kortare än 300 dimensioner - säg 30 - 60 eller mindre - utnyttjar i huvudsak 1 - 10 st. 300-dimensioner styrande ett tema. D.v.s. variationer på lågt värderade dimensioner kan existera. Kanske är dessa uttryckande en hel del likhet för ett ej helt litet antal i praktiken påverkande en del ej rörande mängden vinnare men när vi ställer den färdiga dimensionen relativt alla vektorer som i verkligheten kommer in inkluderande också kombinationer av många ord. Med noise kommer dessa i absolutvärde små dimensioner ej inverka om noise är ej helt litet jämfört med säg för varje vektor minsta värde.

2. Enligt som diskuterat tidigare att en stor yta / sträcka ut från de flesta sim-värden finns också samma dimension oavsett om just varje värde existerar för ett ord gäller att höga värden snarare är sällsynta exempel på vektorer som kan förekomma praktiskt vilka också är ord.

Om jag adderar noise för en position på vektorn i Perl med:

( rand ( 0 ) - rand ( 0 ) )

Inser man att Ubuntu's configuration management igen är helt defunct och rörande ett ämne (separera 32-bitar och 64-bitar kompilering) som till sin natur pratar buffer overflow nära nog var helst. Men praktiskt är ungefär för mig den yttersta gränsen om tränings-konstant är låg och vi är nära klara som kan accepteras (64-bitars Linux - Perl från Ubuntu apt-get utan tvivel då definition av rand är upp till argument som största värde kompilerat felaktigt: Kontrollerande Perl manual har de noterat risken här för rand men har troligt fattat det hela delvis felaktigt. Säkerhetsriskerna är dock primärt i mängd ej lokaliserat Perl då det demonstrerar att Ubuntu CM är defunct bortom all rimlighet om ansträngande sig ens litet och begripande något lite i grunderna i minne och vad det har att göra med kompilering: Jag menar varför inte kompilera allt 32-bitar och därefter kompilera om allt 64-bitar som ej gick att starta på en 64-bitars Linux? Jag hade ej gjort så normalt även om jag kanske ej ids kompilera om eller ladda ner rätt Perl på debug-datorn men är du dum i huvudet, okunnig gör du kanske så eller om mot all förmodan ej aktuellt Ubuntu är något Ubuntish annnat).

Men oavsett 0 som argument är formen för noise det jag använder. För att fånga tänkbart värde 2. i mitt resonemang förklarande värde från experiment utnyttjar jag varje position för indata-vektorn värde som övre-gräns. Vidare utnyttjar jag det minsta värdet över hela vektorn. Samt i flera varianter kvadraten av varje absolut-värde. Ett polynom antar jag att en matematiker skulle uppleva att det blir men praktiskt snarare tre olika lösningar som söker addera tre olika värden som tänkbart har betydelse.

Praktiskt resultat i särklass tydligast är:

• Från träning cirka 30 - 50 000 ord fördelade 60 dimensioner.
• Gäller nära klart att för höga similarity värden mot resp. tillstånd för alla 300 - 350 000 ord som har vektorer.
• Att oavsett om resp. sådant ord är vinnare under träningen eller ens existerande bland träningsdatat är det vad man upplevt naturligt hör dit om tilldelad vinnare för tillståndet beräknande för alla ord. Samma fenomen märks när vi tilldelar värdet sim oavsett vinnare eller inte men cirka 0.05 - 0.10 i off-set similarity ovanför att vi ser några underliga (för mig typiskt off-set html-taggar, forum-talspråk, nummer och liknade vilka ej förekom alls i träningen).

Medan frågan om avvägning bias / förmåga att inkludera korrekt / antal felaktigt tilldelade först börjar bli något som existerar som fråga nedanför (säg riktigare alla dim. 0.35 +/- 0.05 - vid 0.40 finns inga för någon dimension jag sett) men tveklöst similarity av 0.35 - 0.40, med genomsnitt alla vinnare. Skillnaden är värde är enorm.

Men värdet är ej unikt för denna metod. Om jag tränat 50 000 st. lika mycket utan detta hade jag fått något jämförbart i ej felaktigt höga. Och också om överträning och andra ej helt olika problem relaterade ex. om ej Kohonen utan vanlig vektor-kvantifiering den negativa termen när felaktigt tilldelat under träningen är väsentligt svårare att hamna i för Kohonen hade vi dock (och jag har prövat just för detta exempel) haft brutala värde-reduktioner p.g.a. just sådant här d.v.s. en mängd (tiotusentals) ord-koncept som korrekt borde vara höga för en dimension som ligger lågt - och detta oavsett om körande Kohonen-anpassningen utan grannskap eller vektor-kvantifiering med cirka 20 - 30 000 av träningsdatat med cirka 10 000 tveklöst felaktiga.

Typ exempel på hur värdefulla metoder man praktiskt har nytta av ser ut: Snabba, ej adderande komplexitet kod och allt jämförbart. Men där värdet jag avser ej har med dom värdena att göra. Utan dessa värden är mer typiska kännetecken för vad som ger stora värden typiskt i övrigt.

I övrigt betraktande exempel variationer av Kohonen publicerande kännetecknas dessa av att författarna haft svårt för att Kohonen ej är vektor-kvantifering och försökt göra en variant av Kohonen som fungerar som vektor-kvantifiering. Delvis antagligen därför att de känner sig tvungna om publicerande något alls att behöva härleda diverse vilket de upplever svårt om ej klart från start som för vektor-kvantifiering.

Jag vill dock föreslå - oavsett att en del upplevt att de bevisat att det ej är så - att det går att bevisa att Kohonen kan konvergera. Nu är jag direkt värdelöst på hela området matematiska bevis och har egentligen ej varit i kulturen alls sedan teknisk fysik. Men jag fick för mig att jag gjorde det anpassande konceptet för något helt annat. I någon mening kan vi (kanske: vi använder troligen kanske och i någon mening fortsatt lite överallt) se Kohonen som Markov-processer. Vi vet ju också att ibland kan vi bevisa något om vi kan visa det för n resp. n + 1, eller något liknande. Vändande på tilldelnings-ordningen via Bayes sats (n kontra n+1), uttryckande det som Markov-process, och därefter visande konvergens för n och n + 1, och därefter räknande tillbaka visa Bayes-sats har vi förutom att ev. / något jag trodde att jag kanske gjorde då visat konvergensen har vi kod-logiken för vad jag gjorde anpassningen för. Svårt för mig givet tid att säga säkert eftersom jag vet att det som jag parametriserar för 300-WW/CC/FF att det alltid konvergerar. Jag lär ju ej sitta och göra samma sak för algoritmer där något praktiskt kan visa mig felaktig eftersom jag ej känner till några jag behöver där frågan är öppen teoretisk.

Hur som helst får vi samma utökade värde görande LDA med Kohonen-anpassningen med noise. Här gäller dock att man / jag tveklöst kommer få mycket större värde genom att generera noise följande statistiska distributioner från språket i nyheterna.

QED. Eller hur det ibland känns som något fint för läsarnas utveckling att visa vem som är the Big Dog (så kan andra med ibland framtränande osäker självbild se hur man korrigerar upp det). Och för att understryka det lite extra - och kanske för framtiden stimulera NSA eller liknande som tänkbara kunder systemet genom att peka på hur bonus-give-a-ways ser ut: Förutom att jag nu publicerat OpenSSL defekterna redan för år sedan - outing Ubuntu.

Noise, noise, noise. == Information, information, information. Även när perfekt slumpmässigt strikt lika med mer korrekt information samlad i resultatet. Här i alla fall.

PS. PSA får mig alltid att tänka på Nobelpriset (i Kemi tror jag). 1993 - 1994 kanske? Förkortningen är troligen lite fel dock. Vad vi ex. använder för att få fler exemplar av ett stycke DNA-information. Var och lyssnande på dem föreläsande om det i Uppsala minns jag.

Ubuntu: Nautilus - Process underligheter pekar på odefinierade tillstånd

Att nautilus hänger sig på min arbetsdator (som ligger några versioner bakåt på Ubuntu) är inte ovanligt men händer inte oftare än att jag föredrar den p.g.a. sämre klick-natur än default filhanteraren för LXDE.

Idag hände emellertid något udda. De sista operativsystem jag kunde djupt var Windows 2000 Server på en av de med den samtidiga Solaris cirka. Kan man mer om Linux djupare kanske det är mer förståligt men därmed inte självklart mindre varnande rörande processhanteringen (i kontext av verkligt high-security miljö: I övrigt ligger praktiskt problematik inte i magnituder i närheten av sådant här).

Av vana när den hängde sig beordrade jag dödande av fönster från menyn som söker göra det snällare och därför generellt är att föredra. Men är ej van jag typiskt väntar på innan intierade andra åtgärder: Hinner det eventuellt (vilket för vad jag bedömer hängt ej är normalt alls då Nautilus tycks sakna vettig "tidshantering" rörande när följande upp om något signalerats till det). Denna gång hinner dock fönstret dö innan jag ens börjat göra kill (jag börjar regelmässigt högst upp och går stegvis med uppföljning med ps ner till 9). Jag följer upp med ps när det ny försvunna fönstret är borta att inga Nautilus körs då om något på annan skärm körande att jag tagit över det istället. Inga Nautilus processer är igång.

Jag startar upp ett nytt Nautilus efter död från LXDE's meny-alternativ run. Ny Nautilus fungerar normalt på alla sätt.

Några minuter senare stänger jag ner lxterminal fönster. Den Nautilus som hade hängt sig hade jag startat upp från ett av dess lxterminal istället för run i menyn. När detta lxterminal dödas - mycket märkbart p.g.a. av all status- och feltext som kastas ut i terminalen när man startar denna väg - dör min nya Nautilus.

Ska vi spekulera om orsak är vad jag kan tänka mig att kärnan cachar nyligen dödade processer och om de kan svara reattachar dem till nya. Men om så eftersom processer kunde dö på detta sätt sker det på sådant sätt att status-värden för processen återanvänds ej korrekt och därmed troligt - möjligen vid sidan om hur processen kan dödas - ej följer säkerhetsmodell för processer. Icke dokumenterade - odefinierade - vägar för att påverka processen existerar.

Det är inte första gången jag träffat på liknande icke-definierade tillstånd rörande processhanteringen i Linux. Mitt intryck är att det är jämförbart med erfarenheten av Solaris och Windows (rörande Windows när man gjorde insats ordentligt för Windows 2000 Server initialt - inkl. adderande några komponenter egentligen utanför OS samt reducerande möjlighet att aktivera delar av parallella delar av den feta kärnan vi möjligen kan referera till som "alternativa" OS inkluderade i den feta kärnan - var processhantering liksom mycket i säkerhet välfungerande medan min erfarenhet från några år bakåt nu av något Windows - ej server säkert - som kom med min laptop att dess säkerhetshantering var i mycket defunct och ej på sådant sätt att det underlättade användning: Tvärtom snarare).

Så i summering: Oavsett hur en process startas i Linux är det tänkbart att andra processer - ev. med krav att de startades av samma användare - kan definiera annars ej existerande kommunikationsvägar och möjligheter för den. D.v.s. i värsta fall ärvande rättigheter som den tidigare processen hade om de åtminstone refererar till samma fil (utan djupa kunskaper nog i Linux men från mitt intryck användande Linux definieras processens identitet från vilken fil de startats via som direkt referens d.v.s. snarare än från mjuka- och ev. hårda-fil-referenser till terminerad filnod).

Rörande korrigering av detta anar jag att en planering än mer långtgående optimering av min Linux (bl.a. planerar jag att koda om dess hantering av CPU:er för hur den lägger ut processer vilken är direkt dum utnyttjande tillgänglig processkraft brutalt dålig) kan tänkas korrigera detta. Erfarenhet från tidigare optimering jag gjort ger mig en känsla av att detta kan sortera till diverse jag råkat på i Linux ev. från början tänkt snabba upp något men som praktiskt i en stressad miljö bara orsakar problem stabilitet när pressande minne och/eller konkret ger sämre prestanda (re-attachar man processen här tror jag ex. inte för ett ögonblick att det snabbar upp något alls: Och om någon prestanda förändring kommer från det är min tro utan närmare kontroll att det bara slöar ner genom att gå utanför normalt samt riskerande diverse fel som kastas upp till kärnan att behöva hantera för att sedan börja om - Spekulativt hade jag kört min Ubuntu här "pressad" i CPU och minne under långkörning på många veckor så hade kärnan ej klarat att göra re-attach utan ev. givit flera sekunders fördröjning medan den prövar N antal gånger innan börjande om).

Jag inser att min referens inom parentes kan ge intryck av att jag kan saker om Linux. Det är emellertid falskt. Jag ser det som ett misslyckande - ett misslyckande för konceptet OS jag görande saker ovanför ej ska behöva bry mig i: Ett misslyckande för Linux - varje gång jag behöver lära något om Linux. Och ex. optimerande lär jag som jag gör det i alla fall inte ett jutta mer än jag behöver. Och pedagogiken jag använder är då inte sittande och läsa något allmänt om OS utan identifiera motsvarnade filer med logik och om jag inser logiken för vad de gör samt att det troligt är vad som är ineffektivt letande rätt på en vedertaget snabb algoritm som jag kodar in. Man lär sig verkligen inget generellt eller övergripande om Linux den vägen. Och faktiskt lär man sig ingenting nytt alls om Linux mer än vilken kod-del i filnamn - om man kommer ihåg det senare eller faktiskt inte missar att dokumentera förändringen man gör - som hanterar det man förändrat.

På den positiva sidan rörande Linux och förändringar gäller trots att det i all rimlighet inte ska vara möjligt - kan man tycka så här rent allmänt - att undvika omstart kring diverse förändringar man gör tycker man djupt. Men Linux (eller i all fall Ubuntu) är anmärkningsvärt kompetent i att klara sådant. Besläktat helt säkert men imponerande i så mycket mer är hur smidigt uppdateringar oavsett berörande program eller OS fungerar. Det är väl den tunna kärnan och allt i övrigt utspritt på enskilda komponenter som underlättar kombinerat med en idag uppenbart ruskigt fin dokumentering (eller auto-detektion) av hur olika delar beror av varandra. Möjligheter jag spekulerar hör till det mest möjliggörande för att göra det görligt för allt fler att använda Linux.

Skulle jag någonsin behöva driftsätta Linux som plattform för något liknande ett cloud hör vad jag såg här för Nautilis plus ett fåtal (två tror jag) andra småsaker jag råkat på under Ubuntu åren till vad jag skulle följa upp. Dels för att verifiera att det ej förstår säkerhetsmodell. Vidare om ej så verifiera - troligen koda om - faktiskt är meningsfullt förbättrande rörande prestanda snarare än att i sannolikhet X tidskostnad snarare ge tidsförluster över längre tid.

Sedan självklart (för mig) gäller att trots att arbetsmiljö numera aldrig får ansluta till nätet är det tänkbart på att vad vi såg här kan vara en rest-effekt av överdrivet sofistikerade modifikationer gjorda av över-drivet kunniga angripare. Visar det sig fallet är tänkbart det korrekta att tänka säkerhetsmodell utifrån att se till att kostnad föreligger för sådant. Oavsett om nu nätverkskostnad, CPU, minne m.m. som helt enkelt tar tid om övrigt falerar - eller implementerande säg en management kostnad hos ev. identifierad ansvarig organisation görande ansvariga personer synliga kanske som icke-rättrogna när det gäller kommunistpartiets koncept (snarare något annat faktiskt men funktionellt exempel: Kanske något mer Bo-liknande - Minns ni Bo-kostnaden föranledd av att man satt och trodde sig smart lyssnande på vad jag skrev i personliga anteckningar på min dator indikerande falskt över mer än ett år närmare två honom som samarbetande med demokrati-organisationer - Kanske om ni tycks indikerade här att en lagom kostnad är att göra det känt bland Bo's polare i partiet och militären: Jag tror knappast dom gillar att förklaringen vad detta snarare än allt fabrikerat).

Längre tillbaka var det ej vad jag som riktigt aktuellt men lite för mycket problem runt säg 2007 och några år framåt förändrade det bit för bit och min erfarenhet praktiskt av förändrad metodik i hantering var att det närmast binärt skar allt av det mer märkbara problemen.

Viss rest förvisso - möjligen lika gärna att de var oskyldiga men exakthet i vad man vet kring allt går inte att sätta som kräv - men där just mycket sofistikerad och därmed också mer arbetskrävande. Ansvar för sin egen historik är dessutom menar jag en moralisk rimlighet att de tar. Alternativet är ju trots allt att de accepterar vad man gjort i kontakt med mig och betalar en rimlig ersättning (310 000 svenska kronor räknat på 3 * 1250 kr per timme) tydliggörande att det ej kommer upprepas i vilket fall man kanske rörande strö-problem (ej otroligt p.g.a. av angrepp och om så ej otroligt dem) kan räkna bort dem. Så verkligen vad man valt själv och med fullmedvetenhet om det givet att jag tydliggjort det här flera gånger genom åren och de är verifierade läsare.

Mer förslappad numera och mindre praktiskt engagerad gäller dock att jag mer än kanske rimligt faktiskt här om alls kommer verifiera att det om så är externt korrumperad processhantering. Dock det troligaste är något defunct naturligt i Linux. Att understryka givet omfattande problem bakåt att man potentiellt inför ev. problem är lika sur och otrevlig som man kom att bli från det tror jag hur som helst är korrekt att göra av och till. Nya rekryteringar, äldre folk som går vidare till annat m.m. gör det sunt att påminna så man slipper mer själv-organisatoriskt-destruktivt beteende drabbande mig. Säg 75% chans.

Ubuntu: Flytta processer resp. dedikera till fysiska CPU:er och / eller process core instanser

Frågan är sedan för mig som inte roat mig med sådant här särskilt mycket förr om en kostnad finns för att kasta ut pågående processer från några av CPU:erna när en diskret-process-grupp behöver gå igång jag hellre vill ska få närmare beräkningsbar CPU-tid så att de kan avlyssna vettigt (ex. hindrande att datum- och tids-relaterat data kan förskjuta vår verklighet bakåt trots att vi samplar nog därför att det tar längre än en timme, ett dygn eller vad nu vi samplar för diskret tidsperiod att stoppa in data.

• xmodulo.com/2013/10/run-program-process-specific-cpu-cores-linux.html

Ty övrig tid i min mer manliga resurs-begränsade värld där inte en massa kognitivt-förvekande CPU-cluster bara finns att koda dumt slöa efter behov roas man av sådant som att man faktiskt vill utnyttja dom CPU:er man har maximalt. Och utan att alls önska lära mig en milimeter OS-verklighet i onödan nere i Linux tänker jag att risk att det kostar att flytta en bunt process pågående finns?

Det är just sådant här Linux-kompetens-relaterat som får mig att börja drömma om att installera upp Windows 2000 Server. Det var ett fint OS. Krävde inte att man behövde bränna en CD-skiva vilket tog en evighet för mig att lösa då jag självklart innan saknade OS. Väldigt svårt faktiskt. Men lösbart om just hittar sina gamla Windows 2000 Server CD. Linux samhället upplever jag börjar bli förslappat tjockt-förätna av att Linux blivit mainstream: Riktig kompetens lösande problem utan att tunga användare som jag ska behöva engagera mig i OS-detaljer - en OS-subkulturs värsta misslyckande - blir allt mer scarce: Varför ska jag behöva vara så otrygg att Ubuntu-tyngden räcker för att bara lite på att sådant här sker utan tidskostnad? Tid kompetens från individer är ju en försvarlig kostnad i tung OS-användning.

Ett spännande projekt för Ubuntu-samhället vore att ta möjlighet att följa mina utmaningar här när jag av och till söker skapa värden för dem givande requirement data åt dem. Så ser man enkelt var större behov förbättringar finns med tillhörande kompetenta reflektioner såväl som motiverande råd jag säker tror kan bromsa Linux-samhällets förslappande rasande mot ett abstrakt Windows 95 koncept dagar som dessa när man hittar potentiellt tidsödande engagera sig i OS-detaljer defekt kernel djup.

Perfekt vore en liten som punktlista - eller vad som gör det kanske ännu bättre - som direkt framgår vad kostnaderna för sådant här är om dessa kostnader alls finns. Och hur man optimerat flyttar processer om bättre metod än den jag hittade bland topp fyra Google-sökning finns. Gör man commit på ett OS är det mest grundläggande just att garbage mer OS-roade personer ska ha löst ska gömmas: Jag görande mer abstrakt viktigare - för mig mer generellt eller här ganska brett för världen i förlängningen tror jag - ska ej behöva ödsla tid lära sig sådant här strunt: Vi ska inte behöva hamna där vi känner att vi behöver lära något.

Men jag tror på Linux-folket. Detta och alla liknande ännu ej upptäckta defekter är säkert lösa i nästa version. Lös våra - världens problem - utan att kräva att vi engagerar oss görande er livsuppgift ni mutat in i er OS-sekt. Tänkt på att Microsoft-sekten fortfarande lever...

Sunt att ha utvecklingsdatorn off-line

Pågående major-versions precis som för Warrior under själva konvergensen till version givet det den större andel av skarpt data nära core som den "riktigare" större Blue Light har jag sett som mycket sunt att ha off-line. Mycket svårt att ha en utvecklingsdator säker och ännu svårare som här där jag prövar för mig helt nya insatsvaror för enskilda funktion (ex. MediaWiki och Semantic MediaWiki) att ha säker.

Ett kortare avbrott för det för att installera på diverse Perl-moduler m.m. föranledde synkning med Google konto vilket jag gissar är relaterat till vad vi ser i bilden även om det också tänkbart kan förklaras med andra händelser runt utvecklingsdatorn (dock bara själva den intensiva nätverkslast som gick från utvecklingsdatorn under uppdateringarna hade gjort det problematiskt för data att tas ut via andra metoder allt för enkelt).

I bilden ser vi Google Chrome flikar från min bärbara dator som aldrig haft access till utvecklingsdator och kör någon billigare lite sämre Microsoft Windows version anpassad för privat-användning snarare än kontor. Ordningen som fönstren öppnats (hittade under morgonen när jag vaknade) är till endast http://localhost/mediawiki-1.21.1/index.php/Main_Page före http://localhost/mediawiki-1.21.1/index.php?title=Category:INTERNAL_DEVELOPMENT&action=edit&redlink=1. Bookmark finns gjord lokalt på utvecklingsdator för den senare men ej den första (spekulativt synkroniserad där jag kommer kontrollera inställningarna för min open source version av Google Chrome - som heter något annat än Chrome - medan Google Chrome jag hade innan avinstallerade sig själv efter uppmuntrats till det från för det gjord funktionalitet).

Det kommer givetvis aldrig inträffa att jag för en nöjes-dator med Microsoft Windows i mitt nätverk betraktar den som annat än Internet. och det kommer ej heller inträffa att jag hanterar nätarkitektur-frågor rörande sådant här annat än genom att fysiskt bryta nät-access.

Synkroniserings-frågan med Google kan möjligen förutom att förklara tydliggörande mål för angrepp mycket möjligt vara självförklarande utan annan än maskinella aktörer. Jag har sett beteende rörande det tidigare. Det tycks troligt att jag tar bort dom möjligheterna för utvecklingsdatorn i samband med nästa uppdatering av saker och ting (förövrigt har den en del andra Chrome problem relaterade att jag bytte ut Chrome mot dess instansiering som open source projekt vilket gjort att en del inställningar Chrome gorde ej gick bort och ej heller sattes och förändrades av den senares inställningar medan jag ej haft intresse eller lust att ändra dem manuellt ex. inkluderande vilken webbläsare som är default för filtyper som open source versionen menar att den är default för men Ubuntu fortsatt tror är Google Chrome trots att den är avinstallerad).