Jaderné noviny – 15. 8. 2013: Y2038 na obzoru (diskuse)

[Josef Kufner]

Navrhuju zavést pie:// URI schéma, které bude adresovat polohu dat v π.

[pc2005]

ad Pí: No nevím, nepřipadá mě to jako dobrý nápad .

[ertwertwe]

autor pifs to samozrejme myslel jako vtip a proof of concept. cituji web: "proc skladovat stare normalni data, kdyz muzeme skladovat hafo metadat"

[jehovista]

No pak bysme si asi museli ukladat polohu v tom pi. A u netrivialniho souboru bych rekl, ze zapis te pozice bude delsi, nez samotny soubor.

[Sten]

Nebude. π je disjunktní a tedy statisticky bude zápis pozice průměrně přesně stejně dlouhý jako samotný soubor

[jehovista]

To recitujes poucku, nebo se to da i dokazat tak, aby to pochopil prumerny ctenar abicka?

[Sten]

π má statisticky náhodné rozložení číslic. To znamená, že v něm lze nalézt jakoukoliv sekvenci a že se stoupajícím počtem hledaných sekvencí bude průměrné místo nálezu hledané sekvence v půlce (jde o půlku nekonečně dlouhého čísla ). Možných kombinací obsahů souborů je nekonečně mnoho a mají rovnoměrné rozložení, tj. jsou také statisticky náhodné (pokud by nebyly, sbohem steganografie). Takže zapsat offset na náhodnou pozici v π zabere průměrně stejné množství dat jako ta samotná data, která tak ukládáme.

Mimochodem jde o stejný problém, proč komprimační algoritmy nemohou fungovat na všechny soubory a naopak u některých souborů způsobí zvětšení (opět to statisticky konverguje k tomu, že komprimovaná data budou stejně velká jako originální data, prostě ta entropie musí zůstat; důkaz viz †). Na malém množství podobných dat komprimační algoritmy fungují. Jenže fungují díky tomu, že hledají nadbytečná (neetropní) data, která ale určitě nejsou statisticky náhodná. U π, které je statisticky náhodné, budete mít i u těchto souborů stejnou pravděpodobnost, že zápis offsetu do π bude větší než samotná data, jako pravděpodobnost, že bude menší. Statisticky to opět bude konvergovat k tomu, že offsety budou stejně velká jako samotná data. Průměrně tedy místo neušetříte, ale ani neztratíte.

† důkaz, že komprimovaná data statisticky konvergují na stejnou délku jako původní data (on se totiž týká i toho π):

Do k bitů lze uložit 2ᵏ hodnot. Mějme tedy 2ᵏ různých souborů (poznámka: souborem rozumím libovolnou sekvenci dat) a zkusme je zkomprimovat. Komprimací rozumíme zachování nebo zmenšení velikosti souboru. Menších souborů je ale jen 2ᵏ⁻¹, tedy některé soubory zůstanou stejně velké. Teď budeme komprimovat 2ᵏ⁻¹ různých souborů obsahujících k-1 bitů a tak dále. Nakonec zkusíme komprimovat soubory s nula bity. Takový je právě jeden a nejde zmenšit. Tím pádem ale nejde zmenšit ani soubory o jednom bitu, protože by ty zmenšené nebylo možné odlišit od souboru s nula bity. A tak dále až po k. Tedy po úspěšné kompresi budou všechny soubory stejně velké.

[ebik]

Věří se, že pí má rovnoměrně rozložené číslice. Nikdo to nedokázal. Nedokázal ani, že pí je disjunktní číslo pro alespoň nějakou soustavu a opravdu obsahuje všechny konečné sekvence zapsané v té soustavě. Samozřejmě není ani důkaz, že tomu tak není.

[walkeer_CZ]

no, vzkledem k tomu, ze pi je transcendentni, tak je to mozna docela opravena vira, nebo jsem mimo?

[xyz]

Samo osebe to nestačí. Napríklad číslo \sum_{n=1}^\infty 10^{-n!} je transcendentné a pritom má má v zápise v desiatkovej sústave len jednotky (na "faktoriálových pozíciách") a nuly (všade inde).

[Sten]

To nestačí, ale všechny známé číslice jsou (alespoň zatím) statisticky náhodné

[jehovista]

Na jake hladine vyznamnosti? XD

[Michal Kubeček]

Ono i v případě, že je rozložení číslic opravdu náhodné, tak to není žádná výhra, protože by to sice na jedné straně znamenalo, že pro každou sekvenci pravděpodobnost, že se vyskytne v prvních n číslech zápisu, konverguje k nule, ale na druhé straně také to, že pro libovolné n existuje sekvence, pro niž platí, že zápis pozice jejího prvního výskytu bude aspoň n-krát delší než sekvence sama.

[Jendа]

Tato hodnota přeteče 19. června 2038

Na mém systému je to už o něco dřív. Že on mě Intel zase ošidil o setinu bitu?!

[Michy]

Ať dělám, co dělám, vychází mi přetečení na 19.1.2038.

date -d "@$((2*1024*1024*1024-1))"
Út led 19 04:14:07 CET 2038

Že by záměna anglického Jan/Jun?

[Sten]

Má to být 19. ledna 2038 (či 18. ledna pro ty, kteří žijí na západ od Labradoru)

[SGF]

A hergot, labradora má soused a my máme byt západně od něj...

[David Watzke]

Dík, opraveno

[Conscript89]

Ale v titulku clanku je porad srpen :)

[xkucf03]

On se hlavně ten problém objeví už ve chvíli, kdy bude někdo chtít vyjádřit čas za touto hranicí – ne až po tom, co tuto hranici překročí reálný čas. Jde o různé předplatné, pronájmy nebo události naplánované do budoucna… jasně většinou se to týká aplikačního softwaru a tam se můžou používat jiné datové typy. Ale obecně mi přijde zavádějící psát, že problém roku 2038 se nás týká až za 25 let.

[Michal Kubeček]

Osobně mne spíš překvapuje, že mnohem dříve nebyly komplikace s problémem roku 1901…

[Lol Phirae]

Tak tohle je z roku 2010, a skutečně to několik lidí reportovalo (asi je stejně jako mě nebaví furt obnovovat certifikáty.)

Changes between 0.9.8n and 1.0.0  [29 Mar 2010]

New function OPENSSL_gmtime_adj() to add a specific number of days and
seconds to a tm structure directly, instead of going through OS
specific date routines. This avoids any issues with OS routines such
as the year 2038 bug. New *_adj() functions for ASN1 time structures
and X509_time_adj_ex() to cover the extended range. The existing
X509_time_adj() is still usable and will no longer have any date issues.
[Steve Henson]

[jc]

IMHO se tady projevuje jedna z nevyhod soucasneho vyvoje linux kernelu. Kdyby byl nejaky "opravdu vyvojovy" strom jako puvodne, nemuseli by se bat rozbit ABI. Uzivatele / vyvojari software by pak vedeli, co je/bude treba k tomu, aby to fungovalo i s novou hlavni verzi.

[trekker.dk]

Rozbít ABI nebylo povolené nikdy.

[mankind_boost]

Základním pravidlem vývoje Linuxu je NIKDY NEROZBÍT KOMPATIBILITU USERSPACE. Kvůli tomu je v Linuxu naprosto neskutečné množství různých hacků a obežliček.

[Aleš Kapica]

Dokonce tolik, že se někdy něo rozbije, aniž by o tom vůbec někdo něco tušil..

[Sten]

Jak by mohl být nějaký „opravdový“ vývojový strom pro věci jako KDE či GNOME? Navíc ani samotný kernel už nemá „opravdový“ vývojový strom, používá distribuovaný Git. „Opravdový“ vývojový strom lze používat akorát u „hobby systémů“ jako OpenBSD.

[R]

Problem toho "skutocne vyvojoveho" stromu bol ten, ze skutocny vyvoj sa dial iba tam a stabilne verzie boli silne zastarane. Pritom boli vo vyvojovych jadrach nebezpecne bugy (sposobujuce poskodenie filesystemu a pod.).

Sucasny vyvojovy model (s gitom) je podstatne lepsi - nove veci sa k pouzivatelom dostanu podstatne rychlejsie. To je kvoli driverom doslova nutnost.

[VD]

Jendou z vlastností π je to, že je to normální číslo, což znamená, že jeho číslice jsou rovnoměrně rozprostřena

V článku i jiných zdrojích je, že jde jen o domněnku! Ale popisu toho fs je, že se se vyhledávají jednotlivé byty, takže to ani není potřeba.

[Luboš Doležel (Doli)]

Opraveno.

[x14]

opraveno?

JEDNOU z předpokládaných vlastností π je to, že je to normální číslo, což znamená, že jeho číslice jsou rovnoměrně ROZPROSTŘENY s tím důsledkem, že jde o disjunktní sekvenci, takže všechny možné KONEČNÉ posloupnosti čísel jsou v něm někde přítomny... atd...

[x14]

převidatelný -> převídatelný, provedné -> provedené

a to už je snad všechno

[Petr]

"navrhl je ponechat po dobu 100 let, aby se Linus nenaštval" - za 100 let se Linus už opravdu nebude schopen naštvat

[Roslav]

"Linus večne živý." a "S GNU/Linux na večné časy a nikdy inak!"

[bohyn]

Doufam ze Linux vydrzi dyl nez na vecny casy :)

[Honz]

Je v Ječný...