Názory k článku
Microsoft tvrdí, že 40 procent virtuálů v Azure běží na Linuxu
-
Tomu sa nedivim, aj nasi vyvojari placu, ze by boli radi, keby ten nas software behal na Linuxoch, pretoze virtualy s Linuxami su tak super flexibilne, lacne a dobre sa spravuju. Ale trepu si hlavu o stenu, pretoze historicky sa drzali zhnitych Microsoftnych technologii, frameworkov a ineho hnusu a teraz nie je casovo mozne ten software ocistit a usposobit behu na Linuxe. Nehovoriac o tom, ze velka vacsina z nich su doslova trilobiti, ktori ziju vo svete widlich frameworkov aj 2 desatrocia v kuse a nie je mozne, aby vystupili zo svojej krabicky a pochopili ako treba aplikaciu zmenit, aby na Linuxe bezala spolahlivo a rozumne rychlo.
Druha vec je, ci by ten Linuxovy virtual este bol rychly a stabilny, keby sa nanho nas software nasadil sposobom, ktorym sa nasadzuje na windows. Dost sa obavam toho, ze ani trocha.
-
S BSOD uz to nie je tak horuce, su stroje, ktore hodia BSOD len vynimocne, aj ked moja osobna skusenost je, ze u 7cky to bolo lokalne minimum a 10tka je na tom trocha horsie. Ale mame v robote kolegov, ktorym 7cka padala, 10tka nepada alebo naopak 7cka nepadala a 10tka pada. Istu cast ma na svedomi HW (hlavne smejdove RAMky) u inych je to nevysvetlitelne, pretoze ani intenzivne testovanie roznymi memtestami problemy nehlasi.
Ja skor hovorim o tom, ze samotny deployment aplikacie castokrat vyzera ako keby hnali svine po navsi. A to sa jeden moze stabilitou aj pokrajat, ked bude aplikacia v rovine mentalneho potratu, poriadne to fungovat nebude nikdy.
-
Ano, za castou. Hodne malou a typicky sa po nejakej nie velmi dlhej dobe ukaze, ze RAM je vadna, pretoze pocitac nie ze nahodne hadze BSOD, ale pada pri vacsej zatazi. Na nasich strojoch v pripade vadnej RAM alebo MB (zdroje sa u nas kupuju drahsie a overene, pretoze nic nenastve viac ako odstavena masina kvoli usetrenym 1000 korunam na zdroji, takze ich zavady su zriedkave) typicky pada kompilacia bud padom VS alebo castejsie padom celeho systemu, alebo je mozne problem odhalit pustenim memtestu.
A nikto ma nepresvedci, ze necertifikovany driver pre zvukovu kartu moze za to, ze z casu na cas VS ignoruje breakpointy, nahodne sebou sekne (to mi je celkom jasne, preco sa to deje, kedze VS je siroko daleko jedine 32bitove vyvojove prostredie a nas projekt je velky), alebo za to, ze pri boote masiny pomerne casto vidavam dva kurzory mysi namiesto jedneho. A to mam stastie, pretoze kym som mal na stroji 7cku som videl BSOD raz pri upgrade NVidiackeho drivera, kde to bola znama chyba a s 10tkou som ho zatial videl asi len 5x. Mam kolegov, ktori na podobnom alebo identickom a rovnako starom HW vidia BSOD kludne aj denne. A nejako nie som presvedceny o tom, ze by rozptyl kvality drahych PC komponentov bol tak velky.
Zvysok (majoritu) by som pripisal (ne)kvalite SW potazmo OS samotneho.
-
Pokud vidíte dva kurzory myši místo jednoho, tak to sice v principu může být driverem zvukové karty, ale spíš bych se díval po driverech HID zařízení, třeba touchpadu. BSOD při upgradu video driveru jsem ještě neměl; mimochodem viděl jste někdy upgrade video driveru na X11 serveru za provozu? :) BTW při pádu aplikace i celého OS můžete vygenerovat dump, a předpokládám že s debuggerem si rozumíte.
A jako vždycky může být nejen lépe, ale i hůře. Tohle je myslím dost poučné.
https://lwn.net/Articles/304105/
https://communities.intel.com/thread/96168
https://thenextweb.com/insider/2016/02/01/running-a-single-delete-command-can-permanently-brick-laptops-from-inside-linux/ -
Mimo standardnej usb klavesnice a standardnej usb mysi ten pocitac (desktop) ziadne ine HID zariadenie v tej dobe nemal (teraz mam, ale na chovani to nic nezmenilo). Oboje pouzivaju genericky driver od Microsoftu (koniec koncov co ine obycajnej PCdlovej klavesnici a obycajnej trojtlacidlovej mysi s koleckom ostava, zeano). Graficka karta poziva WHQL signed driver priamo od NVidie, jednu dobu tusim 7cky zvladali ten driver dodat same. Ale kludne mozeme occamovu britvu ignorovat aj dalej, mate este nejaky napad na nepravdepodobneho 3rd party vinnika 99% padov a abnormalneho chovania Windowsu?
To BSOD pri upgrade drivera neriesim, to bolo uznane ako chyba na strane NVidie (a bol to stabilne plosny problem snad na kazdom jednom PC s tou kombinaciou HW a SW) aj s podanim opatreni a uvedenim rozsahu skod (ziadne, dalsi reboot to dal do poriadku). Btw BSOD to nehodilo za behu, ale pocas updatovacieho rebootu (ten update sa instaloval spolu s dalsimi a WUPD si vyziadal reboot, po reboote nasledovala modra smrt a dalsi reboot uz bol ok).
Samozrejme, ze keby som velmi chcel, tak by som mohol debugovat ci uz visualko, alebo kernel. V pripade visual studia to nemam zapotreby, je mi jasne, ze gro padov mi sposobuje vycerpanie 32bitoveho adresneho priestoru, kedze Microsoft vytrvale nie je schopny alebo ochotny z VS urobit 64 bitovu aplikaciu ale namiesto toho ludi presviedcaju o tom, ze ak pamatovy priestor nechaju vyzrat, su blbi. Beztak nemam potrebu to debugovat, nie som za to plateny.
-
Na prvním místě by to asi chtělo toho 3rd party viníka vyloučit. Typicky se vyplatí pomocí utility autoruns ověřit ne-ME drivery a servisy, zvláště nepodepsané, a případně je odstranit. Po BSOD můžete triviálně natáhnout dump do windbg a napsat "!analyze -v", což vám řekne bugcheck code plus ve kterém modulu došlo k havárce. Přijde mi dost tristní, když vývojář neví jak provést troubleshooting BSOD, nebo když řekne "to bude asi nejspíš OS, a stejně nejsem placený za to, abych se tím zabýval".
-
Tristne to samozrejme nie je. Keby som sustruznik a sustruh mi nahodne vyhadzuje nastroj z upinacej hlavy, tak to budem budto ignorovat, ak to nebude ohrozovat bezpecnost alebo spomalovat moju pracu, zavolam na to opravara, alebo sustruh vymenim za novy, alebo sustruh uplne ineho vyrobcu. V ziadnom pripade ho nebudem rozoberat a diagnostikovat. Viem o sustruhu prilis malo na to, aby sa vyplatilo plytvat mojim casom na jeho diagnostiku, potazmo opravu, ked clovek, ktory je na to skoleny to zvladne rychlejsie a v konecnom dosledku aj lacnejsie.
V mojom pripade (suhrnne cca 6 BSOD za necele 4 roky co tuto masinu mam) mi nepride efektivne vynakladat cas na post-mortem analyzu BSOD alebo toho, preco mam obcas po boote dva mysie kurzory. Som proste zvyknuty na to, ze system pracuje stabilne kludne s uptime radovo mesiacov. Ked bol problem na inych strojoch invazivny (masina zarucene spadla, ak sa urobil full rebuild release branche / zaujimave ze pri full rebuild debugu to nespravilo), tak sa na to postval memtest a vypadli z toho vadne RAMky, na inej masine zasa bola diagnostikovana vadna doska.
Doma samozrejme ziadne instalacie Windowsu neprevadzkujem, takze s BSOD ani ich post-mortem analyzou problem nemam. Sucasnu nestabilitu mojho laptopu pripisujem zlyhavajucemu 9 rocnemu HW, kedze povaha chyby je uplne absurdna a pocetnost vyskytov sa dost rapidne zvysuje.
-
nobody (neregistrovaný)
OS kde driver zvukove karty v principu muze za zobrazeni dvou kurzoru je slusne smecko ;)
mimochodem viděl jste někdy upgrade video driveru na X11 serveru za provozu? :)
videl sem to mnohokrat, provede se upgrade pri jehoz cinosti nemam zatizene CPU a muzu normlane pracovat, nemusim restartovat po jeho dokonceni, az se rozhodnu restartovat trva to par vterin, nemusim cekat jednotky az desitky minut na "dokonceni aktualizace", nekoukam na nehejbajici se % prubehu z ktereho nic neni poznat, necekam pak pri zapinani na "dokonceni aktualizace", proste to funguje normalne... nebo co tou otazkou chtel sasek z PR oddeleni Microsoftu rict? -
Driver zvukové karty je kernelový modul, a i "odborník" s vaší mírou (ne)znalostí by mohl vědět, že kernelový modul může v principu provádět spoustu věcí, včetně manipulace se zařízeními a soubory.
Takže jinými slovy upgrade video driveru na X11 serveru za provozu neuděláte. Ve Windows je možné vyměnit video driver za chodu, a běžně se to dělá. Světe div se, aplikace fungují dál. Klauna s Tuxem na klopě to sice může překvapit, ale to jen protože dotyčný klaun je nedouk.
-
nobody (neregistrovaný)
dost chabe, kernelovy modul zvukoveho subsystemu nema co delat s kurzorem na obrazovce ;-)
bud prekrucujes co si psal, nebo se nauc vyjadrovat, upgrade driveru a inicializace/nahrazeni_beziciho driveru jsou 2 rozdline veci...
tak jasne Windows jsou tak "genialni" ze dokazi vymenit video driver (tedy samozrejme za splneni hromady podminek) za chodu, ale nedokazou za chodu vymenit stovky dalsich veci kvuli kterejm je pri WindowsUpdate v 3/4 pripadu vyzadovan restart, nasledne se pri restartuje zdlouhave dokoncuje instalace protoze Windows ji nedokazali udelat za chodu, nasledne se pri zapinani zdlouhave provadi dokoncovani dokoncovani instalace, protoze Windows ji nedokazali udelat za chodu, ani pri predchozim dokoncoveni pri zdlouhavem predchozim restartu...
no ale co cekat od saska z PR oddeleni Microsoftu, bude dat lhat a prekrucovat protoze to ma v popisu prace, to ze pusobi jako chudak je mu jedno, staci ze za hyenismus ma spinave prachy ;-) -
Přezdívka (neregistrovaný)
"Necertifikovaný HW" je absolutně irelevantní a nicneříkající buzzword, protože mám mnohonásobnou (nejen) osobní zkušenost s tím, že MS WHQL dají bez jakýchkoliv problémů certifikaci prakticky jakémukoliv binárnímu svinstvu, takže "nepředvidatelný výskyt BSoD, který začal hned po instalaci nebo aktualizaci WHQL certifikovaného driveru" není ani náhodou nic neobvyklého.
-
No nase stroje nie su zrovna low-cost, pohybuju sa v hornej stvrtine cenoveho spektra (aj to len preto, ze pouzivame vylucne low power graficke karty, ktore nepotrebuju vetrak a to vo vseobecnosti vela nestoji). Jediny sposob ako za pocitace s obdobnou HW konfiguraciou dat viac penazi by bolo kupit si nejaku znackovu pracovnu stanicu. Navyse ja vacsinou Linux prevadzkujem na strojoch s vekom blizkym 10 rokov roznej nadobudacej ceny za nova (od lowendoveho laptopu ASUS s desktopovym procesorom AMD, ktory stal novy snad 15 000 SK az po MacBook Pro, ktory mohol ako novy stat niekde medzi 2 a 3 tisic dolarov) a nikdy som problem s nahodnymi padmi systemu ako celku nemal bez toho aby sa velmi kratko po tom ukazala nejaka zavada na HW samotnom. Tento mytus o tom, ze Windows je dokonale stabilny system a jeho pady sposobuje nekvalitny hardware by som celkom s kludom zavrhol. Svoje o tom hovori aj pocet a povaha bezpecnostnych dier, ktora pojde ruku v ruke s poctom a povahou programatorskych chyb veducich k nestabilite a nakoniec aj padu systemu.
