Diit.cz - Novinky a informace o hardware, software a internetu

Diskuse k Chyba v linuxovém jádře ovlivňuje práci s disketou

dobrá zajímavost.
ale napsat "chvíly", to je taky moc zajímavé ;-)

+1
0
-1
Je komentář přínosný?

A na to přesně je v článku odkaz "nahlásit chybu", protože takhle v komentáři to po opravení vypadá vytrženě. Měl jsem omylem ve větě dvakrát slovo "používaly" (což mi právě odkazem někdo hned nahlásil) a to jedno vymazání se mi povedlo opravdu kvalitně, posunuté o pár znaků doleva. Stane se, zvlášť z mobilu.

+1
+2
-1
Je komentář přínosný?

.... jojo LS-120 tu ještě někde mám zrala jak magnetoopticke 120MB diskety tak i klasické 3,5 palc. diskety a dokonce i o velikosti 2,88 MB. Mechanika se pripojovala už na IDE/PATA...

+1
+1
-1
Je komentář přínosný?

Po uvedené opravě nicméně s flagem i bez něj dochází v případě, že disketa není v mechanice nebo je chráněna proti zápisu, k vrácení chyby Read-only file system okamžitě.

to je příšerná věta.. jsem si jí musel přečíst 3x než jsem pochopil obsah.

+1
0
-1
Je komentář přínosný?

To vybizi k zajimave diskusi. Je to opravdu bug? A ne treba Fix? Protoze pred tim sla zavolat beztrestne funkce open i v pripade, ze v mechanice nebyla zadna disketa. A az po pristupu k ni uzivatel zjistil, ze tam nic neni. To, ze to ted vraci chybu hned pri pokusu ji "otevrit" me osobne prijde v poradku a spise predchozi stav vnimam jako chybny.

A ted otazka... Prestava byt bug bugem kdyz se s nim nauci vetsina zit? A pak nasledne, kdyz se objevi fix, ktery hazi vidle do toho jak se ta vetsina naucila s tim bugem zit, tak stane se pak ten fix bugem? Nebo vetsina ma smulu?

+1
+4
-1
Je komentář přínosný?

Tohle je dobrá otázka. Vzhledem k tomu, že flag O_NDELAY by měl způsobit, že volání open() nečeká na reálný výsledek a vždy končí s nulou (alespoň co jsem si tak prošel popisy funkce open() při psaní článku) a chyba se řeší jinak, pak bych původní chování označil za vlastnost a jeho změnu za bug. Ale vypadá to, že většina lidí zastává názor přesně opačný :)

+1
0
-1
Je komentář přínosný?

V dobre odokumentovanom kode (a v zdravom ekosysteme) typicky plati, ze:
1) ak je dokumentovane chovanie nejake a kod sa chova inac, je kod chybny a je to bug
2) ak sa chovanie kodu zmeni tak, aby bolo v sulade s dokumentaciou a nejaky program sa rozbije, potom tento program bol vadny, lebo zalezal na zjavne nedokumentovanom chovani
3) ak program zalezi na nejakom detaile chovania ineho kodu, ktore nie je zdokumentovane, tak taky kod exploituje API a zalezi na vnutornom chovani volaneho kodu
4) ak sa vnutorne chovanie volaneho kodu zmeni bez toho aby rozbilo dokumentovanu funkciu ale rozbije volajuci kod, ktory na tomto vnutornom chovani zalezi, potom je volajuci kod vadny, lebo zalezal na niecom, co vobec nemal riesit
5) ak sa chovanie zmeni tak, ze kod sa prestane chovat v sulade s dokumentaciou, tak sa jedna o zanesenie bugu a nie opravu
6) v takom pripade je mozne zmenit dokumentaciu API, resp. API samotne, ak je zmena nevyhnutna (dajme tomu, ak ste Microsoft a zistite, ze kvoli mizerne navrhnutemu poradiu loadovania DLL je podpora uzivatelskych symlinkov bezpecnostnym problemom). ale potom sa jedna o nekompatibilnu zmenu API a mala by byt odlisena verziou.

+1
+2
-1
Je komentář přínosný?

Tolik teorie, ale v praxi uživatelé za chybu považují tu změnu, která rozbila doposud fungující stav.
A pak jim vysvětlujte, že chyba byl ten předchozí stav (kdy jim to fungovalo dobře) a ten nový stav (kdy to mají rozbité) je oprava :-)

+1
0
-1
Je komentář přínosný?

Preto ten prvy riadok ;)

Kym niekomu nieco treba vysvetlovat, je to ok. Sranda nastane, ked sa jedna o korporatny entagled kod a niekto z pouzivatelov zacne opravu cez menezment, ktory o tom vie kulove, blokovat. Potom ma clovek v maile thread s jednym menezerom, ktory sa dozaduje opravy a druhy thread s druhym menezerom, ktory sa dozaduje, aby sa najlepsie nic nemenilo.

+1
0
-1
Je komentář přínosný?

Pokud to tak bylo před lety specifikováno, OS se podle toho choval a dnes to někdo změnil, aniž by ten úmysl byl nějak diskutován, tak je to chyba. Byť to nové chování může připadat někomu logičtější. A mám pocit, že i ve woknech nebo dosu se to chovalo podobně - systém zkusil na disketu zapsat a až pak dostal hlášku, že to nejde.

+1
0
-1
Je komentář přínosný?

„Protoze pred tim sla zavolat beztrestne funkce open i v pripade, ze v mechanice nebyla zadna disketa.“
Podle popisu soudím, že to byl právě záměr.
Tj. program mohl volat open předem a případnou chybu řešil až ve chvíli zápisu.

„A ted otazka... Prestava byt bug bugem kdyz se s nim nauci vetsina zit?“

Ona je ještě horší situace: Sice jde o chybu, ale daný produkt se už mezitím rozšířil a spousta jiných programů a uložených dat ne že se s tou chybou naučí žít, ale na takové chování spoléhá.
Takže oprava by naopak spoustu věcí rozbila.

+1
0
-1
Je komentář přínosný?

"Ona je ještě horší situace: Sice jde o chybu, ale daný produkt se už mezitím rozšířil a spousta jiných programů a uložených dat ne že se s tou chybou naučí žít, ale na takové chování spoléhá.
Takže oprava by naopak spoustu věcí rozbila."

to je prave to zda ma pak vetsina smulu :) Jinak jak pise klega vys, kdyz se zmenou uvnitr rozbije volajici kod nad tim, tak je to pak chyba koho?

+1
0
-1
Je komentář přínosný?

Prosim povedzte mi realne kto opuziva disketovu mechaniku a potrebuje aktulane jadro.

Ak je to nejaky priemyselny equipment co ma disketovku, tak tam sa urcite nemeni OS ale ostava ten co tam bol dodany.

+1
0
-1
Je komentář přínosný?

Proto taky trvalo tak dlouho než se na to přišlo a chyba se dostala i do LTS.

+1
0
-1
Je komentář přínosný?

Tam bylo i zajímavé mezidobí kolem přelomu století:
Diskety už byly mimo z hlediska objemů přenášených dat (i když ze setrvačnosti byly ještě široce podporované),
nástupci disket (Zip drive apod.) se moc nerozšířili a mechaniky byly drahé,
CD vypalovačky ještě nebyly tak rozšířené a byly drahé,
Internet se taky teprve rozšiřoval a připojení bylo pomalé.

Tehdy fungovaly věci jako šuplík na harddisk a přenášení disků (interních IDE, tehdejší počítače neměly žádný externí konektor, ke kterému by mělo smysl připojovat harddisk).
Technicky zdatnější (či chudší) uživatelé měli prostě odšroubovanou bočnici u PC a vyhozený Molex + IDE konektor ven :-)

+1
+3
-1
Je komentář přínosný?

A nebo upilovaný caplíky u 5 a 1/4 palcové záslepky, a za ní ten Molex s IDE. Ještě se na to sekunďákem lepil nějakej pinčlík, aby se to dalo snadno vytáhnout. Později přišli šuplíky, kde se dovnitř dal ten disk snadno připojit a zastrčit do bedny.

+1
0
-1
Je komentář přínosný?

Šuplíky přišly dost brzo, já ho měl asi v roce 1993. Ovšem jejich problém byl občas mizerné kontakty a hlavně vzájemná nekompatibilita. Pokud se přenášel disk, tak na druhé straně musel být šuplík od stejného výrobce. Pokud ne, tak to v tom lepším případě do sebe mechanicky nepasovalo. V tom horším se dal odpravit disk, protože propojovací konektor byl u všech typů stejný, ale jeho zapojení se lišilo. A 12V na IDE sběrnici nebylo moc zdravých...

+1
0
-1
Je komentář přínosný?

"nástupci disket (Zip drive apod.) se moc nerozšířili"

Tak ještě že u nás na fakultě měly všechny stroje ZIP mechaniku a já si ještě předtím prozíravě koupil stroj se ZIP mechanikou taky. :)

+1
0
-1
Je komentář přínosný?

Pozor, existovaly i pokročilé floppy disky v 3,5" formátu s kapacitou kolem 21MB - mamka je coby EEG laborantka používala ukládání pořízených EEG záznamů. Ten přístroj jel ve Zlínském špitále myslím až někdy do roku 2013-2015.

+1
0
-1
Je komentář přínosný?

Pro psaní komentářů se, prosím, přihlaste nebo registrujte.