Gepubliceerd: Maandag 14 september 2009
Het vorige week geopenbaarde gat in TCP/IP blijkt ook aanwezig in Windows XP, wat eerst veilig werd geacht. Net als voorganger 2000 krijgt XP geen patch.
Toon volledig artikel
Tis zo simpel , nu moeten ze wel aan de vista....
heel slim , ultiem bewijs van de miscrosoft lock in....
Misschien toch maar linux?
Tis zo simpel , nu moeten ze wel aan de vista....
heel slim , ultiem bewijs van de miscrosoft lock in....
Dat was ook het eerste dat bij mij op kwam. Ik zou er hier op deze plek voor willen pleiten dat de overheid Microsoft verplicht om dit soort serieuze fouten in veel gebruikte software, zoals XP, te verhelpen. Het is toch bij de wilde beesten af dat ze dit zo maar mogen doen?
De reden hiervoor is dat dit teveel werk zou kosten. De architectuur is te verschillend om tcp/ip-bescherming te kunnen implementeren, stelt de softwareproducent.
De aap was bij Windows 2000 al uit de mouw, natuurlijk. Ze zeggen het hier alleen veel vriendelijker dan toen. Als Microsoft deze fout wil verhelpen, dan moet het hele OS op de schop en dat is geen verrassing. Als die reeksen vam telkens terugkerende fouten en kwetsbaarheden kunnen eigenlijk maar een ding betekenen: Er zitten serieuze en ernstig ontwerp fouten (Design Flaws) in Windows.
Het is dus heel makkelijk, als het te moeilijk wordt laat je het gewoon lopen en de klant stikken, zijn geld had je toch al.
De client- en serveruitvoeringen van Windows 2000 genieten nog support tot juli komend jaar. Tenzij er een uitzondering wordt gemaakt, zoals nu.
Dit heet in gewoon Nederlands: Stoep garantie. Je hebt met Windows garantie tot de deur.
Het grote verschil is dat Win2000 voornamelijk professioneel gebruikt wordt, en dus ondersteund wordt door een IT afdeling die zelf passende maatregelen kan nemen.
En als ze dat niet doen dan regelt de baas het verder.
Consumenten thuis hebben geen W2000 maar XP, en ook geen manager om de IT afdeling achter de vodden te zitten.
Deze gebruikers blijven dus met een onbeveiligd systeem zitten.
Je hebt met Windows garantie tot de deur.
Je haalt de deur niet eens.
Ze geven geen enkele garantie, lees de bijsluiter maar.
Als jouw bedrijf in de problemen komt door MS software, geeft MS niet thuis.
Als een automobielbedrijf problemen ontdekt met een bezietank, worden alle auto´s teruggeroepen naar de garage. Dat is het verschil.
Er zijn producten zat die uit de handel worden genomen.
Het wordt tijd dat diverse MS producten uit de handel worden genomen.
Wat is het criterium? Hoe erg moet het worden?
Als een automobielbedrijf problemen ontdekt met een bezietank, worden alle auto´s teruggeroepen naar de garage. Dat is het verschil.
Think again. Als een automobielbedrijf problemen ontdekt met een onderdeel, dan maken ze een kosten-baten analyse om te bepalen of ze ermee weg komen het onderdeel niet te vervangen. Als de vervangingskosten hoger zijn dan de geschatte kosten door de problemen te laten ontstaan, dan zullen ze niet vervangen of in ieder geval niet terugroepen. Indien je me niet geloofd... hoe vaak is jouw auto al terugeroepen? Denk je dat dit is omdat er zo weinig fouten gevonden zijn?
Ik weet niet meer welk merk het was, maar aantal jaartjes geleden werden alle auto´s van een bepaalde serie naar de garage teruggeroepen wegens mogelijke benzinetank problemen. Dit was een voorzorgsmaatregel.
Dell heeft eens 4 miljoen batterijen terug gehaald.
Als het over software gaat, blijkt het ineens een andere wereld te zijn. Een virtuele wereld alsof deze niet bestaat. Maar er zijn wel degelijk gevallen van zelfmoord bekend omdat software is gehackt.
Lage kwaliteit software kan vreselijk veel schade aanrichten. Voorbeelden genoeg. Een 2e traps raket die ineens in de achteruit stand staat en de raket stort neer. Een Boeing 767 die door een fout in de software verongelukt. Kruisraketten die per ongelijk worden afgeschoten door een virus? misschien maak ik het nog mee.
Alleen 1 ding is zeker, Microsoft zal geen enkele verantwoordelijkheid nemen. Schade zal niet op Microsoft verhaald kunnen worden.
Eigenlijk zouden ze nu alle windows versies van de markt moeten halen. Speelgoed pistolen die echt lijken mag ook niet.
Het wordt hoog tijd voor een kwaliteits stempel. De consument moet kunnen zien dat ze met onveilige software werkt.
kun je met open source de verantwoordelijkheid beter regelen en wie is er dan de verantworodleijke?
Is OSS per definitie beter en veiliger?
Garandeer jij me dat een open source product geen problemen veroorzaakt?
Garandeer jij de tijdige updates en beveiligingsupdates die nodig zijn voor een ongestoorde werking?
Ik verwacht op tenminste alle vragen een duidelijk ja met een goede motivatie. Als je die niet kunt geven klets je dus fiks uit je nek.
lees ook bijv: http://webwereld.nl/article/comments/id/58262
kun je met open source de verantwoordelijkheid beter regelen en wie is er dan de verantworodleijke?
Wie is er volgens jou verantwoordelijk voor dit lek in XP?
Let wel: er is voor de licentie betaald, met de garantie van service packs.
Voor Open Source betaal je niets en je hebt doorgaans plenty mogelijkheden om te patchen of om fouten heen te werken. Let wel poortjes 139 en 445 dicht zetten in een Windows netwerk omgeving is geen oplossing.
aangezien laps niet antwoord..
Wie is er volgens jou verantwoordelijk voor dit lek in XP?
Let wel: er is voor de licentie betaald, met de garantie van service packs.
je stelt twee verschillende vragen.. de verantwoordelijkheid voor het probleem met de TCP/IP implementatie is onduidelijk omdat we niet weten waar het probleem zit. Daar is net geen duidelijkheid over.
Als je bedoelt dat MS zijn spullen moet patchen heb je helemaal gelijk en daarvoor zijn zij verantwoordelijk en daarvoor heb je ook extended support. Ik vraag me alleen af waarom men deze starre houding kiest en net zoals Red Hat de afwijzing kiest. Dat lijkt met problemen in het protocol te maken te hebben waar de verantwoordelijkheid niet duidelijk ligt.
Hoewel iedere analogie riskant is hier een poging:
Als blijkt dat 230 Volt ineens een groot probleem is geworden bij gebruik in een kwade opzet, wie is dan verantwoordelijk. De energieleverancier die het voltage moet aanpassen ( en lost dat het probleem op?) of de kwaadwillende die de problemen verzorgt. Die laatste in ieder geval maar in het geval van software en hackers zijn die niet altijd te vinden en zeker niet aanspreekbaar voor schade. Dus moet de leverancier alles doen om schade te beperken binnen zijn mogelijkheden. Waar ligt hier de grens? En welke mogelijkheden zijn er.. het is een speciaal geval dit keer blijkbaar!
Ja, dat is te regelen. Hoe? Door een heel stevig contract af te sluiten met je leverancier. IBM zet Linux in op z'n mainframes. Daar hangt een supportcontract aan met garanties van een iets andere orde dan Windows XP. Kost een stuk meer ook.. dat wel, kwestie van kosten/baten afwegen.
Het grote voordeel van OSS: de oplossing van dit issue zit mogelijk al in nieuwe releases van Linux. Zodra dat zo is, kun je besluiten dit desnoods helemaal zelf te backporten zodat je het probleem oplost zonder andere variabelen in je systeem te introduceren.
Een upgrade van Windows of een ander gesloten systeem lost je probleem wel op, maar introduceert nog een heleboel meer nieuwe gedragskarakteristieken.
los van de antwoorden van laps, die op zich laten wachten.
Welke garantie geef jij dat een linux patch geen onverwachte bijwerkingen heeft die je bij XP wel verwacht?
Ook IBM zal zijn verantwoordleijkheid beperken tot haalbare doelen en opbrengsten. Een scherp SLA zal nooit de garantie bieden dat er GEEN problemen optreden, wel dat de leveranciers zijn best zal doen die op te lossen. In dit kader is de houding van Red had wel interessant, die heeft toch ook stevige support contracten.
Als een atoomcentrale ontploft door een softwareprobleem heb je overigens weinig aan een schadevergoeding voor de nabestaanden. Garanties zijn vaak een papieren tijger waar je jezelf niet op moet dood staren.
Ik persoonlijk ga je dat inderdaad niet garanderen. Open source stelt je echter wel in staat om zelf je prioriteiten te stellen. Je bent niet afhankelijk van de agenda van een fabrikant en je hebt ook de keuze om alle code te auditen voordat er ook maar iets op je systeem wordt toegelaten. Dat kan, afhankelijk van je situatie, een grote meerwaarde zijn.
In mijn eigen situatie ben ik bijzonder gelukkig met het feit dat de upgrade-cyclus ingericht op de dynamiek van onze organisatie, en niet die van een leverancier.
Ook wel aardig: er hoeven geen licenties zoals bijvoorbeeld CAL's geadministreerd te worden, geen gedoe met voorwaarden voor gebruik in virtuele omgevingen of gedoe met licenties per CPU-core en mensen mogen het ook gewoon op hun laptop mee naar huis nemen. Dit gaat niet zozeer over kosten maar over gemak, en een zekere mate van vrijheid.
Open source stelt je echter wel in staat om zelf je prioriteiten te stellen. Je bent niet afhankelijk van de agenda van een fabrikant en je hebt ook de keuze om alle code te auditen voordat er ook maar iets op je systeem wordt toegelaten. Dat kan, afhankelijk van je situatie, een grote meerwaarde zijn.
Opvallend want door die keuzes te maken neem je de verantwoordlijkheid zelf en daar zal een leverancier niet snel op ingaan bij problemen. het waren immers jouw keuzes en niet de zijne!
Je lost daarmee dus het probleem van de verantwoordelijkheid van een leverancier voor zijn spullen niet echt op.
Wie is trouwens de leverancier van open source.. is dat een Red hat of de codeschrijver die zonder aanspraak zijn module oid ter beschikking stelt en terecht zelden of nooit de verantwoordelijkheid voor het gebruik neemt.
Kortom, geen oplossing voor het geschetste probleem en zeker niet voor de opmerkingen van laps.
Je kunt die verantwoordelijkheid natuurlijk ook gewoon delegeren naar een derde partij. Dat kan gewoon bij, onder meer, IBM, RedHat, Novell en nog een hele sloot anderen. Daar krijg je minstens dezelfde garanties als bij gesloten software dus daar zit geen verschil. Bij open source blijven wel de voordelen overeind die ik hierboven genoemd heb, ook als je de verantwoordelijkheid delegeert.
De vraag wie je leverancier is, is natuurlijk heel eenvoudig. Bij wie heb je je spullen gekocht en waar heb je je supportcontract? Dat staat keurig op papier, dus geen onduidelijkheid.
keren we terug naar Red Hat als een voorbeeld van wat jij graag ziet en met alle voordelen van open source zonder de vermeende nadelen van closed source.
Die doen hetzelfde als MS voor hun gebruikers.. verklaring past niet echt bij je verhaal lijkt me zo.
Daarnaast zal een leverancier van open source jouw eigen keuzes waarschijnlijk uitsluiten als die niet passen bij zijn normale SLA opzet. Maar ook daar heb je nog steeds geen garantie dat er niks mis kan gaan, die is simpelweg niet te geven. Niet door closed source en niet door open source firma;s. perfecte software bestaat niet dus je kunt hooguit tot op beperkte hoogte een indekking tegen schade regelen.
Nogmaals ene bedrijf zal ongetwijfeld zijn best doen het op te lossen binnen het SLA. De realiteit is dat ik teveel SLA heb gezien waarin wel schadevergoedingen staan en voornemens en reactietijden en oplostijden soms zelfs, maar feitelijk zijn die afhankelijk van de situatie en bieden dus op zichzelf geen garantie tegen onheil. Dat kan ook niet en het is onredelijk te denken dat daar een fundamenteel verschil zit in de benadering closed versus open source.
Jongens, sorry dat ik het zeg, maar wat een non-discussie. Jullie zijn gezellig appels met peren aan het vergelijken. Linux is geen product in de zin dat Windows dat is. Je kunt ze dus niet langs dezelfde meetlat leggen.
De kernvraag is of het gerechtvaardigd is dat Windows XP niet gepatcht wordt op het TCP/IP lek (even afgezien van de discussie of niet uberhaupt mogelijk is). M.a.w. is het de verplichting van de leverancier dat een lek gedicht wordt wat (waarschijnlijk) niet door de leverancier zelf veroorzaakt is? Zo ja, hoe lang geldt deze verplichting? Bij een fysiek apparaat is dat momenteel (in Nederland) 1-2 jaar, maar voor software ligt dit anders. Kunnen de leeftijd van de software en het doel van de software een rol spelen in de verplichting van de leverancier?
Ik heb eigenlijk nog niemand kunnen betrappen op goede antwoorden op de bovenstaande vragen. Dat is ook niet zo gek, want het is complexe materie en de wetgeving hierover op z'n minst vaag. Ik heb het antwoord zelf ook niet in algemene zin. In dit geval denk ik dat Microsoft er onverstandig aan doet het niet te patchen (al is het maar om de publieke opinie), maar tegelijk vind ik dat ze hiertoe niet verplicht zijn. Voor Windows server producten vind ik van wel.
Zo complex is die materie niet. Er zit een fout in een product dat door leverancier nog steeds verkocht en ondersteund wordt. Dat moet dus opgelost worden. Is een doodsimpele consequentie van twee zaken: eindeloze 'support' garanderen op een sterk verouderd product, en de broncode van het product in kwestie gesloten houden.
Bedankt voor je link, ik wist niet dat deze discussie gevoerd was.
Vrije software garandeert niks, lijkt me ook logisch voor een copy left licentie
Diverse open source leveranciers leveren gegarandeerde onderhoud. Zelfs 5 jaar gratis: Ubuntu 8.04 LTS Server: Released April 2008 and maintained until April 2013
Feit is wel dat, als ik alleen al kijk naar het aantal virussen en lekken in windows, de windows software niet het stempel veilig krijgt.
Zelfs met een condoom erop is het niet veilig surfen. Dat zou iedereen moeten weten.
Ik heb eventjes gezocht. Er zijn/waren blijkbaar opensource projecten met een stempel veilig. Weet niet wat de status nu is.
Volgens deze pagina op de MS site, verloopt extended support voor WinXP op 08/04/2014.
Sinds bedrijven voor extended support betalen, zullen ze dit lek gewoon maken.
Dit lek zal gemaakt moeten worden omdat XP gewoon verkocht wordt op netbooks en eeepc's. Microsoft Marketing stuurt graag dit soort berichten uit om XP te "Demoniseren". In NL weten we dat dit een heel effectieve (s)linkse methode is.
XP is ook onderdeel van het Microsoft Embedded programma dus ook hier zal gepatched moeten worden.
Dit lek zal gemaakt moeten worden omdat XP gewoon verkocht wordt op netbooks en eeepc's.
Ik kan me niet echt voorstellen dat netbooks en eeepc's ingezet worden als server.
Problemen als een connection queue exhaustion of een TCP/IP Orphaned Connections Vulnerability zullen daar vrijwel nooit tot rampen leiden denk ik.
Het probleem lijkt een stuk moeilijker als eerst aangenomen. Servers van Microsoft (en anderen) zijn voor zover ik begrijp ook nog steeds niet honderd procent veilig, ze zijn alleen beter bestand gemaakt tegen dit soort aanvallen.
he updates for Windows Server 2003 and Windows Server 2008 do not completely remove the vulnerabilities; the updates merely provide more resilience to sustain operations during a flooding attack
Het lijkt er op dat de wijze heren rond de tafel moeten om hier een structurele oplossing voor te verzinnen in het TCP/IP protocol.
Misschien een mooi gelegenheid om het te combineren met IPv6.
Ergens denk ik dat MS het stiekem wel een goed idee vind dat XP zo totaal ongeschikt gemaakt wordt voor server-achtige doeleinden. 't is wel nooit zo bedoeld, maar we weten allemaal hoe duur een server editie van Windows is, en dat veel bedrijven truuks bedenken om daar onderuit te komen.
Microsoft weet marketing technisch altijd een slaatje te slaan uit beperkingen van oude MS systemen.
Dat komt omdat ze de leken in de wereld hebben doen laten geloven dat er maar 1 computersysteem is. Vroeger was het: NU WEL EEN MULTI TASKING besturingssysteem (terwijl de concurrentie er al lang een had) en de hele horde stapte over. Nu vrees ik dat het gaat worden: NU WEL EEN VEILIG besturingssysteem en de hele horde stapt over op windows7, want het oude besturingssysteem is bagger. Dat er al lang andere veilige systemen bestaan is de horde onbekend.
M.a.w. Microsoft´s strategie is er op gericht om mensen 'dom te houden' en indien nodig (als men twijfelt) te voeden met angst en onzekerheid.
Een ander probleem is dat journalisten, ook van gerenommeerde media, lang niet altijd door hebben dat ze voor een karretje worden gespannen. Journalisten die geen wederhoor toepassen zijn hier extra kwetsbaar voor
De onduidelijkheid over dit lek neemt zo alleen maar toe. Het feit dat een standaard firewall setting het probleem voorkomt lijkt me niet echt een oplossing voor het defecte tcp/ip protocol.
Ik vraag me bijvoorbeeld ook af of de IPv6 ondersteuning ditzelfde probleem heeft.
Ook het nog onduidelijke status van Linux waar het volgens de kwetsbaarheden lijst niet voorkomt bij recente builds, maar waar nergens te vinden is dat er daadwerkelijk iets aan gedaan is, maar het raadsel groter.
Of Apple er last van heeft/had is ook al onduidelijk, aangezien er een gebrek aan info is op dat gebied.
Kortom, nog heel wat uit te zoeken hier.
IPv6 heeft hier mogelijk nog veel meer last van omdat die verbindingen wat complexer zijn om op te zetten. Verder verschillen de IPv6-stacks die ik gezien heb niet zoveel van IPv4 op dit vlak.
Ik denk ook niet dat IPv6 het probleem gaat oplossen. Of het meer of minder last zou ondervinden kan ik niet overzien.
Ik heb zelf de indruk dat TCP/IP hierop structureel aangepast moet worden. Op het moment dat een structurele oplossing noodzakelijk is, lijkt me dat een mooi moment om ook eens te kijken naar het upgraden van het adresbereik.
Je moet dan tenslotte toch alle servers upgraden voor deze problemen.
Maar laat ik eerlijk zijn. Ik ben een ontwikkelaar van bedrijfssoftware, ik maak gebruik van netwerkprotocollen, maar de diepe interne werking daarvan is voor mij ver onder de motorkap. :)
SED:
Ook het [sic] nog onduidelijke status van Linux waar het volgens de kwetsbaarheden lijst niet voorkomt bij recente build, ...
...
Of Apple er last van heeft/had is ook al onduidelijk, ...
Het probleem is implementatie specifiek, zoals in [url=http://www.govcert.nl/download.html?f=144]the factsheet[/url] staat beschreven dat je kon vinden via het originele artikel:
Op 8 september 2009 brengt een aantal soft- en hardwareleveranciers patches uit voor een serie van kwetsbaarheden, ontstaan door implementatiefouten, ...
Lijkt me niet dat Linux en Apple dezelfde TCP/IP stack hebben als Windows.
als je het artikel en de factsheet leest dan kom je toch wat meer info tegen die niet wijs top Windows specifieke implementatiefouten zoals jij lijkt te suggereren.
Het feit dat Red had aangeeft dat zijn Enterprise linux wel kwetsbaar is geeft aan dat de implementatiefouten breder gezien moeten worden.
Aangezien veel leveranciers hun huiswerk nog moeten doen ( o.a Apple?, neem maar aan dat ze het benadrukken als ze onkwetsbaar zouden zijn en anders zijn er legio fans die dat al lang gedaan hadden)
Dus nog veel onduidelijkheid en die factsheet maakt niets duidelijker.
Ps, lees jezelf wat verder in over het lek o.a op de blogs van Outpost24, dan merk je dat het behoorlijk diep zit
Aangezien veel leveranciers hun huiswerk nog moeten doen ...
De titel van dit artikel stelt dat MS haar nieuwe huiswerk niet wil doen!
En haar huiswerk blijkbaar in het verleden slecht gemaakt had.
Dus nog veel onduidelijkheid en die factsheet maakt niets duidelijker.
De factsheet is heel duidelijk, doch compact.
Als de bewering van Microsoft klopt dat het een probleem in het TCP/IP protocol betreft dan kunnen ze er weinig aan doen. Anders zouden ze afwijken van de standaard en dan heb je de poppen helemaal aan het dansen. Zolang 2000 & XP niet kwetsbaar zijn voor CVE-2009-1925 (remote code execution) zie ik verder het probleem niet zo met deze beslissing.
Waarom kunnen ze het lek dan wel dichten in Vista en WIndows 7.
Je hoeft niet van een protocol af te wijken om een lek te dichten wat daardoor ontstaat. Het is wat je ermee doet nadat het pakketje binnen is.
Microsoft geeft zelf aan dat ze de aanval in Windows Server 2003 en 2008 niet helemaal kunnen afvangen. Dat zou je toch aan het denken moeten zetten. Ik denk toch dat ze hun uiterste best zouden doen om in elk geval de server software dicht te krijgen. Het feit dat dat niet 100% lukt, maakt duidelijk dat het probleem erg lastig is.
Ook van Apple en Linux heb ik niet 100% duidelijk of het probleem is opgelost. Bijvoorbeeld Red Hat geeft nog steeds een houtje touwtje oplossing voor CVE-2008-4609.
Als je wil Windows bashen, dan moet je wel zeker zijn dat je eigen os het echt beter doet.
De problemen die beschreven worden in de CVE's lijken mij persoonlijk lastig op te vangen. Het zou me niet erg verbazen als dit nog een poosje blijft doorzeuren tot er een structurele oplossing verzonnen wordt.
Werkt NIST die lijst eigenlijk bij wanneer er nieuwe releases van OS'en uitkomen nadat een CVE in de lijst is beland?
Daar heb ik heb eerder naar gekeken. De eerste versie van de NVD-lijst is van 20-10-2008, ruim na de introductie van linux-kernel 2.6.25 in april 2008. Het is geen hard bewijs, maar zelfs als de lijst alleen de kwetsbaarheid van kernels op het eerste moment van publicatie aangeeft, dan lijkt het er op dat met 2.6.25 er iets is gebeurd waardoor die kernel niet in de lijst werd opgenomen.
De changelog van 2.6.25 vertelt van alles, maar ik kan niet beoordelen of de genoemde wijzigingen iets te maken hebben met het lek.
Als de bewering van Microsoft klopt dat het een probleem in het TCP/IP protocol betreft dan kunnen ze er weinig aan doen.
Dat ben ik met je eens. En ik heb zelf het gevoel dat Microsoft hier best een punt heeft.
Anders zouden ze afwijken van de standaard en dan heb je de poppen helemaal aan het dansen.
En terecht. Een Windows only TCP/IP zit denk ik echt niemand op te wachten. Net zo min als op een Apple, Linux of Google versie trouwens.
Als de wereld nu eens weigert om nog verder die microsoft troep te kopen dan gaan ze misschien eens naar hun klanten luisteren. Maar dat laatste zal een utopie zijn.
Iets verkopen om je vervolgens iets nieuws te laten kopen omdat het oude product toch defecten heeft. Om je vervolgens weer een nieuwe versie te laten kopen omdat de oude nieuwe versie ook weer een defect heeft.
Yeah right.
Wij noemen dit oplichting in normaal Nederlands. En degene die het toch kopen noemen we ....... (vul zelf maar in).
Nu kan dat allemaal wel normaal zijn in software land, maar er zijn grenzen. Een ervan is als je weigert een defect op te lossen in een bestaande versie die nog wordt verkocht.
Je lult nu toch?
Apple en Linux zijn er misschien ook gevoelig voor?
Er is verder nauwelijks iets bekend over het problem en iedereen zit maar te speculeren hier.
Windows 2000 kan ik me iets bij voorstellen, maar windows xp wordt nog gewoon verkocht. Er bestaat ook nog zoiets als verantwoordelijkheid.
Windows XP wordt niet als server gebruikt? Je zal nog versteld staan. Alleen al het pakket XP Unlimited die jouw XP-machine in 3 muisklikken omtovert in een terminal server.
En dat is nou precies de crux. Windows XP is niet geschikt om als server te draaien. Doe je dat wel, is het je eigen fout, schuld, probleem e.d. als je daardoor problemen hebt. Wil je toch een server draaien, dan koop je de goede licenties. Wil je dat niet? Dan ga je linux/unix draaien. Als jij in een dieselauto op slaolie gaat rijden omdat het kan, zul je ook geen garantie krijgen mocht er daardoor iets niet werken.
@Doubleday 19:51
Windows XP wordt niet als server gebruikt?
Ik denk niet dat XP veel gebruikt wordt in professionele netwerk opstellingen.
Ik ben overigens wel met je eens dat Microsoft haar uiterste best moet doen om een oplossing te vinden.
Ik denk niet dat XP veel gebruikt wordt in professionele netwerk opstellingen.
Jawel hoor, XP is heel populair in VMware VDI oplossingen. Scheelt enorm veel beheer vergeleken met terminal servers.
Ik dacht dat daarbij een desktop werd gevirtualiseerd vanuit een server. De server zelf (de host) draait dan toch geen XP?
Op de server zelf draait een hypervisor b.v. VMware ESX.
Op het SAN staat een golden template (file) van een XP installatie.
In het kort komt het er simpel gezegd op neer dat, als een gebruiker achter b.v. een thinclient gaat zitten, er een RDP sessie wordt opgestart met een virtuele XP desktop welke op de ESX server draait.
Deze virtuele XP desktop wordt __on the fly__ gekloont van de template en vervolgens opgestart.
De gebruiker ervaart geen enkele delay bij het inloggen omdat er natuurlijk een pool van virtuele XP machines standby staat. De virtuele XP wordt weer weggegooid als de gebruiker uitlogt. Natuurlijk zijn er ook permanente sessies mogelijk, maar dat is beheermatig niet zo handig.
Het enige wat dus beheer vergt (naast een windows 2003 server om sessies toe te kunnen wijzen) is een XP desktop en dat kan elke boerenpummel uitvoeren (template -> vm (software aanpassen) -> template.
Deze technologie heeft Citrix/windows terminal server concept met de dure inhuur consultants obsolete gemaakt.
M.b.v. geheugen trucjes van VMware en data deduplicatie kan je op een 4 quad core server met 32G geheugen wel 125 XP virtuele machines kwijt. Vergelijk dat eens met een Windows/Citrix terminal server waar max 25 gebruikers kunnen werken en dan nog is 1 gebruiker in staat om de hele server op te hangen. Windows is namelijk niet ontworpen als multiuser systeem. Citrix heeft dit pas later toegevoegd.
Het bovenstaande VDI concept werkt omdat dit vertaalt kan worden als 125 Citrix servers met 1 gebruiker. Een citrix server met 1 gebruiker zit geen andere gebruikers in de weg! In tegenstelling tot windows heeft de hypervisor blijkbaar wel een goed preemptive multitasking ontwerp om een eerlijke verdeling van de tijd te kunnen realiseren. Sommigen zeggen dat je dit met powerfuse onder windows goed kan regelen, maar dat is niet waar powerfuse verlaagt alleen de prioriteit van bepaalde processen. Er zit te veel troep (blocking functies in kernel mode) in de windows kernel. Windows NT zou ooit met een microkernel uitgerust worden. Dit is nooit gebeurd . Ze zijn nooit verder gekomen dan de 'hardware abstraction layer.
Als je toch met een terminal server concept aan de gang wil, gebruik dan een linux terminal server (wel een goede time sharing implementatie) en gebruik voor de windows only applicaties een seamless window (met het juiste thema natuurlijk) naar een virtuele windows desktop eventueel aangevuld met een gestreamde virtuele applicatie om de XP template lekker klein te houden.
Dus toch... bewaren die XP licenties, want VDI is een veelbelovend concept.
Nu ik dit zo opgeschreven heb, snap ik waarom VMware een groot probleem is voor Microsoft. Als ze in dit concept ook nog Linux desktops kunnen aanbieden wordt het helemaal een feest. VMware heeft zich hier nog niet over uitgesproken.
Wie dit wel heeft gedaan is Redhat. Zij komen dit jaar nog met een nieuw concept (spice protocol)
PS ik heb geen enkele binding met vmware
Hup allemaal upgraden naar Windows 7
Upgraden van Vista naar Windows 7 kan 20 uur duren
Nice downtime, vooral voor grote bedrijven, lmao.
Dit is voor grote bedrijven niet van toepassing hoor. Ik heb (in een testopstelling) in +/- 40 minuten per werkplek de werkplekk geupgrade van Windows Vista naar Windows 7, met behoud van gegevens door middels van System Center Configuration Manager. Dat het 20 uur kan duren zal wel bij bepaalde configuraties zijn.
Ik heb (in een testopstelling) in +/- 40 minuten per werkplek de werkplekk geupgrade van Windows Vista naar Windows 7.
Geloof ik niks van.
Dat zou twee keer sneller zijn dan MS deed op hun snelste systeem: 85 min
Zie tabel bron
Wie geen zin heeft om zo lang te wachten, kan beter een schone Windows 7-installatie overwegen. Die installatie zou slechts een halfuur tot drie kwartier kosten, zelfs op een relatief trage machine, zo blijkt uit de testresultaten.
;)
Aanvulling: zelfs bij enterprise upgrades is een verse install vaak aan te raden. Het saneren van soms lange tijd ongebruikte software is daarmee een goede aanleiding en zorgt voor een hoop minder onderhoud aan ongebruikte software. Uit ervaring blijkt dat er nogal wat onzinnige software jaren lang met images mee verhuist naar nieuwe machines. Opruimen is dan een prima stap en een verse install zorgt dan voor dubbele winst.
Die [schone] installatie zou slechts een halfuur tot drie kwartier kosten.
Dan heb je een kaal OS zonder programma's, wat heb je daar aan?
Een halve oplossing, is geen oplossing.
Ik gok dat SED bedoelt dat iemand dat eenmalig gaat inrichten. Dat mag een paar weken duren. Vervolgens trekt je daar een image van. En ben je weer even klaar tot de volgende release waar je weer je basis software gaat evalueren.
In die situatie is het natuurlijk meer de imaging software die bepaald hoe lang de installatie duurt. Over het algemeen zal dat korter zijn dan een upgrade of schone install.
Dit is denk ik vooral interessant voor de grotere toko's.
http://microsoftblog.globalknowledge.com/2009/08/20/perform-a-rapid-rollout-of-windows-7-using-windows-deployment-services/
of klik hier bijv..
system deployment blog:
BLOG
Vertel dat maar eens aan bedrijven die geen downtime kunnen veroorloven.
En wat moet een bedrijf met allemaal onzinnige software dan? hebben ze er nooit over nagedacht wat zinvol is en nutteloos?
wat denk je zelf?
Software schaft men aan en gebruikt men een tijdlang. Soms komt er een update en soms vervangt men het met ""nog even"" behouden van de oude software die vervolgens jaar na jaar meelift in de image. Dat is zinloze software geworden die je moet saneren. Daar is een migratiepad altijd goed voor. Ook om de noodzakelijke updates nu eens door te zetten door het gehele netwerk. Opruimacties doen het altijd goed. Grote opslag is gelijk aan veel troep.
Soms komt er een update en soms vervangt men het met ""nog even"" behouden van de oude software die vervolgens jaar na jaar meelift in de image. Dat is zinloze software geworden die je moet saneren. Daar is een migratiepad altijd goed voor.
Is het niet makkelijker om de onnodige applicatie te un-installen i.p.v. een hele image opnieuw te maken?
De informatie in de link over de duur van upgrades van Vista naar Windows 7 is irrelevant voor bedrijven waar de userdata op niet op de C schijf maar op een netwerk share staat.
Dat is juist in de meeste gevallen niet de situatie.
Veel die schrijven toch nog veel naar hun lokale schijf.
Ik vraag mij wel af wat Microsoft dan ineens met alle data doet?
In elk fatsoenlijk netwerk heeft een gebruiker bijna niets lokaal staan. Richt jij dat anders in?
Overigens is die genoemde 20 uur een extreem geval met uitzonderlijke zaken zoals een erg groot profiel ( wat je normaal ook beperkt en verwijst naar een netwerk drive)
Maar het blijft ook dan veel.
Overigens is die genoemde 20 uur een extreem geval met uitzonderlijke zaken zoals een erg groot profiel.
20 uur lijkt me ook slechts voorkomen in extreme situaties.
Laten we de medium gebruiker nemen, en middelen over de systemen.
Medium user - Low-end
32bit: 175 min
Medium user - Mid-end
64bit: 185 min32bit: 115 min
Medium user - High-end
64bit: 95 min32bit: 100 min
64bit: 85 min
Geeft gemiddeld 125 minuten installatie tijd.
Ik vond zijn vragen eigenlijk best wel aardig. In de praktijk zie je natuurlijk dat er veel open source software veel veiliger/beter is dan veel closed source, maar om nu te zeggen dat dat per definitie zo is, vind ik ook niet te beantwoorden.
Wat is beter? Heel veel betrokken ontwikkelaars die de open sources kunnen bekijken en de gaten kunnen dichten voordat de hackers die ook mee kijken hier gebruik van kunnen maken of weinig ontwikkelaars die gaten kunnen dichten terwijl hackers niet mee kunnen kijken.
Ik denk dat veel afhangt van het gevolgde ontwikkelmodel, de kwaliteit van de programmeurs en dat openheid altijd wint.
Uit ervaring weet ik dat open source ontwikkelaars veel gepassioneerde zijn dat closed source ontwikkelaars waar ik ooit een van was. Maar meer kwaliteit zou ik ook niet durven te zeggen.
Om te kunnen reageren, dient u ingelogd te zijn.
2 jaar geleden: 13 februari 2010
3 jaar geleden: 13 februari 2009
4 jaar geleden: 13 februari 2008
5 jaar geleden: 13 februari 2007
14 jaar geleden: 13 februari 1998
IDG Nederland is uitgever van: AppFish
, CIO, Computer!Totaal, Computerworld, ITworld, Jobworld, MacWorld, RAW fotomagazine, TechFish, Tips & Trucs, Webwereld en Zoom.nlMeer informatie: IDG Nederland, IDG.com, Privacy-statement, Cookie-statement Hosting by Terremark.
