Názory k článku Source Mage GNU/Linux: časové znamení ohlásilo ...

Moc pěkný článek, ale na pár místech chybějí horní indexy, takže 231=2^31, 230=2^30. Asi chyba vzniklá při copy & paste.

Teda opravit chybu tim, ze misto long dam long long je pekne hnusne a hned na zacatku je napsane, ze je to blbost a ze by melo byt pouzite time_t. Bylo by asi dost vhodne se nad tim zamyslet a pouzivat takove datove typy, ktere se pouzivat maji a ne ty, ktere nahodou svym rozsahem taky funguji.

Ale pokud jste dobre cetl, tak by Vam to stejne nepomohlo, protoze ta velikost typu se s time_t kryje. Potrebuje vetsi datovy typ.

Mozna placam, ale domnivam se, ze MOJE :) mel na mysli spis to, co se pise na zacatku clanku - kdyby byl v minulosti (teoreticky) pouzit vyhradne time_t a ten upraven na 64 bit, tak by se "jednoduchym" znovuprelozenim zdrojaku dala tahle w2.038k patalie napravit. U long uz je potreba mechanicky prepsat postizene deklarace.

"Každý den se tak číslo na unixových hodinách zvýší o 86400 (1 den x 24 hodin x 60 minut x 60 sekund)."

Tak na tohle jsem se tuhle taky spolehnul, ale prestupny dny s 23 ci 25 hodinama mou aplikaci tvrde potrestali. Tak pozor.

A to jeste neuvazujete prestupnou sekundu, ktera se nekdy vklada. Dalsi info (cesky): http://home.zcu.cz/~poupa/sec.html#prestupna

Je vidět, že jste si ještě žádný pořádný průser nevykoledoval. Kdybyste si cvičně zhroutil billingovou databázi, jako já, tak už by vás nikdy v životě ani nenapadlo nad nějakými přestupnými sekundami přemýšlet! At si země mění svoji oběžnou rychlost jak chce! To že se najednou začne signál z radiohodin o sekundu rozcházet není nic závažného, "adjtimex" to časem srovná. Důležitější je zajistit, aby žádná následná událost "časově nepředběhla" událost předchozí!

Ale jinak jsme tady trochu off topic.

Dokud používáme čas s rozlišením na sekundy, tak přestupné sekundy moc nevadí. Ale u systémů reálného času pracujících časovými kvanty např. desítek milisekund, tam už to mi to před léty docela dalo zabrat. Asi tak, jako když při přechodu z letního času se jedna hodina zopakuje 2x a všechny události by se najednou měly zopakovat. Naštěstí dnes zatím (asi) nikdo v databázích čas pod jednu sekundu nepotřebuje a přestupná sekunda nastala naposledy před pěti lety. Ale blíží se to (viz obr. na http://hpiers.obspm.fr/eop-pc/earthor/utc/leapsecond.html).
Takže zatím můžeme klidně spát....

...a detailista, ale vazne si nedokazu predstavit jednoucelove zarizeni, ktere by melo "velkou sanci" fungovat jeste v roce 2038. Asi mam malo bujnou fantazii. :-) Nebyl by nejaky nazorny priklad, abych neumrel uplne hloupy? Dik!

Zarizeni mozna ne, ale soft z toho zarizeni muze byt klidne pouzity v jinem. Soft se nepise pokazde od nuly, casto se jen tuhle prilepi nove vlastnosti, tuhle se neco opravi, pripadne cast jednoho softu se pouzije v jinem a hle mame "novy" soft. Timhle zpusobem muzou dnesni chyby prezivat veky.

Pokud bych si třeba instaloval topení s regulačním systémem, tak proč ne? Nebo různá jiná zabudovaná zařízení.

Zdravim

A nebylo by treba vsechny deklarace casovych promennych prepsat na time_t a tu nalezite upravit na 64bit? Kdyz uz se to musi cely projit nebylo by to lepsi udelat poradne nez nejakou hroznou oberlicku s long long ?

Jeste ze pouzivam Slackware a BSD-init :-)

Zdenek

Ano, deklarace vsech casovych promennych by mely byt prepsany na time_t. V linuxovych distribucich se ale nachazeji tisice ruznych aplikaci. Neni v silach vyvojaru distribuce prochazet zdrojove kody vsech aplikaci.

Pouziti long long bylo pouze provizorni. Jednalo se o nejrychlejsi mozne reseni. Kratce pote byl do grimoire pridan opravdovy patch.

http://www.smee.org:8080/@md=d&cd=//&cdf=//sgl/devel/grimoire/smgl/simpleinit-msb/BUILD&c=T1I@//sgl/devel/grimoire/smgl/simpleinit-msb/BUILD?ac=22

Klíd, do roku 2038K = 2038000 je ještě dost času, ne? :)

Uz jsem se lekl, ze mam v clanku dalsi chybu (dekuji za horni indexy). Y2.038K mam nastesi s teckou. :-))

skanduji: "My chceme pokracovani serialu o Initu"......
:)