PHPdude
-
Innlegg
988 -
Ble med
-
Besøkte siden sist
Innholdstype
Profiler
Forum
Hendelser
Blogger
Om forumet
Innlegg skrevet av PHPdude
-
-
"odd" og "even" er bare et alias for "2n+1" og "2n", som igjen kan leses som "hvert andre element i rekken + 1" og "hvert andre element i rekken", hvor det første elementet i rekken har nummeret 1.
":nth-child"-selectoren er langt mer fleksibel enn odd/even, og alle mulige tilsvarende verdier kan oppgis for å markere/velge elementer basert på nummerering.
Spesifikasjonen inneholder en god del eksempler.
Måtte bare presisere litt
-
Det finnes ingen måte å gjøre dette på automatisk, verken i CSS2 eller CSS3 såvidt meg bekjent.
CSS3 har funksjonalitet for akkurat dette.
Sjekk http://www.w3.org/TR/css3-selectors/ eller for å være mer nøyaktig: http://www.w3.org/TR/css3-selectors/#nth-child-pseudo
I praksis vil det si at man kunne gjort noe ala dette for å markere annenver rad forskjellig:
tr:nth-child(odd) { color:#ccc; } tr:nth-child(even) { color:#eee; } -
Hva er egentlig problemet her? Med mindre jeg har oversett noe trenger du bare å definere riktig tegnsett. Det er på ingen måte nødvendig å bruke HTML-entites for å vise æ (æ), ø (ø) og å (å), så lenge tegnsettet er satt riktig kan også sånne tegn brukes rett fram uten noe mer "dilldall".
Orker ikke noen forklaring på hva tegnsett er, du får heller søke litt.
Uansett så er det mange forskjellige tegnsett som kan benyttes og nettleseren klarer ikke og finne ut hvilken som er benyttet på din side helt av seg selv, så du må fortelle den det.
Dette gjøres ved å sende en HTTP Content-Type header sammen med websiden din, eller eventuelt "juksemåten" med å legge til en meta-tag ala <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> i <head>-delen.
Uansett bør du bruke en tekst-editor hvor du kan kontrollere tegnsettet, det som følger med Windows er ubrukelig, men f.eks Notepad++ duger - notepad-plus.sourceforge.net/
Kort sagt så sørger du for at tegnsettet blir definert som beskrevet overfor og filene faktisk er lagret med det tegnsettet du har definert.
Så lenge det er gjort riktig skal du ikke ha noe problem med at nettleseren bare viser tulletegn.
-
Hei,
Har registrert at Intel og AMD så smått har begynnt å komme med komponenter som tilbyr "maskinvare-akselerasjon" for virtualisering, lurer på om dagens løsninger gir såpass forbedringer at det bør vurderes også til maskiner hvor virtualisering kun er sekundært bruksområde?
Eller det hovedsakling sånn at "alle" nye prossessorer/plattformer inkluderer det viktigste ?
Noen gode råd hadde vært flott!
-
Enig med dabear, PHP er en glimrende template-motor i seg selv, med mindre man har spesielle behov er det ingen grunn til å dra inn et nytt system med en annen syntaks og dårligere ytelse enn ren PHP.
Man må bare være litt disiplinert og ikke putte inn all verdens PHP-kode i vilden sky selv om muligheten er der...
En løsning jeg er fan av er Zend_View, da får man det beste fra begge leirer: ytelse, syntaks og fleksibilitet som PHP, og verktøy for å forenkle genereringen av HTML-kode som i Smarty etc og diverse andre fordeler.
Kan brukes uavhengig av resten av Zend Framework.
-
At du i det hele tatt kan påstå noe sånt som at MS aldri kunne "gjøre om formatet" viser bare din egen uvitenhet og ignoranse.
Jeg har aldri sagt at ikke MS (og ISO og ECMA) kan gjøre om på formatet.
Skjønte du ikke hva jeg mente med "gjøre om formatet"? Du skrev: <quote>MS vil ikke senere kunne "gjøre det om" til et nytt proprietært format. Det er ikke slik ISO fungerer</quote>
Altså er det ikke snakk om en naturlig videreutvikling jeg sier at du har benektet, men en undergraving av åpenheten i formatet, altså noe ala en Embrace, extend and extinguish-operasjon. Det er noe vi har sett MS gjennomføre flere ganger tidligere, dette har lite med ECMA/ISO, bare om Microsoft sine forretnings-metoder og din påstand om at MS ikke ville kunne undergrave den åpenheten som måtte eksistere i OOXML, men det er ikke OOXML-spesifikt, EEE-taktikk kan de like gjerne bruke mot ODF, noe som kan vise seg å bli høyst aktuelt.
Hele svaret ditt er egentlig så fullt av misforståelser, over-forenkling, svada og ignoreringer at jeg like gjerne kunne sitert mitt opprinnelige innlegg som svar på ditt svar, men jeg vil vertfall oppklare de to gode bemerkningene du kommer med:
Hvor er dokumentasjonen på at de ikke bruker dette formatet selv?http://www.ecma-international.org/news/TC4...%20complete.htm
Kortversjonen er at alle endringer ECMA har gjort etter at Microsoft sendte inn formatet, er forskjeller mellom MS-OOXML og ECMA-OOXML.
Microsoft utviklet OOXML, de implementerte det i MS Office, så sendte de det til ECMA for godkjenning. Og etter at MS Office 2007 ble lansert har ikke Microsoft endret sin implementering.
Selv om du neppe fattet omfanget av det du skrev kan jeg jo bruke deg også som kilde:
Hvis du har fulgt litt med i debatten vil du se at de norske innsigelsene i stor grad er imøtekommetJa riktig, ECMA har gjort *endringer* i spesifikasjonen, Microsoft har *ikke* oppdatert sine egne implementeringer til å følge endringene.
I *tillegg* så er det sånn at MS Office benytter seg av diverse funksjonalitet som ikke er dokumentert i noen OOXML-spesifikasjon, dette dreier seg om diverse binærobjekter, makroer, DRM-mekanismer, ActiveX-serialisering, OLE-objekter og SharePoint metadata.
Det MS har sagt er at utviklingen er overlatt ISO og at de naturlig nok ikke kan gi noen garantier for all fremtid. Det kommer an på hva ISO/ECMA gjør med formatet. Det er stor forskjell på "ikke aktuelt" og "kan ikke garantere for all fremtid".Selvfølgelig har ikke MS avvist det for all fremtid, men i det øyeblikk MS Office 2007 ble sendt ut i markedet stengte i praksis MS av muligheten for å rette seg etter endringer, siden det bra sikkert ville skapt masse problemer for brukerne.
Det viktigste er nå dog motivasjonen, og MS har neppe noen som helst motivasjon for å rette seg etter endringene, her kan jeg henvise til min beskrivelse av MS sin strategi rundt åpne standarder, du siterte den ikke, men den ligger i slutten av det forrige innlegget mitt, viss du skulle ha oversett den...
Viss du mener at den beskrivelsen er helt på jordet kan vi like gjerne stoppe denne debatten øyeblikkelig, for da er det langt mer grunnleggende oppfatninger vi må diskutere før de "politiske" aspektene rundt "standarden OOXML".
Angående det du skriver om patenter og styring har jeg dette å si:
- Alt rundt OpenDocument Format er ikke perfekt.
- Begge formennene i ECMA sin "Technical Committee" for OOXML er ansatt i Microsoft.
http://www.ecma-international.org/memento/TC45.htm
- Les: http://www.noooxml.org/patents
Det er en velkjent teknikk å lese halve setninger og plukke ut enkeltdeler for å sverte den man er uenig med. Det er samtidig like uredelig og det blir ikke sant selv om du skriver det.Ikke "fordi jeg skriver det", men fordi fakta viser det. Er du uenig i det så får du heller presisere uriktighetene, jeg utelukker ikke upresise formuleringer.
Nå må du gjerne opplyse meg om hvilke deler av innlegget ditt jeg "halverte".
-
Angående OOXML: Jeg er, overraskende nok, ikke enig med deg. OOXML-spesifikasjonen vil bli overlatt ISO (om den blir godkjent som standard) og MS vil ikke senere kunne "gjøre det om" til et nytt proprietært format. Det er ikke slik ISO fungerer. Selv om vedlikeholdet av spesifikasjonen vil gå til ECMA skal alle endringer godkjennes i ISO og du kan banne på at de vil følge godt med.
Akkurat som de fleste OOXML-fans er du raskt ute for å påpeke at videreutvikling skal skje oss "uavhengige" ECMA, ok, viss vi nå for diskusjonens skyld tar ECMA sin uavheninghet for god fisk, så sitter vi allikevel igjen med et aldri så lite problem:
Microsoft har så godt som avvist at det blir aktuelt å gjøre endringer i MS Office sitt MS-OOXML format for å være kompatibel med endringer som ECMA/ISO gjør i OOXML, og det trengs ikke noe geni for å skjønne at MS Office sitt MS-OOXML format vil bli "defacto"-versjonen av "OOXML", selv om den ikke er kompatibel med en eventuell OOXML ISO-standard.
Det er klart MS ønsker å holde på sin markedsposisjon, noe annet ville vært rart. Jeg tror imidlertid de har skjønt at tiden for lukkede dokumentformater er over og at de har forstått at de ikke har noe valg.Ja og nei. Ja de har forstått at markedet ønsker seg bort fra det format-helvete som MS har presset frem i årevis nå, ja MS er et selskap som tjener fantasi-beløper på sin tilnærmede monopol-situasjon, men nei de har ikke forstått at de ikke har noe valg, derimot har de funnet fram til en perfekt mellomting, så de fortsatt kan kontrollere "lockin-faktoren" i MS Office sine formater og forsinke interoptabiliteten som ODF ville medført samtidig som de kan rope høyt om dette fantastiske ÅPNE formatet de skal sende til ISO-godkjenning (men som de ikke engang bruker selv) og fremstå som åpne oss de mange utvitende rundt i verden.
Det var jaggu tre fluer i en smekk det, ikke rart Ballmer har sånt et fett glis.
At du i det hele tatt kan påstå noe sånt som at MS aldri kunne "gjøre om formatet" viser bare din egen uvitenhet og ignoranse.
Embrace, extend and extinguish er en velkjent MS-strategi for nettopp å undergrave definerte standarder, og her snakker vi tilogmed om et format hvor MS selv er den eneste betydelige pådriveren - barnemat for EEE!
Denne artikkelen inneholder en del utdrag fra MS sin strategi rundt åpne standarder, se også min personlige "favoritt", denne interne e-posten fra Bill Gates himself. Se vedlegg.
Å tro at et sånt selskap er egnet til selv å utvikle et *åpent* format er i beste fall naivt.
-
Nøkkelen her er egentlig teori og erfaring, det er få snarveier på de områdene, men jeg vil anbefale deg å sette deg inn i et rammeverk som f.eks Zend FW. (primært MVC-delen) Ikke nødvendigvis for å bruke selve rammeverket (selv om jeg vil anbefale det også for større prosjekter), men for å se hvordan disse tingene løses av folk som har nok kunnskap til å velge og vrake mellom forskjellige løsninger og gjennom mange års erfaring har kommet fram til en "best practice"-metode for oppgaven.
-
Jeg håper tiden hvor enhvert selskap som får en glup ide og lager sitt eget format for å tvinge brukere til å bruke deres produkt ...
.. Og det er akkurat hva MS gjør med OOXML.
Det er ett åpent format slik jeg har forstått det, dersom det er for komplisert for at andre kan klare å implementere det, så er selvfølgelig det ett problem og kanskje årsaken til at det ikke ble ISO standard? Hva var årsaken til at det ikke ble ISO standard?
At den er unødvendig komplisert er en faktor ja, men langt langt fra den eneste eller største.
http://digi.no/php/art.php?id=395080
http://www.standard.no/pronorm-3/data/f/0/...00_comments.pdf
At ODF pr. idag ikke innholder alt MS kunne ønske seg kan MS kun skylde seg selv for. Vi har fått en ISO standard for dokumentbehandling som Office 2007 (or whatever) kan støtte i den grad det er mulig. De har såpass med ressurser at de får det nok til om de vil.Slik jeg forstod det inneholder ikke ODF alt kundene ønsker seg, tror ingen her bryr seg om hva MS måtte mene, men dersom aktuelle kunder ikke vil bruke ODF fordi det mangler elementer/funksjonalitet, så er det ett reelt problem for formatet.
http://blogs.sun.com/dancer/entry/dispelli...yths_around_odf
-
Hardware.no (ved Arsæll Benediktsson): Skal dere fremstille en rapport i et så betent tema som ODF vs. OOXML som "uavhengig" får dere i det minste beskrive hvorfor akkurat "The Burton Group" sin er mer troverdig enn andre rapporter på dette området som spretter opp ukentlig med veldig sprikende konklusjoner.
Angående innholdet i akkurat denne rapporten så henviser jeg til Ars Technica sin gjennomgang, og da ser ikke rapporten verken særlig seriøs eller uavhengig ut lenger
http://arstechnica.com/news.ars/post/20080...iso-abuses.html
-
Sniktitt da ;-)
-
Brukertester av KDE4 bør vel vente til 4.1, utviklerne understreker jo at KDE4.0 ikke er ment å erstatte 3.5 for vanlige brukere.
Kan gjerne få både i pose og sekk, men blir helt feil å vurdere KDE4 utifra 4.0, så er vel kanskje best og heller gå grundigere til verks når 4.1 osv. kommer?
-
Synes egentlig det er lite viktig å ha en artikkel om en RC versjon av en desktop utgitt på hw.no. Da kunne man like gjerne gitt ut artikler om andre like store/større prosjekter som oppgraderer versjonene sine. Det ville da selvfølgelig bli helt fullt av artikler under tema "Linux" på forsiden, noe som alle de andre som ikke bryr om GNU/Linux/Alternative programmer kanskje ikke kommer til å sette så mye pris på. Hw.no er jo fremdeles en nyhetsside for aktuelle nyheter, og jeg vil da argumentere at en ny desktop for *nix kanskje ikke er det mest vidt-spennende av ting som kunne blitt skrevet om.
Derimot hvis det hadde vært nyheter om for eksempel OS forandringer(Windows 7, Linux 2.7/8, Mac OS XI/etc.) eller hvis nevnte desktop i artikkelen faktisk hadde blitt sluppet som ferdig-versjon hadde det vært akseptabelt å ha dette på forsiden ettersom det da har mer betydning leserene.
Vil vertfall si at KDE4 er *vel* så viktig som en eventuell lansering av Linux 2.8 (Linus har ingen som helst planer om å forlate 2.6 enda), Linux-kjerna er så klart viktig den, men for "vanlige" folk er KDE4 veldig mye mer interessant siden destopmiljøet *er* brukeropplevelsen, i motsetning til kjerna som er usynlig.
Og det vi snakker om her er blant de aller aller største og mest ambisiøse lanseringene FOSS-verden har sett av et av verdens største programvare-prosjekter (bortimot fem millioner linjer kode).
Selv om KDE4.0 bare er den spede starten på KDE4-serien inneholder jo 4.0 vel så mye nyheter som på de tilsvarende områdene i XP -> Vista, har ingen oversikt her, men er bra sikker på at Vista fikk dekket både, beta, interne builds, RC'r (i flertall) osv osv.
Det skulle jo bare mangle at Vista får mer presse, men synes ikke at dekningen av KDE4 på noen måte har hvert overveldene.
Vi snakker jo om det som vil bli selve spydspissen for brukeropplevelse innen FOSS-baserte operativsystemer de neste årene.
PS: KDE4.0.0 ble nylig "tagged for release" og skal slippes den 11.
-
Med mindre du har noen mer spesielle behov ser ikke jeg ikke hvorfor du skal dra PHP inn i saken, det enkleste vil nok å være å stille inne webserveren, og siden du nevnte Linux så regner jeg med det er enn Apache-server og da kan du rett og slett opprette en .htaccess-fil hvor du putter følgende:
<FilesMatch "\.(pdf)$"> Header set Content-Disposition '"attachment; filename="downloaded.pdf"' </FilesMatch>
Da vil alle pdf-filer i den mappen (og undermapper) du opprettet .htaccess-filen bli sendt med Content-Disposition:attachment-headeren og vil "tvinge" nettleseren til å laste ned filen.
1. opprett en fil et sted på din egen maskin med navnet ".htaccess", skrevet nøyaktig sånn.
2. kopier koden min ovenfor inn i filen
3. kopier filen over til serveren via FTP eller hva du nå pleier å bruke.
Det tryggeste er nok å kopiere .htaccess-filen til den samme mappen som PDF-filene dine ligger i.
4. Sjekk om det fungerer.
-
-
Enig i alt annet du sa, men: acid2 validerer faktisk
HTML ja, men CSS nei.
http://jigsaw.w3.org/css-validator/validat...test.html%23top
-
Skummel å se halleluja-stemninger det plutselig ble, ville trodd historien burde lært en at alle tegn på bedre standard-støtte i MS-produkter må tas med mange klyper salt.
Acid-testen er dårlig egnet til å bedømme generell standard-støtte, den tester bare et veldig begrenset område. Et av de viktigste aspektene ved Acid-testen er at den inneholder ugyldig kode og ikke ville blitt godkjent av W3C-validatoren. Dette gjøres for å sjekke at nettleseren håndterer feilene korrekt og det gjør det noe betenkelig at det understrekes at "standard mode" er nødvendig for å passere testen, grunnen til den ugyldige koden er jo ikke for teste mer funksjonalitet, men fordi sånn ugyldig kode skal håndteres/ignoreres på en spesiell måte, noe annet ville vært å undergrave standardene og gjør vanskelig/umulig og lage gode fallback-prosedyrer for nettlesere som ikke har den brukte funksjonaliteten (sånn som IE)
Acid2-støtte i seg selv ville ikke vært særlig mye jobb for MS, som nevnt tester jo Acid2 bare et lite utvalg av funksjonaliteten og hittil har vi ikke noe som helt bevis på at IE8 ikke har tatt snarveien og implementert den helt nødvendig funksjonalitet for å passere testen, men ignorert annen og vel så viktig funksjonalitet.
Også veldig viktig å huske på at hittil er alt vi har sett et bilde og vi har ingen som helst beviser for at dette er noe som kommer til å bli en realitet med IE8, vi vet ikke engang *når* IE8 kommer til å komme, at MS sier "i løpet av 2008" er like troverdige som norske politikeres klimaløfter.
Realiteten er nok at IE8 bare vil bringe bagatell-forbedringer og at dette ikke er noe annet enn enda ett av MS sine PR-stunt hvor det loves gull og grønne skoger bare man kan vente *litt* lenger. Hadde MS hatt noe som helst interesse av et bedre WWW hadde de enten droppet IE helt, byttet ut IE sin renderings-motor med Gecko eller WebKit (noe de kunne gjort helt gratis) eller tatt ett skikkelig skippertak og fått på plass tilnærmet full støtte for CSS2.1, endel CSS3, XHTML, en skikkelig DOM-støtte pluss endel SVG og for å vise at de virkelig mener alvor burde de slengt med en del HTML5 og et dypt og ærlig løfte om ikke å stikke kjepper i hjulene for den kommende overgangen til HTML5/XHTML2 og Ecmascript4 (Javascript 2).
Utviklingskostnadene hadde neppe vært stort høyere enn beløpene markeds-avdelingen bruker til å dekke over all stolkastingen til Steve "I'm gonna fucking kill Google" Ballmer
Nå var jeg nok i overkant negativ her, men jeg synes det er noe IE har fortjent...
-
I alle dager da!? Du sa noe om at er det fint at all RAM brukes, selv på tross av dårligere generell ytelse, og jeg stilte deg et veldig konkret spørsmål:
? Sikker på at jeg ikke blir forvekslet med noen andre?
jeg bare supplimerte ditt innlegg.
Oups, legger meg paddeflat og trekker tilbake den aggressive tonen, dog står det meste av innholdet seg.
Men nok en gang, så du ikke kan glemme det:HVORFOR ikke BEGGE DELER!?
Hadde det var så greit så.... Blir vel som å spørre hvorfor noen ikke har laget det perfekte OS.
En kan ikke alltids få pose og sekk. Hva kunne ha skjedd om MS hadde droppet lansering av Vista, og heller satt alle konsentrasjonen til optimalisering, hva ville skjedd?
1. Kanskje færre funksjoner. (da noen kanskje suger RAM, og/eller at de rett og slett ikke har nok tid til å implementere flere)
2. Kanskje et par år ekstra ventettid. (imens så kanskje folk hadde suttet på en 2-3 GB ram som bare venter på å bli brukt, og man begynner å gå dritt lei av WinXP)
Vel, ikke vet jeg, men noen negative sider pleier det som regel å være.
Grunnen til at jeg skrev så aggressivt i stad var en tvilsom "hent-ut-det-som-passer-og-ignorer-resten"-kommentering av innlegget mitt, og du er ikke uskyldig der du heller.
Som jeg skrev så har konkurrentene klart å gi i både pose og sekk på det aktuelle området. Og det er ikke stort av funksjonalitet i Vista (bortsett fra DRM) som ikke finnes i min Ubuntu, men jeg kunne pekt på *veldig* mye funksjonalitet som mangler i Vista.
Så hvorfor ikke Windows også? Eller sagt på en annen måte: Hvorfor skal man ikke kunne forvente det samme fra Windows også?
For å vri om på ditt bilde: Hva hadde skjedd viss Microsoft istedenfor å utsette lansering for å "optimalisere" (fullstendig omskriving i Windows sitt tilfelle..) til man var på nivå med konkurrentene bare gjorde alt like riktig og bra og like fort som konkurrentene med en gang?
-
Regner med at du er enig i at det er ikke noe mål i seg selv å skulle bruke opp RAM, målet er å bruke mer RAM for å få bedre ytelse tilbake (oppstartstider i dette tilfellet).
Akkurat det med XP var ment som at det er mulig å ha tilsvarende korte oppstartistider der også, det var resten av innlegget som var interessant, glem gjerne det med XP.
Er like fint å "bruke opp" rammen op ekstra funksjoner og bedre design.
170kr for 2GB DDR2 ekstra er ikke å karakterisere som spesielt dyrt.
I alle dager da!? Du sa noe om at er det fint at all RAM brukes, selv på tross av dårligere generell ytelse, og jeg stilte deg et veldig konkret spørsmål:
HVORFOR ikke BEGGE DELER!?Og viss du virkelig ikke skjønte hva jeg mente i forrige innlegg om oppfylling av RAM bare for oppfyllingen sin skyld, så vil det altså si minnebruk man ikke får noe (som i ingenting) igjen for og som sagt så regner jeg virkelig med at du er enig i at sånn minne-bruk ikke er noe mål!
Egentlig kan man da ta den totale minnebruken til Vista (ekskludert cache) og deretter trekke fra minnemengden konkurrentene trenger for å utføre de samme funksjonene, ser man litt firkantet på tallet man da får vil det representere en sånn bortkastet minnebruk, og i Vista sitt tilfelle er dette tallet ekstremt høyt.
At RAM er ekstremt billig for tiden har ikke noe med saken å gjøre.
Men nok en gang, så du ikke kan glemme det:
HVORFOR ikke BEGGE DELER!? -
Konkurrentene klarer det, ja tilogmed XP klarer det
Hva mener du?
Viss du mener at xp faktisk bruker minnet, så er jo det feil, det er jo det jeg liker så godt med osx og vista, at man kan dobbelklikke uten at det vil si at hdd lyset skal lyse konstant noen sek, men at det bare spretter opp, akkurat som ie gjør rett etter oppstart i vista.
Regner med at du er enig i at det er ikke noe mål i seg selv å skulle bruke opp RAM, målet er å bruke mer RAM for å få bedre ytelse tilbake (oppstartstider i dette tilfellet).
Akkurat det med XP var ment som at det er mulig å ha tilsvarende korte oppstartistider der også, det var resten av innlegget som var interessant, glem gjerne det med XP.
2 gb får man fra 5000 og oppover(med bærbare), og det er faktisk på tide at et operativsystem faktisk tar i bruk dette minnet istede for at du kan skryte over din 3dmark score!Der har du noe av nøkkelpunktet ved diskusjonen.
HVORFOR ikke BEGGE DELER!?
-
Valg av tegnsett har vært/er et problem og særlig for websider, den ultimate løsningen er å konvertere alt til Unicode så her er mitt bidrag, et script som leser alt av filer i en mappe og oppretter en kopi med valgte tegnsett:
<?php header('Content-Type: text/plain'); /** * Old character encoding */ $oldEncoding = 'ISO-8859-1'; /** * New character encoding */ $newEncoding = 'UTF-8'; /** * Directory containing files with the old encoding */ $dir = './oldDir'; /** * Path where to save converted files * * NOTE: Must be a empty and writable directory */ $destDir = './newDir'; $dirIterator = new RecursiveDirectoryIterator($dir); $iterator = new RecursiveIteratorIterator($dirIterator, RecursiveIteratorIterator::SELF_FIRST); $count = 0; if(!is_writable($destDir)) { throw new Exception('No write permission to destination: ' . $destDir); } foreach($iterator as $file) { $count++; echo "\n" . str_repeat("\t", $iterator->getDepth()) . $file->getPathname(); if($file->isDir()) { continue; } if(!$file->isReadable()){ echo "\nERROR: File not readable!\n\n"; continue; } $path = substr($file->getPathname(), strlen($dir)); $content = file_get_contents($dir . $path); $newFilepath = $destDir . $path; if(false === ($converted = iconv($oldEncoding, $newEncoding, $content))) { echo "\nERROR: Conversion failed!\n\n"; } $dirname = dirname($newFilepath); if(!file_exists($dirname)) { mkdir($dirname, 0777, true); } file_put_contents($newFilepath, $converted); } echo "\n\nTotal: $count\n";- De dokumenterte variablene i starten er ment å endres.
- ext/iconv er nødt til å være installert.
- Scriptet kan fint kjøres gjennom en webserver, men er nok best å kjøre det gjennom terminalen med sin egen bruker sånn at rettighetene til de nye filene blir riktig.
- Viktig at det gamle tegnsettet er oppgitt riktig, ellers vil resultatet kunne bli ikke bare feil, men ubrukelig.
- Lisens: Public Domain eller BSD License
-
2 gb får man fra 5000 og oppover(med bærbare), og det er faktisk på tide at et operativsystem faktisk tar i bruk dette minnet istede for at du kan skryte over din 3dmark score!
Der har du noe av nøkkelpunktet ved diskusjonen.
HVORFOR ikke BEGGE DELER!?
Konkurrentene klarer det, ja tilogmed XP klarer det, selv om jeg forsåvidt liker noe av ideen bak SuperFetch om at operativsystemet selv skal klare å finne ut hvilke programmer som skal forhåndslastes.
-
-
"Det er lite vits å oppgradere motoren for at kjerra skal gå fortere med håndbrekket på. Ta heller av håndbrekket"
Vista er jo raskere på enkelte ting, som oppstart, og oppstart av programmer(integrerte programmer). Noe som er mye viktigere enn superpi og de ekstra 1000 poengene i 3dmark06. Mener jeg, mener bestefar, mener pappa, mener mamma, mener bestemor, mener søster, mener bror, mener onkel og mener kusine.
Noen som vet om noen troverdige undersøkelser om XP eller Vista har raskest oppstart? Min erfaring er at det er så godt som likt. XP (og Windows generelt) blir tregere etterhvert og at Vista kommer bra ut viss man sammenligner med en sånn "utslitt" XP-install bør ikke være noen overraskelse.
Beklager simen1, men slik er det, folk driter visst i superpien, sånn er det bare.Og vista går smoothere i desktop enn xp på min pc(2 gig)(siden jeg er obs på å bruke integrerte programmer), har oppe 3 ie(med minst 2 faner hver), wmp, my computer, task manager og 3 msn vinduer inkludert live today og har bare 48% ram igjen. Det er sløsing etter min mening, at 48% skal stå ubrukt. Klarer liksom ikke å bruke det opp
.Så Vista går "smooth" viss du bruker "integrerte programmer"? Går XP "smooth" uansett hva slags programmer du bruker da?
At ubrukt RAM er bortkastet RAM kan jeg være enig i, men det er ikke vits i å bruke opp RAMet viss man ikke får noe igjen for det, og der er Vista todelt. På den ene siden har de SuperFetch som virker som et bra konsept, selv om dagens implementering neppe er perfekt. På den andre siden er Vista et stort minnesluk som bruker enormt mye mer minne enn hva som er nødvendig for oppgavene.
Og så kommer "superpi"-ytelse i tillegg og sier noe om den generelle ytelsen til systemet, de testene på enkeltprogrammer jeg har sett (inkludert denne) tyder jo på at Vista kommer usedvanlig dårlig ut på dette området og det er mer alvorlig enn ekstrem minnebruk og tilsier at ressursene Vista bruker opp ikke kommer tilbake i form av bedre ytelse, men forsvinner ut i det store intet. Unntaket er da SuperFetch som viss man har enorme RAM-mengder kan gi raskere oppstart av en del programmer på en bedre måte enn at hvert enkelt program forhåndslaster seg selv under oppstart.
Kjør Photoshop i Linux
i Diskuter fotoartikler (Tek.no)
Skrevet
For å være presis vil jeg ikke snakke som "Linux-ytelse", bare Wine-ytelse, altså fordi det ikke er snakk om noen Linux-versjon av Photoshop, bare Photoshop-støtte i kompatibilitetslaget Wine.
Som Wine-utviklerne er nøye på å understreke og som beskrevet i linken, så er ikke Wine en emulator ala sånt man bruker for f.eks å kjøre gamle konsoll-spill på PC, men programfilene må allikevel gå gjennom dette "kompatibilitetslaget" og i praksis er det et ytelses-tap i det ekstraleddet som ikke hadde vært nødvendig viss det var et native GNU/Linux-program
Vertfall så har jeg sett meldinger om at ytelsen er generelt god og at den i noen tilfeller er bedre enn man ville opplevd i Windows og noen ganger dårligere, jeg ville vært mer bekymret for stabiliteten enn for ytelsen...