ntity

(entity@ran ~): uname -a
Darwin ran.dnz.se 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 i386
(entity@ran ~): man -k xml
Pod::Perldoc::ToXml(3pm) - let Perldoc render Pod as XML
dom(n)                   - Create an in-memory DOM tree from XML
hdxml2manxml(1)          - HeaderDoc XML to MPGL translator
libxml(3)                - library used to parse XML files
libxslt(3)               - library used to do XSL transformations on XML documents
tclxml(n), ::xml::parser(n) - XML parser support for Tcl
tnc(n)                   - tnc is an expat parser object extension, that validates the XML stream against the document DTD while parsing
xml2-config(1), xml-config(1) - script to get information about the installed version of GNOME-XML
xml2man(1)               - MPGL to mdoc (man page) translator
xmlcatalog(1)            - Command line tool to parse and manipulate XML or SGML catalog files
xmllint(1)               - command line XML tool
(entity@ran ~):

En lätt lösning vore ju exempelvis att skriva ett kort TCL script som loopar genom din XML fil, men om det är en spec XML fil så behöver du ju inte använda något som "förstår" XML, en onliner med grep & sed löser det snabbt..

Kan inte annat än hålla med, att han dessutom verkar skriva artikeln mest tack vare ilska att ingen ville läsa det han bloggade gör ju inte saken bättre..

Att man dessutom nu måste betala 29kr/månaden för aftonbladet+ för att läsa "Alex Schulman listar de fem skönaste svenskarna – varje vecka" lär ju inte ge honom mer läsare..

Förutsatt att inget nu har ändrats sedan jag senast jobbade med att utbilda/hjälpa en del av de som felsöker telefonin så är kompensationen beroende på hur länge som du är utan telefonen, dock så brukar även samtal krediteras med samtals pott eller genom att de stryks från räkningen, vad det blir beror på vem som gör det och vad du har för abbonemang (samtals pott på ett fast-pris abb är ju lite meningslöst).

Vad det gäller felanmälan i sig, så ja, de har rätt när det säger "Alla felanmälningar tar tre arbetsdagar", då avtalet du har som privatperson är felavhjälpning inom 3 arbetsdagar, det kan ju självklart gå snabbare, men att lova något sådant vore mest bara korkat av supportteknikern.

Vad det gäller felet så har jag en god uppfattning om hur det har uppstått, grannen som du blivigt korskopplad med beställde bredband (inte säkert från telia) och teknikern som åkte ut för att koppla in DSLAMen på deras koppar lina blandade ihop ledningarna..

Om man någonsinn sett mängden av kablar och hur tight de är dragna ibland så förstår man att det händer

Koppla ur airporten, vänta 30 min, koppla in TC, jag antar att du inte väntat på att DHCP-leaset skall gå ut?

Du kan avbryta registrerings frågan och sedan göra inställnignen i Mails inställnignar.

Jag använder Default Apps (http://www.rubicode.com/Software/RCDefaultApp/) där kan du ställa in för en massa andra format med, men framförallt slå av att något öppnas överhuvud taget.

Dock börjar DA bli rätt gammalt, jag kör Tiger och det funkar utmärkt, men om det fungerar på leopard vet jag inte.

Det jag försöker förklara är att det inte alls är konstigt, enligt ps hade du två processer som hade uninteruptable wait som status, de processerna ligger på CPUn utan att göra något i väntan på en operation som gör att processen inte går att deschedula, vanligtvis orsakas det av IO block, men ps i OS X ger inte mer finfördelad info än "U", därför ser du högt load värde men låg CPU belastning..

Eftersom din Macbook har 2 cores, så kommer då alla andra processer att ställas i kö som vill in på CPUn, och du hade någon eller några som ville in (state "R") som då gör att kön växer och du får en högre load värde..

Om inte loaden sjunker efter du tagit bort proccesserna som blockerade CPUn så är det andra som har tagit över och blockerar den, du får leta vidare med ps helt enkelt, det kan även vara så att de proccesserna har blockerat CPUn så länge att du nu byggt upp en stor kö med processer som vill in, då kommer det ta länge för load värdet att gå ner..

Att hitta felet kommer att ta tid, eftersom du måste kolla med ps vad som är fel just då, ändra, kolla igen, ändra kolla igen osv alternativt prioritera om processer för att de skall få tillgång till CPUn fortare om det krävs.

Men egentligen är inte en load på 1-2 ett fel, det betyder som sagt bara att det funnits processer i kön hela tiden, om du inte störs av det (annat än att värder är annat än normalt) så spelar det ingen roll, om den börjar trava upp i 20-30 skulle jag oroa mig, då det kommer att leda till att datorn känns seg eftersom det kan handla om 1-2 sekunder i väntan på CPU tid vilket kommer att märkas kan jag lova

Den kommer inte sjunka direkt, load värdena är medeltal på 1, 5 & 15 minuter.. Dock spelar inte load värdet speciellt mycket roll om det inte börjar bli så högt att du upplever att maskinen blir slö pga att schedulerkön är så lång att processerna måste vänta väldigt länge för att få sin CPU slot..

Det enda som det säger är att det varit X processer i scheduler kön senast 1, 5 och 15 minuter, så ett värde över 1 innebär bara att den aldrig varit tom..

Australien är ett U-land när det kommer till internet av många anledningar, de ligger lite avigt till ja, men det är (eller var iaf tidigare) billigare att köra trafiken över sjökablarna i stilla havet och sedan peera i Amerikanska IXar än att göra det lokalt inom landet pga reglering från den Australiensiska staten..

Enligt ditt ps urklipp är det antingen Safari eller MenuCalendarClock som strular, de är de två som ligger med uninteruptable status, vilket driver upp din scheduler kö, dvs load värdet.

Så antingen testar du stänga av Safari då det händer, eller slår av MenuCalendarClock och kör ett tag, bara testa dig fram, alla andra processer ligger i sleep eller annan wait status, och endast någon process ville in på procssorn..

Säker på att processerna försvinner även om du dödar programmet?

Det är vad som händer idagsläget egentligen med FPS spel, alla har sin egen uppfattning om vem som är var etc, och sedan bestämmer servern som alla är anslutan till vem som har rätt. Därav kan det se ut som om du skjuter ngn som sedan vips är 20 meter bort då delayen varierar..

Men det som jag ville framföra var att det är inte så enkelt som de får det att låta, om de verkligen har löst probelmen som de säger så kommer de bli stort, men jag är som sagt skeptisk..

Det enda som de talar om i presentationen är delay i video codecen, vilken dom säger har fått ner till 1ms, även om det är sant så enda tillfället de nämner de problem med delay som jag talar om är i början av del 2 av presentaionen då de tar frågor, och säger att de inte har någon lösning på problemet eftersom det är ljusetshastighet som är gränsen.

Detta är samma problem som Citrix, RDP utvecklare och resten har brottats med sedan urminnes tider, att köra en LAN appllikation över WAN, det funkar utmärkt över LAN, som deras demo, men WAN är något helt annat.

Med tanke på att detta problem är något som vi får förklara för kunder som inte förstår skillnaden på LAN & WAN allt för ofta på jobbet så vore det underbart om de hade löst det, jag jag tror dock inte det..

Jag erkänner även att jag inte är någon videokompressions expert, men grundproblemet är egentligen delay, villket som sagt är ett fysiskproblem med ljusets hastighet etc..

För att stödja några tusen spelande så behöves det rätt mycket servrar, och dessa blir svåra att placera så nära kunderna som det kommer att krävas, framförallt eftersom delayen nu är flyttat från agerande till händelse (som i dagens nät FPS) till öga - hand kordinationen som är mycket med känslig för sådant (eftersom du skickar ett komando med kontrollern, som måste till servern för att renderas, och sedan komma tillbaka över nätet igen.. )

Det vore väldigt coolt om det fungerade som de säger, jag får mest bara känslan av att de inte berättar hela historian helt enkelt, vilket vi har sett företag tidigare göra genom att lova runt och hålla tunt

En bra summering på varför jag inte tror på detta alls finns här:

http://www.eurogamer.net/articles/gdc-why-onlive-cant-possibly-work-article

Men grundproblemet är delay, vilket är en fysikalisk begränsning och att få ut utrustning så nära kunderna att detta blir användbart för de sakerna som de lovar (FPS spel) kommer bli så dyrt att de måste bli partners med varenda ISP som finns..

Men det är en bra ide, även om man kan spela en del spel över RDP redan idag utan större problem om man bara är villig att tumma på bildkvaliten.

i date så är %W veckans nummer i array format, dvs 0-53, det som du letar efter är %V som är "vanligt" format, 01-54

Etherpad.com är exakt det som du letar efter, har även stöd för revisioner och annat smidigt.