mboost-dp1
Microsoft
det kan godt ske at de havde lige mange fejl næste4n men det er altså bedre at æave dem på to dage end ti.. er glad for jeg har firefox.. og desuden kan jeg bedre lide firefox'es design..
Jeg forstår ikke helt det her "sikkerhedshul ræs",
Jeg kender ikke nogen der er blevet groft misbrugt pga. sin browser. Det er jo ikke alle og enhver der har programmeringsfærdigheder nok til at misbruge dem.
Når jeg opdaterer mit software er det primært for at få de nye features med.
Jeg kender ikke nogen der er blevet groft misbrugt pga. sin browser. Det er jo ikke alle og enhver der har programmeringsfærdigheder nok til at misbruge dem.
Når jeg opdaterer mit software er det primært for at få de nye features med.
Det skal pointeres at kritiske fejl i Mozilla ikke er åbne for public. Jeg har engang sendt en meget kritisk en ind (wuhuu, $500 :p) , som blev holdt lukket.
De havde en stump patch kode klar løbet af 4-5 dage. Meget imponerede må jeg sige.
Derudover har Mozilla jo autoopdatering, som f.eks. her til aften :)
De havde en stump patch kode klar løbet af 4-5 dage. Meget imponerede må jeg sige.
Derudover har Mozilla jo autoopdatering, som f.eks. her til aften :)
Pointen er ikke saa meget hvor mange fejl der findes. I alt software over en "Hello World" kompleksitet vil der vaere fejl. Det der er vigtigt er hvor hurtigt bliver de fixet? For Microsofts vedkommende er det ikke videre imponerende.
Som #1
Hvis fejlene kun var, text error, bookmark bug eller sådan noget småtteri, kan det jo som sådan være en ligegyldig undersøgelse.
Jeg vil mene når man laver sådan en undersøgelse, må man antage at der er tale om kritiske fejl, som er potentielt farlige for brugeren af browseren.
Men sådan nogle undersøgelser er kendt for at lege lidt med sandheden og vil selv gætte på de har taget ALLE fejl med, som text errors og bookmark bugs og alt det småfnider som normale brugere aldrig ser.
Hvis det er sandt, så er det jo nemt at få FireFox sat i et mindre godt lys og få det til at se ud som FireFox faktisk ikke er så sikkert som det siges.
Hvis fejlene kun var, text error, bookmark bug eller sådan noget småtteri, kan det jo som sådan være en ligegyldig undersøgelse.
Jeg vil mene når man laver sådan en undersøgelse, må man antage at der er tale om kritiske fejl, som er potentielt farlige for brugeren af browseren.
Men sådan nogle undersøgelser er kendt for at lege lidt med sandheden og vil selv gætte på de har taget ALLE fejl med, som text errors og bookmark bugs og alt det småfnider som normale brugere aldrig ser.
Hvis det er sandt, så er det jo nemt at få FireFox sat i et mindre godt lys og få det til at se ud som FireFox faktisk ikke er så sikkert som det siges.
antallet betyder nu ikke så meget som hvad det rent faktisk er fejlen er. 100 fejl som kan få browseren til at crashe er jo ikke engang halvt så slemt som remote arbitrary code execution..
Man kunne måske også undre sig at fejl mængden stiger propotionalt med folk der andvender browserne - kunne det tænkes at jo flere der bruger det jo flere fejl bliver der fundet?
Egentlig vil det jo være mere interresant for en hacker at finde en fejl i IE og Firefox in fx opera da det giver ham adgang til en meget størrer brugerflade...
Egentlig vil det jo være mere interresant for en hacker at finde en fejl i IE og Firefox in fx opera da det giver ham adgang til en meget størrer brugerflade...
#8 Jeg tror du vil blive stærkt overrasket over hvor mange der egentligt bruger Safari og Opera, men måske?
Jeg har svært ved at se relevansen i denne nyhed da vi ikke får at vide hvad fejlene kan få betydning for. Men hvis nogle har en anelse om hvilke fejl der er fundet primært i FF og IE må i endeligt poste det, for jeg har ingen anelse om hvilke.
Jeg har svært ved at se relevansen i denne nyhed da vi ikke får at vide hvad fejlene kan få betydning for. Men hvis nogle har en anelse om hvilke fejl der er fundet primært i FF og IE må i endeligt poste det, for jeg har ingen anelse om hvilke.
#24 i forhold til hvor mange versioner af IE der skal vedligeholdes for sikkerhedshuller synes jeg det er vildt at tallet ikke er højere.
Var der ikke en nyhed om at alle opdateringer til Windows, og derigennem IE, skulle testes i mere end 100 forskellige versioner?
Ja det er rart at hullerne bliver lappet hurtigt, og ingen tvivl om at MS virkelig gør en indsats her.
Firefox teamet retter vel hurtigere idet de har en meget kortere testfase, på grund af de færre versioner.
Var der ikke en nyhed om at alle opdateringer til Windows, og derigennem IE, skulle testes i mere end 100 forskellige versioner?
Ja det er rart at hullerne bliver lappet hurtigt, og ingen tvivl om at MS virkelig gør en indsats her.
Firefox teamet retter vel hurtigere idet de har en meget kortere testfase, på grund af de færre versioner.
Her er et dumt spørgsmål. Hvorfor skal det absolut tage Microsoft længere tid at udvikle patches fordi de er en større virksomhed? Tror i at Office teamet eller ERP teamet har den store indflydelse på eller arbejde med at få shippet patches til IE? Næppe. Den virkelige grund er selvfølgelig at Microsoft satsede på .Net og SOAP - og så havde man den indstilling at browseren var forældet.
Hvis vi taler om at det er mere effektivt at arbejde med open source projekter, så kan jeg godt forstå at det skal tage Microsoft længere - men ellers mener jeg ikke der er den store forskel i IEs og FFs udvikler teams.
Hvis vi taler om at det er mere effektivt at arbejde med open source projekter, så kan jeg godt forstå at det skal tage Microsoft længere - men ellers mener jeg ikke der er den store forskel i IEs og FFs udvikler teams.
Der er, som med med så meget andet, fordele og ulemper ved at være i en stor organisation/koncern.
Er man del af en stor organisation, er det typisk lettere at få resourcer til et projekt, da der generelt er flere resourcer at arbejde med. Omvendt er administration og beslutningsprocesser for det meste lidt mere omstændigt.
Forudsat de store organisationer har kompetencerne (især på ledelsesområdet) og en sund politik for fejlrettelser, ser jeg ingen grund til at det skal tage længere tid at løse fejl, end andre steder.
Hvis man har en leder, der er ansvarlig for fejlhåndtering, og man har planlagt plads til at løse fejl i sin resourcestyring hos de resourcer, der kan lave fixes, så behøver det ikke tage lang tid.
Det, der kan tage lang tid, er derimod dokumentation og aftesting. Jeg ved ikke hvordan open source udviklerne normalt dokumenterer, men jeg ved at især store virksomheder ofte har ret store krav til dokumentation - især af fejlrettelser. Dog ikke i et omfang, der berettiger 8 dage ekstra.
Aftesting af mange versioner kan, naturligvis være et problem - det siger sig selv. Hvis jeg nu var chef et sted, hvor en enkelt rettelse skulle aftestes i mange versioner, ville jeg benytte mig af automatisk testing (det har jeg været med til at lave med stor succes), men det er jo ikke sikkert at MS-lederne i den afdeling, har ment at det var noget at smide penge efter. Det kan sagtens tage 8 dage ekstra. Test tager tid - lang tid.
Er man del af en stor organisation, er det typisk lettere at få resourcer til et projekt, da der generelt er flere resourcer at arbejde med. Omvendt er administration og beslutningsprocesser for det meste lidt mere omstændigt.
Forudsat de store organisationer har kompetencerne (især på ledelsesområdet) og en sund politik for fejlrettelser, ser jeg ingen grund til at det skal tage længere tid at løse fejl, end andre steder.
Hvis man har en leder, der er ansvarlig for fejlhåndtering, og man har planlagt plads til at løse fejl i sin resourcestyring hos de resourcer, der kan lave fixes, så behøver det ikke tage lang tid.
Det, der kan tage lang tid, er derimod dokumentation og aftesting. Jeg ved ikke hvordan open source udviklerne normalt dokumenterer, men jeg ved at især store virksomheder ofte har ret store krav til dokumentation - især af fejlrettelser. Dog ikke i et omfang, der berettiger 8 dage ekstra.
Aftesting af mange versioner kan, naturligvis være et problem - det siger sig selv. Hvis jeg nu var chef et sted, hvor en enkelt rettelse skulle aftestes i mange versioner, ville jeg benytte mig af automatisk testing (det har jeg været med til at lave med stor succes), men det er jo ikke sikkert at MS-lederne i den afdeling, har ment at det var noget at smide penge efter. Det kan sagtens tage 8 dage ekstra. Test tager tid - lang tid.
#32
Ja præcist ligesom Apple har 100% monopol på hardware til deres eget OSX.
Andele er så dejlig simple at manipulere så det passer ens egen plan.
Men Safari's udbredelse er meget lille i forhold til FF og IE når man kigger på alle computere.
Og kiggede du på hvad artiklen drejer sig om kan du se at Safari's andel på OSX er fløjtende irrelevant.
Ja præcist ligesom Apple har 100% monopol på hardware til deres eget OSX.
Andele er så dejlig simple at manipulere så det passer ens egen plan.
Men Safari's udbredelse er meget lille i forhold til FF og IE når man kigger på alle computere.
Og kiggede du på hvad artiklen drejer sig om kan du se at Safari's andel på OSX er fløjtende irrelevant.
#30 Ja. Jeg kan f.eks nævne at hos ABB tager det ikke 10 (og slet ikke mere end 200) dage at fikse en bug - slet ikke når downtime i bl.a. Olie og Gas industrien koster adskillige millioner kroner i minuttet. Derfor må jeg konkludere at det er fordi Microsoft ikke har viljen til at gennemføre patchningen i en rimelig tid, fordi det ikke har nogen direkte økonomisk konsekvens på deres bundlinje.
#35 Så burde de måske overveje at skifte til en mere agil organisationsstruktur?
#35 Så burde de måske overveje at skifte til en mere agil organisationsstruktur?
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund