mboost-dp1
unknown
#46 - Problemet ligger ikke i, at man tvinger folk til at opgradere, men derimod i at man skal tappe dem for penge mens man gør det.
Windows 2000 vurderes af mange, med alle dets service packs, at være mere stabilt og sikkert end Windows XP pro, som er Windows 2000's arvtager. Microsoft deler ikke den vurdering, og er i svag grad allerede ved at udfase Windows 2000 som operativsystem. (ikke noget officielt endnu, men det er da interessant, at XP SP2 havde rettet en fejl, som ikke var rettet til Windows 2000 endnu?). Samme med Windows 98, som fx i min bevisthed var den sidste platform, som man kunne installere C&C Win95-edition på. Den er snart ikke god nok mere, og snart vil den blive efterladt i en sikkerheds-afgrund.
Microsofts markedsteori baserer sig så på, at folk "bare må" "opdatere" deres Windows-installation, så den er "med i tiden".
Men det er noget vås, for en Win98-maskine er fin at køre httpd og ftpd på, eksempelvis. (Om end jeg personlig ville brække mig over det). Hvorfor i alverden er det, at Microsoft ikke kan vedligeholde supporten, så (meget) ældre systemer kan følge med?
I den forbindelse skal det siges at Windows XP kræver en i686'er. Hvis man ikke har en P2 eller derover, så er det synd, og man må "bare" købe en ny maskine - som sikkert sluger mere energi.
Det er min mening, og jeg er ikke sikker på, om jeg taler på andre end mine egne vejne.
Windows 2000 vurderes af mange, med alle dets service packs, at være mere stabilt og sikkert end Windows XP pro, som er Windows 2000's arvtager. Microsoft deler ikke den vurdering, og er i svag grad allerede ved at udfase Windows 2000 som operativsystem. (ikke noget officielt endnu, men det er da interessant, at XP SP2 havde rettet en fejl, som ikke var rettet til Windows 2000 endnu?). Samme med Windows 98, som fx i min bevisthed var den sidste platform, som man kunne installere C&C Win95-edition på. Den er snart ikke god nok mere, og snart vil den blive efterladt i en sikkerheds-afgrund.
Microsofts markedsteori baserer sig så på, at folk "bare må" "opdatere" deres Windows-installation, så den er "med i tiden".
Men det er noget vås, for en Win98-maskine er fin at køre httpd og ftpd på, eksempelvis. (Om end jeg personlig ville brække mig over det). Hvorfor i alverden er det, at Microsoft ikke kan vedligeholde supporten, så (meget) ældre systemer kan følge med?
I den forbindelse skal det siges at Windows XP kræver en i686'er. Hvis man ikke har en P2 eller derover, så er det synd, og man må "bare" købe en ny maskine - som sikkert sluger mere energi.
Det er min mening, og jeg er ikke sikker på, om jeg taler på andre end mine egne vejne.
#42
hvis der er andre måder, hvad er det så? og hvorfor er det ikke gjort? hov, det er nok fordi at dem som ville kunne gøre noget ved det er den normale forbruger, men de er fuldstændig ligeglade med det hele. og derfor bliver det ikke gjort.
det vil at det igen bliver nødt til at gå som det gør nu. folk kan bare være glade for at der ikke har været en som har været virkelig ond endnu.
hvis der er andre måder, hvad er det så? og hvorfor er det ikke gjort? hov, det er nok fordi at dem som ville kunne gøre noget ved det er den normale forbruger, men de er fuldstændig ligeglade med det hele. og derfor bliver det ikke gjort.
det vil at det igen bliver nødt til at gå som det gør nu. folk kan bare være glade for at der ikke har været en som har været virkelig ond endnu.
#12
Ja, det lyder meget sandsynligt. Så indtil der kommer noget konkret dokumentation bør man frygte det værste.
#16
Din argumentation holder ikke. Apache har tre gange så mange brugere som Microsofts webservere. Alligevel bliver Apache ikke angrebet i nær så stor udstrækning. Microsoft produkter er mest udsat både på de områder hvor de har stor udbredelse og de områder hvor de har lille udbredelse.
#35 NX bitten beskytter stakken, IKKE heapen/free store.
Jeg kender ikke Microsofts implementation. Men faktum er, at NX sagtens kan beskytte heapen. Faktisk er det nemmere at beskytte heapen end stakken. Når heap alloceres angiver man nemlig om der er brug for at afvikle kode derfra. På stakken sker der til gengæld ingen eksplicit allocering, og derfor ved OS ikke hvilke dele af stakken der er behov for at afvikle kode fra. Heldigvis har de færeste programmer brug for at afvikle kode fra stakken. Men hvis du f.eks. bruger pointere til nestede funktioner vil gcc generere kode, der lægger trampoliner på stakken. Den nyeste implementation kan vist nok undgå afvikling af kode fra stakken, men det må nødvendigvis være mere compliceret.
Stakken er et hurtigt last-in-last-out lager
Nej, det er omvendt.
der dog er begrænset hvorfor man skal passe på med rekursive kald
Grænsen kan justeres efter behov. F.eks. har mange Linux versioner som default en grænse på 8MB. Men programmet kan sætte den op i nærheden af 2GB, hvis der er brug for det. Man har bare sjældent brug for så meget, og hovedparten af de gange man når op til 8MB skyldes uendelig rekursion.
imens heapen er meget langsommere men tilgængæld mange gange større
Sludder.
Derfor er heap-overrun også sværere at udnytte.
Den primære grund til at buffer overflows på stakken er nemme at udnytte er, at man som regel har mulighed for at overskrive en returaddresse.
Jeg kommer helt i tvivl om, hvorvidt du ved noget, om det du skriver om.
Ja, det lyder meget sandsynligt. Så indtil der kommer noget konkret dokumentation bør man frygte det værste.
#16
Din argumentation holder ikke. Apache har tre gange så mange brugere som Microsofts webservere. Alligevel bliver Apache ikke angrebet i nær så stor udstrækning. Microsoft produkter er mest udsat både på de områder hvor de har stor udbredelse og de områder hvor de har lille udbredelse.
#35 NX bitten beskytter stakken, IKKE heapen/free store.
Jeg kender ikke Microsofts implementation. Men faktum er, at NX sagtens kan beskytte heapen. Faktisk er det nemmere at beskytte heapen end stakken. Når heap alloceres angiver man nemlig om der er brug for at afvikle kode derfra. På stakken sker der til gengæld ingen eksplicit allocering, og derfor ved OS ikke hvilke dele af stakken der er behov for at afvikle kode fra. Heldigvis har de færeste programmer brug for at afvikle kode fra stakken. Men hvis du f.eks. bruger pointere til nestede funktioner vil gcc generere kode, der lægger trampoliner på stakken. Den nyeste implementation kan vist nok undgå afvikling af kode fra stakken, men det må nødvendigvis være mere compliceret.
Stakken er et hurtigt last-in-last-out lager
Nej, det er omvendt.
der dog er begrænset hvorfor man skal passe på med rekursive kald
Grænsen kan justeres efter behov. F.eks. har mange Linux versioner som default en grænse på 8MB. Men programmet kan sætte den op i nærheden af 2GB, hvis der er brug for det. Man har bare sjældent brug for så meget, og hovedparten af de gange man når op til 8MB skyldes uendelig rekursion.
imens heapen er meget langsommere men tilgængæld mange gange større
Sludder.
Derfor er heap-overrun også sværere at udnytte.
Den primære grund til at buffer overflows på stakken er nemme at udnytte er, at man som regel har mulighed for at overskrive en returaddresse.
Jeg kommer helt i tvivl om, hvorvidt du ved noget, om det du skriver om.
#53:
Ja den KAN beskytte heapen men gør det ikke endnu med mindre man har allokeret med win32 API'erne VirtualAlloc()/VirtualProtect(). Den "page protection" bit du omtaler har ganske rigtigt altid eksisteret (og dermed sat af programmører) men på pre-NX CPU'er bliver denne ignoreret.
[Stakken er et hurtigt last-in-last-out lager
Nej, det er omvendt.]
Klart, en fortalelse, jeg mente LIFO - last in first out.
[Grænsen kan justeres efter behov.]
Ændrer ikke på dét faktum at man skal passe på stakken ved rekursive kald og klart have defineret sine exit-conditions. Hvis man i sine kald ligger meget på stakken så skal der pludselig ikke mange kald til et stack overflow - hvorfor vi da som regel også bør kode iterativt hvis det er muligt (er det næsten altid) og desuden benytte heapen (new eller static). Enhver tekstbog om emnet bekræfter dette, du nævner 8 MB som standard stak størrelse - på en moderne (Windows) maskine har du så resten af den "free store"/heap tilbage, i mit tilfælde 300 MB.
[Sludder.]
Det er naturligvis den samme RAM der bruges, forskellen ligger i hvordan denne bruges. På heapen er det ofte garbage collection (Java/C#) hvilket i sig selv koster 15%-25%. Men selv i C/C++ er der forskel, f.eks. hvor du blot skal inkrementere en pointer i en kontinuerlig blok af hukommelse frem for at hoppe rundt i et fragmenteret heap via en virtuel memmory pool.
[som regel har mulighed for at overskrive en returaddresse]
Ja det er jo klart, igen fordi stakken er sekventiel og dermed mere deterministisk end heapen.
[Jeg kommer helt i tvivl om, hvorvidt du ved noget, om det du skriver om.]
Tror bare du lever i en Linux verden.
Ja den KAN beskytte heapen men gør det ikke endnu med mindre man har allokeret med win32 API'erne VirtualAlloc()/VirtualProtect(). Den "page protection" bit du omtaler har ganske rigtigt altid eksisteret (og dermed sat af programmører) men på pre-NX CPU'er bliver denne ignoreret.
[Stakken er et hurtigt last-in-last-out lager
Nej, det er omvendt.]
Klart, en fortalelse, jeg mente LIFO - last in first out.
[Grænsen kan justeres efter behov.]
Ændrer ikke på dét faktum at man skal passe på stakken ved rekursive kald og klart have defineret sine exit-conditions. Hvis man i sine kald ligger meget på stakken så skal der pludselig ikke mange kald til et stack overflow - hvorfor vi da som regel også bør kode iterativt hvis det er muligt (er det næsten altid) og desuden benytte heapen (new eller static). Enhver tekstbog om emnet bekræfter dette, du nævner 8 MB som standard stak størrelse - på en moderne (Windows) maskine har du så resten af den "free store"/heap tilbage, i mit tilfælde 300 MB.
[Sludder.]
Det er naturligvis den samme RAM der bruges, forskellen ligger i hvordan denne bruges. På heapen er det ofte garbage collection (Java/C#) hvilket i sig selv koster 15%-25%. Men selv i C/C++ er der forskel, f.eks. hvor du blot skal inkrementere en pointer i en kontinuerlig blok af hukommelse frem for at hoppe rundt i et fragmenteret heap via en virtuel memmory pool.
[som regel har mulighed for at overskrive en returaddresse]
Ja det er jo klart, igen fordi stakken er sekventiel og dermed mere deterministisk end heapen.
[Jeg kommer helt i tvivl om, hvorvidt du ved noget, om det du skriver om.]
Tror bare du lever i en Linux verden.
# 47 Deternal
Hvis du magtede at fatte noget, ville du vide at hr. og fru Jensen køber deres Windows med deres computer, dvs. OEM.
Hvis du magtede at fatte noget, ville du vide at hr. og fru Jensen køber deres Windows med deres computer, dvs. OEM.
#54 Den "page protection" bit du omtaler har ganske rigtigt altid eksisteret (og dermed sat af programmører) men på pre-NX CPU'er bliver denne ignoreret.
Men det betyder så at hvis programmørerne ikke har dummet sig alt for meget, så får man glæde af NX med det samme. Mange andre arkitekturer har haft en execute bit i mange år, så det er sikkert nemmere at få den del af koden rigtig med posix APIen, som bruges af et utal af operativsystemer på et utal af arkitekturer. Hvis ikke man lige brugte en PC ville execute bitten faktisk have virkning.
Ændrer ikke på dét faktum at man skal passe på stakken ved rekursive kald og klart have defineret sine exit-conditions. Hvis man i sine kald ligger meget på stakken så skal der pludselig ikke mange kald til et stack overflow
Jeg kan ikke erindre en eneste gang en 8MB stak har været et problem for mig. Selvfølgelig har jeg skrevet programmer, der arbejdede med mere end 8MB data, men der er bare ikke ret meget, som det giver mening at allokere på stakken.
hvor du blot skal inkrementere en pointer i en kontinuerlig blok af hukommelse frem for at hoppe rundt i et fragmenteret heap via en virtuel memmory pool.
Snakker du nu om tidsforbrug til allokering? Det er selvfølgelig klart at man hurtigere kan allokere hukommelse på stakken end i heapen. Men det er ikke hastigheden, som er afgørende for, om man allokerer det ene eller det andet sted. Hvis en allokering skal leve indtil funktionen afsluttes kan den allokeres fra stakken. Skal den leve længere kan en stak allokering slet ikke komme på tale. Og har allokeringen dynamisk størrelse er det omtrent lige så nemt at allokere den fra heapen som fra stakken. (alloca er ikke noget hit). Og snakker vi allokeringer af fast størrelse er de enten så små, at der er plads på stakken eller så store, at overheadet ved allokering er negligibelt.
Jeg kunne godt tænke mig at se det tilfælde, hvor det ville give mening at allokere mere end 1MB på stakken.
Men det betyder så at hvis programmørerne ikke har dummet sig alt for meget, så får man glæde af NX med det samme. Mange andre arkitekturer har haft en execute bit i mange år, så det er sikkert nemmere at få den del af koden rigtig med posix APIen, som bruges af et utal af operativsystemer på et utal af arkitekturer. Hvis ikke man lige brugte en PC ville execute bitten faktisk have virkning.
Ændrer ikke på dét faktum at man skal passe på stakken ved rekursive kald og klart have defineret sine exit-conditions. Hvis man i sine kald ligger meget på stakken så skal der pludselig ikke mange kald til et stack overflow
Jeg kan ikke erindre en eneste gang en 8MB stak har været et problem for mig. Selvfølgelig har jeg skrevet programmer, der arbejdede med mere end 8MB data, men der er bare ikke ret meget, som det giver mening at allokere på stakken.
hvor du blot skal inkrementere en pointer i en kontinuerlig blok af hukommelse frem for at hoppe rundt i et fragmenteret heap via en virtuel memmory pool.
Snakker du nu om tidsforbrug til allokering? Det er selvfølgelig klart at man hurtigere kan allokere hukommelse på stakken end i heapen. Men det er ikke hastigheden, som er afgørende for, om man allokerer det ene eller det andet sted. Hvis en allokering skal leve indtil funktionen afsluttes kan den allokeres fra stakken. Skal den leve længere kan en stak allokering slet ikke komme på tale. Og har allokeringen dynamisk størrelse er det omtrent lige så nemt at allokere den fra heapen som fra stakken. (alloca er ikke noget hit). Og snakker vi allokeringer af fast størrelse er de enten så små, at der er plads på stakken eller så store, at overheadet ved allokering er negligibelt.
Jeg kunne godt tænke mig at se det tilfælde, hvor det ville give mening at allokere mere end 1MB på stakken.
#56
OEM betyder ikke kun at den er uden support. Det kan godt være man tror man har en lovlig version, men det er ikke altid tilfældet. Fx hvis man køber OEM versionen sammen med en mus og musen skal skiftes ud. Eller køber OEM sammen med en computer og skifter en vital del ud, fx bundkort eller cpu. Måske har man bedre samvittighed fordi man har betalt for windows, men det er ikke altid ens betydende med at man bruger det lovligt.
OEM betyder ikke kun at den er uden support. Det kan godt være man tror man har en lovlig version, men det er ikke altid tilfældet. Fx hvis man køber OEM versionen sammen med en mus og musen skal skiftes ud. Eller køber OEM sammen med en computer og skifter en vital del ud, fx bundkort eller cpu. Måske har man bedre samvittighed fordi man har betalt for windows, men det er ikke altid ens betydende med at man bruger det lovligt.
#55: Især når man opgraderer sin windows som der var snak om her. Rart at se du følger med i tråden og svarer relevant på comments, eller nå nej.
For ja, hvis Hr. og Fr. Jensen køber en maskine kan de slet ikke undgå at få en tilfældig OEM version af windows smidt med i nakken.
#58: Afaik beskytter forbrugerlovgivningen os således at hvis vi har købt windows (selv som OEM udgave) har vi rent faktisk også lov at sælge den videre - bruge den på en anden computer etc. præcis som man ville forvente v. køb af software. Dette gør sig dog /ikke/ gældende for businesses.
For ja, hvis Hr. og Fr. Jensen køber en maskine kan de slet ikke undgå at få en tilfældig OEM version af windows smidt med i nakken.
#58: Afaik beskytter forbrugerlovgivningen os således at hvis vi har købt windows (selv som OEM udgave) har vi rent faktisk også lov at sælge den videre - bruge den på en anden computer etc. præcis som man ville forvente v. køb af software. Dette gør sig dog /ikke/ gældende for businesses.
#58 michael007dk
[OEM betyder ikke kun at den er uden support. Det kan godt være man tror man har en lovlig version, men det er ikke altid tilfældet. Fx hvis man køber OEM versionen sammen med en mus og musen skal skiftes ud. Eller køber OEM sammen med en computer og skifter en vital del ud, fx bundkort eller cpu. Måske har man bedre samvittighed fordi man har betalt for windows, men det er ikke altid ens betydende med at man bruger det lovligt.]
Jo det er det faktisk.
For det er ikke Microsoft der skriver ophavslovene... ;)
Ikke alle klausuler i deres licens gælder i Danmark.
[OEM betyder ikke kun at den er uden support. Det kan godt være man tror man har en lovlig version, men det er ikke altid tilfældet. Fx hvis man køber OEM versionen sammen med en mus og musen skal skiftes ud. Eller køber OEM sammen med en computer og skifter en vital del ud, fx bundkort eller cpu. Måske har man bedre samvittighed fordi man har betalt for windows, men det er ikke altid ens betydende med at man bruger det lovligt.]
Jo det er det faktisk.
For det er ikke Microsoft der skriver ophavslovene... ;)
Ikke alle klausuler i deres licens gælder i Danmark.
Sidenote:
SÅ er vi også nogle der slet ikke kan få lov til at installere en SP2 på sin lovlige XP home :(.
Og jeg kører da stadig Windows 98SE på min stationære og gider da ikke opgraderer da den kører perfekt og nægter at give 3-4000 kr for en Windows 2000/XP. Og besides, de fleste bugs, exploits og så videre der er kommet frem her de sidste mange måneder gælder kun Windows 2000 og XP.
SÅ er vi også nogle der slet ikke kan få lov til at installere en SP2 på sin lovlige XP home :(.
Og jeg kører da stadig Windows 98SE på min stationære og gider da ikke opgraderer da den kører perfekt og nægter at give 3-4000 kr for en Windows 2000/XP. Og besides, de fleste bugs, exploits og så videre der er kommet frem her de sidste mange måneder gælder kun Windows 2000 og XP.
#60+#61: Det springende punkt er om man har fået oplyst betingelserne inden køb - jeg er ikke klar over om man bliver gjort opmærksom på de punkter udenpå pakken idag. Grunden er at man skal kunne tage stilling til betingelserne inden et køb.
Betingelserne gælder iøvrigt for virksomheder da de har 'aftalefrihed'. Bare for lige at få det på plads hvorfor de klausuler ikke gælder.
I nogle tilfælde vil de dog også stride mod den generelle beskyttelse af privatforbrugere, men da det er en licens man har købt har sælger altså flere muligheder for at give forbrugeren begrænsninger.
Betingelserne gælder iøvrigt for virksomheder da de har 'aftalefrihed'. Bare for lige at få det på plads hvorfor de klausuler ikke gælder.
I nogle tilfælde vil de dog også stride mod den generelle beskyttelse af privatforbrugere, men da det er en licens man har købt har sælger altså flere muligheder for at give forbrugeren begrænsninger.
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