Zítra 23. září proběhne Maker Faire Mladá Boleslav, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Byla vydána beta verze Ubuntu 23.10 s kódovým názvem Mantic Minotaur. Přehled novinek v poznámkách k vydání. Dle plánu by Ubuntu 23.10 mělo vyjít 12. října 2023.
Josef Průša informuje o nových verzích firmwarů pro tiskárny Original Prusa, 5.0.0 pro MK4 a MK3.9 a 5.1.0-alpha1 pro MINI, díky kterým jsou tiskárny mnohem rychlejší.
Mastodon (Wikipedie), svobodná federalizovaná sociální síť, byl vydán ve verzi 4.2. Z novinek je vypíchnuto vylepšené vyhledávání.
Ben Hawkes publikoval pod názvem The WebP 0day analýzu bezpečnostní chyby CVE-2023-4863 v knihovně WebP / libwebp s řadou zajímavých odkazů. Pravděpodobně se jedná o stejnou chybu jako BLASTPASS (CVE-2023-41064 a CVE-2023-41061) v macOS, iOS, iPadOS a watchOS. Zpracování (zobrazení) speciálně připraveného obrázku nebo přílohy vedlo ke spuštění útočníkem připraveného kódu.
Myš je pro kočku: Prohlížeče je dalším dílem ze série článků Myš je pro kočku, kde Edvard Rejthar ukazuje, jak lze počítač ovládat bez myši. Používáte ve webových prohlížečích zkratky Ctrl+(Shift)+Tab, Ctrl+(Shift)+PgDn/PgUp, F6, (Shift)+Alt+Enter nebo F7?
Vývojáři mobilní Datovky prosí o pomoc s testováním beta verze mobilní Datovky s novým grafickým rozhraním, podporou pro tmavý režim a podporou pro VoDZ. Aplikace je zatím dostupná pouze pro zařízení Android a je umístěna v samostatném instalačním kanále Datovka Beta. Tento kanál slouží pro testovaní nové funkcionality a grafického uživatelského rozhraní. Datovka Beta se instaluje jako samostatná aplikace s vlastními daty, která
… více »Harlequin byl vydán ve verzi 1.0.0. Jedná se o TUI (Text User Interface) IDE (Integrated Development Environment) k systému pro správu SQL OLAP databází DuckDB.
Po roce a půl od představení DALL·E 2 představila společnost OpenAI novou verzi DALL·E 3 svého AI systému pro generování "realisticky vypadajících obrázků nebo uměleckých děl" na základě popisu v přirozeném jazyce, viz příklad "kosmonaut na koni fotorealisticky". Jednou z novinek je integrace s ChatGPT.
Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 133 (pdf) a HackSpace 70 (pdf).
Chci se zeptat jestli nemáte informace o tom jestli bude v brzké budoucnosti podporováno víc než 4GB Operační paměti. Mám 6GB a nejnovější Mandriva 2009 umí pouze 4GB takže jsem se musel bohužel vrátit k Windows Vista který jsou jako jediný který to podporujou 
A ta Mandriva je 64-bitová?
13.12.2008 18:28
michich | skóre: 51
| blog: ohrivane_parky
I kdyby byla 32bitová, tak snad má volitelně i kernel s podporou PAE.
Nejsem si uplne jisty, ale 32bit jadro 2.6 podporuje tusim 64GB pameti ... takze bud prelozit jadro, nebo zapatrat primo v distribuci po jadru oznacenem jako *hugemem, *largemem nebo co ja vim jak ...
aha a jak ho nainstaluju ten PAE nebo kde se dá sehnat?
Spusť si příkaz uname -r , ten ti vypíše verzi jádra.
Skoro v každé distribuci je nějaký grafický správce balíčku (programů), (v Mandrivě je to tuším v "Správa počítače") ten si spusť a dej v něm vyhledávat "kernel" nebo "linux" nebo začátek verze jádra z uname -r (např. 2.6.18) a uvidíš tam spoustu balíčku s jádrem Linuxu. Vyber stejnou verzi jádra jakou máš po instalaci, ale verzi s podporou paměti nad 4GB. Bude to napsáno v popisu balíčku.
Neodinstalovávej to používané jádro, může se hodit.
Pak se ti při bootu nabídne i to nové jádro.
Teda ještě doplním intelovský procesor nemám. Mám AMD Athlon X2
To je intelovska architektura. Jestli umi 64bit (nechce se mi to googlit), tak urcite 64bit linux, jinak PAE, coz je option v kernelu. Pokud Nekompilujes vlastni kernely, tak by distro melo mit verzi s PAE, nema-li, vymen distro.
64bit je na >4GB RAM lepsi, protoze ji umi adresovat primo, to PAE je trosku pomalejsi.
13.12.2008 19:19
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Není rozumné srovnávat 64-bitová Windows s 32-bitovým Linuxem a tvrdit, že Windows mají něco navrch. Chceš-li srovnávat, srovnávej na stejné šířce slova. Jinými slovy, použij 64-bitový Linux.
Windows jsou jediný systém, který má ve 32-bitové verzi těžký problém s velkou pamětí a má limit 3 GB. Neumí PAE. V 64-bitové verzi pochopitelně tento problém nebude... Nicméně podstatné je, že Linux nemá problém ani v jednom z obou případů.
Linux na 32-bitové platformě podporuje 64 GB RAM. (Každý proces má ovšem samozřejmě limit 4 GB.) Na 64-bitové platformě je celková velikost RAM řádově TB (u AMD64, MIPS64), nebo snad EB (u dnešních EMT64 od Intelu), ne-li PB (Intel Itanium, IA-64). Linux na 64 bitech tedy samozřejmě podporuje prakticky libovolnou velikost paměti.
Takže asi tak:
Já bych spíš doporučoval to 64-bitové řešení. Tam nemáš (z dnešního pohledu) žádné omezení na velikost paměti pro jeden proces.
14.12.2008 09:36
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Windows jsou jediný systém, který má ve 32-bitové verzi těžký problém s velkou pamětí a má limit 3 GB. Neumí PAE.Windows samozřejmně PAE umí a to až do velikosti 128GB. Pochopitelně je ale lepší použít 64b OS.
Dobře, ale to se týká pouze serverových verzí Windows. Kdybych měl desktop s 8 GB RAM a kdybych tam (ryze hypoteticky) chtěl Windows, asi by se mi nechtělo vynakládat nějakou šílenou částku za Windows Xyz Server.
V Linuxu prostě PAE funguje, bez diskusí a bez výjimek. Kromě toho, těmi 4 GB u Windows XP si vůbec nejsem tak jistý. Podle mě je limit 3 GB a něco málo k tomu, kvůli nějakému podivnému rozdělení adresního prostoru. Přesně to nevím a nikdy jsem to nezkoumal.
Proč neodkázat raději na tuhle stránku? Jen ať si každý přečte, jak je to žalostné! Microsoft si klidně troufá omezovat RAM v 64-bitovém systému na 8 GB, zcela záměrně a uměle. Dokonce si klidně troufne vydávat systém, který umí jen 4 GB (32-bit), případně 16 GB (64-bit), za server. No není to absurdní?
Takže i kdyby ty Visty uměly celé 4 GB, čemuž bych možná i uvěřil, kdbych to viděl, ve srovnání s Linuxem jsou pořád jen hračka pro děti. Což je pointa, kterou jsem původně sledoval, v reakci na blogpost, který se snaží srovnávat 32-bitový Linux s 64-bitovými Windows a tvrdit, že Windows jsou na tom lépe, pokud jde o podporu velké paměti.
23.12.2008 08:59
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Dobře, ale to se týká pouze serverových verzí Windows. Kdybych měl desktop s 8 GB RAM a kdybych tam (ryze hypoteticky) chtěl Windows, asi by se mi nechtělo vynakládat nějakou šílenou částku za Windows Xyz Server.
Nikoliv, to se týká Windows. Ve svém původním příspěvku o nefunkčním PAE nehovoříš o konkrétní verzi. Já na desktopu 8GB RAM mám. A mám zde i Windows. Na 64b hardware patří 64b OS, takže jsem měl Windows XP 64b i když jsem tu měl jen 2GB (teď mám 8GB a Visty 64b Business, před tím XP64). Ale v tom, že na 64b HW je lepší 64b OS asi nejsme ve sporu.
Kromě toho, těmi 4 GB u Windows XP si vůbec nejsem tak jistý. Podle mě je limit 3 GB a něco málo k tomu, kvůli nějakému podivnému rozdělení adresního prostoru. Přesně to nevím a nikdy jsem to nezkoumal.
Ano, to rozdělení paměťového prostoru u 32b XP (tj. systému z roku 2001, kdy 64b hardware doma snad nikdo neměl) je. Ale má pouze hypotetický vliv, protože si 32b app stejně víc než 2G vzít ani nemůže.
Proč neodkázat raději na tuhle stránku? Jen ať si každý přečte, jak je to žalostné! Microsoft si klidně troufá omezovat RAM v 64-bitovém systému na 8 GB, zcela záměrně a uměle. Dokonce si klidně troufne vydávat systém, který umí jen 4 GB (32-bit), případně 16 GB (64-bit), za server. No není to absurdní?
Proč žalostné (krom toho, že chápu potřebu některých si do MS šťouchnout)? Z té stránky plyne, že MS i jeho Windows umí 2TB RAM (ani nevím, kolik paměti lze nacpat do stroje, kam lze nainstalovat i ty Windows), jen je to omezeno podle zakoupené licence. Tohle je něco co MS dělá v podatatě od začátku a administrátoři to ví a podle toho ty licence též navrhují k zakoupení.
Takže i kdyby ty Visty uměly celé 4 GB, čemuž bych možná i uvěřil, kdbych to viděl, ve srovnání s Linuxem jsou pořád jen hračka pro děti. Což je pointa, kterou jsem původně sledoval, v reakci na blogpost, který se snaží srovnávat 32-bitový Linux s 64-bitovými Windows a tvrdit, že Windows jsou na tom lépe, pokud jde o podporu velké paměti.
Původní zápisek (resp. jeho autor) neměl příliš znalostí o rozdílech mezi 32, 64 a PAE, proto srovnával nesrovnatelné. V podstatě stačilo jen toto vysvětlit. Názor, že je Windows hračka (a já dítě 
) ti neberu, jen jej prosím nevnucuj ostatním. I když jsme na linuxovém portálu nepřipadá mi vhodné nenávistně házet špínu na Windows.
O tom, že je rozumné využít 64b hardware naplno, rozhodně nejsme ve sporu.
Nesnažím se házet špínu na Windows. V žádném případě jsem nikoho nechtěl nařknout z toho, že je dítě či co... To už je trochu moc překrucování, se mi zdá. Jen mě nenapadlo příhodnější srovnání mezi systémem, který podporuje tolik RAM, kolik dokáže příslušná architektura a který běží na nějakých 30 platformách, a systémem, který běží na dvou platformách a kapacitu RAM zcela nesmyslně a uměle omezuje na 2 TB, což je asi limit pro AMD64, přestože Intel umí mnohem víc.
Nejdražší Windows Server tedy umí řádově TB RAM. Některé procesory (Itanium) sice dokážou řádově téměř EB, ale dejme tomu, že pro většinu dnešních strojů Windows stačí. Rád bych ovšem poznamenal, že paměťový modul o kapacitě 2 TB se dnes již dá koupit a nemá extrémní rozměry ani extrémní spotřebu. Unese ho jeden člověk a potřebuje kolem 1 kW na 1 TB. Tím chci naznačit, že ani Windows NejlepšíNejhustšíObrovský Server nejsou dostatečně future-proof. Neumí adresovat víc RAM, než kolik jí lze dnes mít v sériově vyráběném serveru.
V žádném případě nechci ani slovem rýpat do lidí, kteří (ať už dobrovolně či nedobrovolně) Windows administrují. Jen mi celá tahle věc připomíná slavný článek Kdyby Microsoft vyráběl auta.
Záměrné omezování dostupné paměti je prostě odporný closed-source trik. Proč se asi někdo snaží omezit použití verze Server jen na menší stroje a na největších umožní pouze Datacenter Server? To mi připadá, jako by ta dražší verze prostě neměla co nabídnout. Svou přízeň si pak musí vynucovat pomocí nesmyslných omezení. Jinak by se nakonec mohlo stát, že správce zvolí Windows ObyčejnýServer a spoustu open-source k tomu.
23.12.2008 17:04
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Proč se asi někdo snaží omezit použití verze Server jen na menší stroje a na největších umožní pouze Datacenter Server?Protoze kdyz si koupis tri prdele pameti tak jiste mas jeste par sestaku na uber verzi windows. To je to same jako "studentska verze office". Rika se tomu vydelavani penez. Spousta open source projektu je dual licencovanych. Je to odporne?
Spousta open source projektu je dual licencovanych. Je to odporne?Odporné? Proč? Já proti SW, co se nazývá pod BSD a GPL a podobnými kombinacemi nic nemám :). Ani mi nevadí BSD a proprietární licence. A... snad bych se uměl smířit i s GPL a proprietární, pokud by se při tom nepoužíval FUD a nezneužívalo se důvěřivosti uživatelů GPL software a zhovadilosti šiřitelů lživých informací :).
Windows jsou jediný systém, který má ve 32-bitové verzi těžký problém s velkou pamětí a má limit 3 GB.AFAIK pouze Windows 2000 profi a XP.
TB (u AMD64, MIPS64), nebo snad EB (u dnešních EMT64 od Intelu), ne-li PB (Intel Itanium, IA-64)To je nejakej renonc ne? 64 bitu je vsude stejnych. (Nepocitam zde ustipnute konektory u procesoru.)
viz en.wikipedia.org/wiki/X86-64
...
Current processor models implementing the AMD64 architecture can address up to 256 TB[4] of virtual address space. This limit can be raised in future implementations to 16 EB.
...
Current implementations of the AMD64 architecture can address up to 1 TB of RAM; the architecture permits extending this to 4 PB in the future (limited by the page table entry format).
...
64-bit Linux allows up to 128 TB of address space for individual processes, and can address approximately 246 (64 TB) of physical memory, subject to processor and system limitations.
A co prosím pěkně to číslo znamená? 64 bitů není všude stejných, protože 64 bitů se pro adresování paměti nikde nepoužívá. To si asi pleteš s 64-bitovou aritmetikou.
Když si o tom něco zjistíš, dozvíš se například, že zdaleka ne celých 64 bitů tvoří adresu. Ostatní bity slouží jako různé flagy a podobně. Některé architektury nepoužívají víc než cca 40 bitů (MIPS64), jinde se používá de facto nějakých 48 bitů (AMD).
Nejzajímavější situace je u Intel Itanium. Tam adresa tvoří cca 60 bitů a ten malý zbytek není nic jiného než příznak, že se jedná o adresy ve virtuálním prostoru jiného procesu. Tímto způsobem se získá například možnost de facto sdílet pointery a datové struktury na nich založené. Stačí jen rychlá bitová operace a pointer je přepočten z adresy v cizím procesu do „lokální“, přímo použitelné podoby. Že si procesy musí tento přístup napřed dohodnout s kernelem, to je jasná věc. Nicméně ve srovnání s klasickou sdílenou pamětí tohle přináší spoustu zajímavých výhod i nevýhod.
Používat 64 bitů pro adresování paměti je nesmyslné plýtvání. Za pár let možná bude k dispozici tolik paměti, aby něco takového dávalo smysl, nicméně dnes v tom žádný smysl nevidím. (A návrháři procesorů ho tam taky neviděli. To jsou lidé nesrovnatelně chytřejší, než jsem já.)
Když si o tom něco zjistíš, dozvíš se například, že zdaleka ne celých 64 bitů tvoří adresu. Ostatní bity slouží jako různé flagy a podobně. Některé architektury nepoužívají víc než cca 40 bitů (MIPS64), jinde se používá de facto nějakých 48 bitů (AMD).Není to náhodou jak kde? U AMD se sice používá pouze spodních 48 bitů adresy, ale adresu tvoří všech 64bitů (s tím, že horní bity jsou kopie bitu 47 - tvrdí wikipedie) Takže s tím, že se to nikde nepoužívá, bych byl opatrnější.
Já jsem ale přece neřekl, že nějaký pointer je menší než 64 bitů. Adresa na 64-bitovém systému je samozřejmě 64 bitů dlouhá. Nicméně to prostě neznamená, že se tím dá adresovat 2^64 bytů paměti.
Nicméně to prostě neznamená, že se tím dá adresovat 2^64 bytů paměti.Kdežto 32bitová adresa prostě neznamená, že se s ní dá adresovat 2^32B paměti. Když je nemáš. Nicméně není pravda tvoje "64 bitů se pro adresování paměti nikde nepoužívá." U x86 se pro adresování paměti používají všechny bity - pokud tohle chceš vyvrátit, tak mi ukaž, na kterých bitech nezáleží a je možné je vypustit.
A už zase někdo překrucuje, co jsem řekl.
Kdo tvrdí, že se dají nějaké bity vypustit? Jak bych je měl vypustit? Jak bych přesvědčil procesor, aby mělo slovo nestandardní délku nebo aby v něm některé bity najednou chyběly? Žádný bit nelze vypustit a nikde jsem to netvrdil.
64 bitů se pro adresování paměti nikde nepoužívá. Jak už jsem minimálně dvakrát říkal, pointer má 64 bitů na všech 64-bitových architekturách, ale některé bity slouží jako metadata a nejsou součástí adresy. Některé dokonce musí být napevno nastavené a žádnou informaci nenesou. Příklad metadat hledej v mých příspěvcích o Itaniu nebo MIPS64. (Nebo si to vyhledej. V manuálech k procesorům to najdeš mnohem přesněji, než tady tvrdím já.)
Pokud chceš mé tvrzení vyvrátit, jmenuj mi jeden procesor, který umí adresovat 2^64 B virtuální paměti. Nenajdeš ho.
32-bitová adresa znamená, že se dá adresovat 4 GB paměti na jeden proces u platformy x86 a 2 GB paměti na jeden proces u platformy MIPS32.
Kdežto 32bitová adresa prostě neznamená, že se s ní dá adresovat 2^32B paměti. Když je nemáš.
To je prosím pěkně nesmysl. Co třeba swap? Když mám dostatek swapu, můžu na x86 klidně adresovat celé 4 GB na jeden proces. Paměť != (to, čemu dnes říkáme) RAM.
Jak už jsem minimálně dvakrát říkal, pointer má 64 bitů na všech 64-bitových architekturách, ale některé bity slouží jako metadata a nejsou součástí adresy.Kdežto na některých architekturách žádné bity jako metadata neslouží. Tak mi necpi MIPSy a Itania. Já se bavím o AMD64, kde žádná metadata nejsou.
Pokud chceš mé tvrzení vyvrátit, jmenuj mi jeden procesor, který umí adresovat 2^64 B virtuální paměti. Nenajdeš ho.x86_64, až bude odstraněno to omezení, které je tam teď.
To je prosím pěkně nesmysl. Co třeba swap? Když mám dostatek swapu, můžu na x86 klidně adresovat celé 4 GB na jeden proces. Paměť != (to, čemu dnes říkáme) RAM.Ano, to vím. A přesně s tímto předpokaldem jsem napsal, že nemůžeš adresovat 4GB paměti, když nemáš 4GB paměti. V takovém případě podle tvé logiky ovšem ten procesor není 32bitový, ale třeba jen 30bitový.
x86_64, až bude odstraněno to omezení, které je tam teď
Ano, děkuji, to jsem chtěl slyšet. Měl jsem tedy pravdu a procesor adresující 16 EB RAM neexistuje. Bavím se o současných procesorech, které jsou běžně dostupné a sériově vyráběné. Omezení nebudou nikdy odstraněna. Dřív než bude tolik paměti potřeba, vystřídají se ještě aspoň dvě další generace procesorů. Tvrdit, že x86_64 bude jednou umět 16 EB, je předčasné.
Ano, to vím. A přesně s tímto předpokaldem jsem napsal, že nemůžeš adresovat 4GB paměti, když nemáš 4GB paměti. V takovém případě podle tvé logiky ovšem ten procesor není 32bitový, ale třeba jen 30bitový.
Zase překrucuješ. Já jsem nikde ani nenaznačil, že by se snad procesor měl označovat jinak jen proto, že nevyužívá k adresování celou šířku slova. Tedy nevím, o jaké „mojí“ logice je řeč. Jaký by měl být z pohledu procesu rozdíl mezi RAM a swapem? Proces nic takového nerozeznává. Má svůj virtuální adresní prostor, který vnímá prostě jako paměť, bez ohledu na to, která stránka je trvale namapovaná do rámce v RAM a která je zrovna uložená ve swapu.
Omezení nebudou nikdy odstraněna. Dřív než bude tolik paměti potřeba, vystřídají se ještě aspoň dvě další generace procesorů.Jo, 640kB paměti je dost na to, aby se to nemuselo upgradovat dalších deset let. Takových už bylo.
Zase překrucuješ.Ne, nepřekrucuju: "64 bitů není všude stejných, protože 64 bitů se pro adresování paměti nikde nepoužívá." Tedy v x86_64 se nepoužívá 64bitů, protože není tolik paměti. Podle stejné logiky když v x86 nemám tolik paměti, není tam 32bitů stejných.
Jaký by měl být z pohledu procesu rozdíl mezi RAM a swapem?To já nevím, vzhledem k tomu, že to sem pořád taháš ty, tak bys to měl objasnit.
Proces nic takového nerozeznává. Má svůj virtuální adresní prostor, který vnímá prostě jako paměť, bez ohledu na to, která stránka je trvale namapovaná do rámce v RAM a která je zrovna uložená ve swapu.Ano, to vím. A stále nevím, jakou to má souvislost s tím, že když nemáš 4GB paměti, pak nemáš 4GB paměti. (Jeden by řekl, že něco takového je zjevné, ale zjevně ne, když už to musím opakovat potřetí.)
Ty ustřižené piny považuji za jakési hodně obrazné vyjádření...
Není zatím žádný důvod ta omezení odstraňovat. Rozhodně nejsou samoúčelná a rozhodně nesouvisí s nějakou optimalizací. Například u MIPS64 slouží některé bity v kernel-mode jako přepínače mezi minimálně třemi různými přístupy do paměti: fyzickým, fyzickým bez použití cache a virtuálním. Odstranění příslušných omezení tedy není ani možné, ani smysluplné. (Dobře, uznávám, MIPS64 je mrtvá architektura...)
Nevím, jak to má například SPARC64, ale i tam by se určitě našly podobně důležité bity.
Ten příklad s Itaniem jsem uváděl právě proto, že tam je těch omezení nejméně. Jeden jediný proces dokáže naráz přistupovat k cca 2^60 B vlastní paměti a navíc ještě (2^63 - 2^60) B paměti, která patří jiným procesům. Ten poslední bit má nějaký hodně speciální význam, pokud vím, a teď se mi to nechce hledat.
Celkově vzato jsem chtěl říct, že některé procesory sice umí skoro 64 bitů (Itanium), ale drtivá většina standardních procesorů (EMT64, AMD64, SPARC64) má adresní prostor zcela záměrně menší, aby adresa mohla obsahovat různá metadata.
Není zatím žádný důvod ta omezení odstraňovat. Rozhodně nejsou samoúčelná a rozhodně nesouvisí s nějakou optimalizací.Ano, ta omezení nejsou samoúčelná, ale s optimalizací rozhodně souvisí - výrazně zjednodušují zpracování uvnitř procesoru.
Například u MIPS64 slouží některé bity v kernel-mode jako přepínače mezi minimálně třemi různými přístupy do paměti: fyzickým, fyzickým bez použití cache a virtuálním. Odstranění příslušných omezení tedy není ani možné, ani smysluplné. (Dobře, uznávám, MIPS64 je mrtvá architektura...)Proč pořád utíkáš od x86, kde žádné bity v adrese neslouží k ničemu jinému, než je adresování paměti.
drtivá většina standardních procesorů (EMT64, AMD64, SPARC64) má adresní prostor zcela záměrně menší, aby adresa mohla obsahovat různá metadata.U toho AMD64 prostě nemáš pravdu. Adresa neobsahuje žádná metadata, adresa obsahuje informace o tom, kde v adresovém prostoru leží požadovaná hodnota.
Ano, ta omezení nejsou samoúčelná, ale s optimalizací rozhodně souvisí - výrazně zjednodušují zpracování uvnitř procesoru.
O tom, zda něco zjednodušují, není k dispozici dostatek informací od výrobce. Nespekulujme tedy. O optimalizacích se člověk může něco dozvědět například v souvislosti s projektem OpenSPARC. Nicméně korektní posouzení vlivu omezeného adresního prostoru na výkon vyžaduje spoustu znalostí, které nemám. Nemá pro mě smysl se o tom hádat, zejména když není s čím srovnávat. Na světě neexistuje procesor, který by uměl adresovat 2^64 bytů.
Proč pořád utíkáš od x86, kde žádné bity v adrese neslouží k ničemu jinému, než je adresování paměti.
A proč pořád vymýšlíš nějaký sen o 16 exabytech? To, co říkáš, není pravda. Dvakrát hledej a jednou střílej od boku. Dobře, metadata jsou pouze u Itania a MIPS64. Intel em64t v adrese metadata nemá. To ale neznamená, že používá 64 bitů. Intel to říká jasně. Víš-li o tom víc než stránky Intelu, všechna čest. Já se raději budu držet jejich informací.
Z tohoto staršího článku je zřejmé, že maximální velikost paměti s každou novou generací procesorů postupně roste. To jsem koneckonců nepopřel. Nicméně momentálně nikdo 16 EB nepodporuje. V případě Itania bych se vsadil, že ani ten 1 EB na proces (+ dalších sdílených 7 EB k tomu) zatím nikdo neimplementoval. Je to pouze jakési maximum, kterého by příslušná architektura mohla jednou dosáhnout.
Nepochybuji o tom, že v daleké budoucnosti bude možné adresovat celý 64-bitový rozsah. Já ale vedu diskusi o současných procesorech, které umí o mnoho řádů méně.
U toho AMD64 prostě nemáš pravdu. Adresa neobsahuje žádná metadata, adresa obsahuje informace o tom, kde v adresovém prostoru leží požadovaná hodnota.
To mám rád, když mě někdo chytá za slovo. Nemá tedy metadata, ale všechny současné procesory AMD mají část adresy
nastavenou fixně. Tedy se příslušné bity k adresování nevyužívají.
O tom, zda něco zjednodušují, není k dispozici dostatek informací od výrobce. Nespekulujme tedyJá nemusím spekulovat. Logický obvod, který zpracovává menší šířku slova, je vždy jednodušší, než ten samý obvod zpracovávající menší slovo. To není spekulace, to je prostě fakt. Jednodušší obvody potom bývají rychlejší atd.
Nicméně korektní posouzení vlivu omezeného adresního prostoru na výkon vyžaduje spoustu znalostí, které nemám.Ano, to je vidět.
To ale neznamená, že používá 64 bitů.Jaktože ne? To, že jsou u toho procesoru uřezané nožičky ještě neznamená, že se nezpracovává celá adresa. Akorát (zatím) každý kus jinak.
Nemá tedy metadata, ale všechny současné procesory AMD mají část adresy nastavenou fixně. Tedy se příslušné bity k adresování nevyužívají.Nemáš pravdu a tentokrát ze sebe ještě děláš hlupáka, který neumí číst. Přímo na dané stránce máš napsané, že ty bity se používají
Opět kecy v kleci. Kdyby se ty bity používaly, šlo by o metadata, proti kterým tu tolik řečníš. Nicméně faktem je, že se nepoužívají a nastavují se podle hodnoty té používané části adresy. Hlupáka ze sebe děláš ty, když neustále chytáš lidi za slovo a překrucuješ, co řekli.
Kdyby se používaly všechny bity, mohl bych použít kterékoliv z 2^64 možných slov jako adresu. Jenže nemůžu. Takže je prostě jasné, že adresa na AMD64 prostě nemá stejnou informační hodnotu jako 64-bitový integer. Lze snadno vygenerovat neplatné adresy, které vyvolají výjimku. (Což je koneckonců jasně popsáno v manuálu k procesoru.)
Soudě podle těch řečí o logických obvodech, ani ty nemáš potřebné znalosti k posouzení vlivu délky slova na rychlost výpočtu. Že jednodušší obvody bývají rychlejší? Co to znamená? Co je to za nesmysl? Procesor prosím pěkně pracuje s diskrétním časem, a to už dobrých 40 let, víme??? Takže pokud by střední doba vykonávání nějaké instrukce klesla třeba ze tří cyklů na dva díky omezení délky adresy, dalo by se tvrdit, že jde o zrychlení.
Nicméně dnešní běžný procesor není nic jiného než počítač, který je typu RISC, běží na něm mikrokód a jeho úkolem je tvářit se navenek jako procesor typu CISC. Má několik pipeline, několik aritmetických jednotek a instrukce provádí spekulativně, tedy mění jejich pořadí, při větvení předpočítává nejpravděpodobnější pokračování a podobně. Při vší dobré vůli se nedá spolehlivě prokázat, co se přesně stane, když adresa nevyužije všech 64 bitů.
Zkrátka a dobře, nemůžeš s jistotou tvrdit, že to či ono omezení zvyšuje rychlost. Na to prostě nemáš znalosti.
Nicméně je to jistý pokrok od chvíle, kdy jsi tady tvrdil, že 16 EB se adresovat dá. Aspoň teď už víš, jak ses mýlil.
Nicméně faktem je, že se nepoužívají a nastavují se podle hodnoty té používané části adresy.Ergo používají se. Když je nenastavíš správně, procesor ti vyhodí výjimku, což už ses konečně s několikahodinovým zpožděním dočetl v manuálu.
Že jednodušší obvody bývají rychlejší?Ano.
Co to znamená? Co je to za nesmysl? Procesor prosím pěkně pracuje s diskrétním časem, a to už dobrých 40 let, víme???Víme. Ale pod tím diskrétním časem se stejně skrývají obvody, které pracují analogově ve spojitém čase a jejich výstup je synchronizován, víme? A teď hádanka pro laskavého čtenáře: copak se stane, když obvod je tak složitý, že k analogovému ustálení výstupu nestačí nějaký počet tiků hodinového signálu? Odpověď pro laskavého čtenáře: hodnota se musí použít až o tik později, ergo zjednodušení obvodu.
Takže pokud by střední doba vykonávání nějaké instrukce klesla třeba ze tří cyklů na dva díky omezení délky adresy, dalo by se tvrdit, že jde o zrychlení.Hm, střední doba instrukce. Jasně - jistě mi rád vysvětlíš, jak by změna šířky adresy měla ovlivnit instrukce typu přičti přímou hodnotu k registru. Jsem na tebe zvědav. Kde omezení šířky slova přinese naprosto jistě zrychlení zpracování, jsou obvody pro vyhledávání v cache či mapování virtuální adresy na fyzickou. A to jsem stále ještě nezmínil fakt, že větší šířka slova znamená víc tranzistorů, což znamená víc zabrané plochy čipu. Vyhoď přebytečné tranzistory a můžeš tam dát nějaký jiný obvod, který pravděpodobně přinese zrychlení jiným způsobem (protože jinak proč by tam byl)
Teda já do toho nechci kecat ale podle rad si nainstaluju 64bit a budu tady brečet že pro 64bit není spousta programů...to mi nepřipadá jako šťastné řešení.
14.12.2008 22:29
Max | skóre: 72
| blog: Max_Devaine
). Chybějící 64bit aplikace vyřešíš nainstalováním 32bitových knihovan a 32 bitových aplikací, takže máš ve finále vše jednom. Napadá mně jen pár drobností, co je stále 32bit, ale to se řeší 32bit knihovnama. Jinak už hodně věcí je v 64bit. Navíc 64bit systém je lépe optimalizován na tvůj HW, dosáhneš s ním lepšího výkonu a odezvy
14.12.2008 23:31
David Watzke | skóre: 74
| blog: Blog...
| Praha
Ale seznam 32b věcí co mám nainstalovaný ti vyjmenuju z hlavy: Wine, RCTW:ET, Firefox (běžně nepoužívám, jen pro testing) + knihovny, aby to všecko běželo. Nic z toho ale nemusím mordovat ručně, vše zařídí distribuce.
No ja jsem 4GB RAM poprve prelezl asi pred tremi roky, vzdy s procesory Opteron, distribuce COS nebo Fedora, a nikdy sem nazaznamenal zadny vetsi problem a to ani u 32bit aplikaci (jen se pro ne dohrkaly knihovny). Takze doporucuji RTFM dane distribuce.
e.
Tak to je samosebou jiná ale ještě před půl rokem jsem "všude" četl jak si uživatelé drží 32-bit z důvodu zpětné nekompatibility 64b OS a 32b aplikací. Jestli jsou tam na to knihovny tak fajn to není problém.A 64bit mi teda bude umět pracovat bez nějakého hledání vhodného kernelu s 6GB operačky jo? Jenom co si tak matně vzpomínám tak kamarád co má tuším taky tolik si nainstaloval 32bit mandrivu a pokaždý mu to vybralo již při instalaci již zmiňovaný pro desktopy ne až tak vhodný kernel-server a netušil jsem proč. Teď už asi začínám tušit takže teda v 64bit mandrivě by všechny kernely měly podporovat upper 4GB?
To ze si lidi drzeli 32-bit asi nebylo na Linuxu 
V opensource neni prechod na 64-bit vubec problem pokud clovek nepise opravdu hodne hloupe. Jediny problem byly neopensource aplikace jako macromedia flash nebo sun java. Ale k oboum existuje i opensource alternativa a dnes je flash uz i pro 64-bit. Navic neni problem provozovat 32-bit aplikace v 64-bit prostredi (pokud clovek doinstaluje i 32-bit knihovny)
A ano, v 64-bit by mela bejt vsechna pamet dostupna at uz si vyberes kterejkoliv kernel.
Super jenom mě prosím nakopněte jak se jmenujou ty knihovny ať vím do čeho jdu a jdu stahovat 64Bit
Kdyz budes potrebovat neco, co je pouze 32-bit, tak spravce balicku si ty spravny zavislosti najde. Aspon verim tomu, ze si je najde sam (Mandrivu nemam), ale s nejvetsi pravdepodobnosti 32-bit aplikace nebudes potrebovat
No já nevím ale když jsem se před rokem pokoušel pracovat ve 64bit mandrivě tak to byla katastrofa. balíčky jako win32-codecs a teď si momentálně další nevzpomenu tam prostě nebyly a to mi dost vadilo ale pokud bych tyhle mohl do 64bit mandrivy 2009 jakkoliv nainstalovat bude to super
U fedory uplně stejně jak ty pro 64b
Příklad:
[petr@soban ~]$ rpm -qa | grep glibc
glibc-2.9-3.x86_64
glibc-2.9-3.i686
glibc-devel-2.9-3.x86_64
glibc-common-2.9-3.x86_64
glibc-headers-2.9-3.x86_64
[petr@soban ~]$ rpm -qa | grep dbus-libs
dbus-libs-1.2.8-1.fc10.x86_64
dbus-libs-1.2.8-1.fc10.i386
A jestli tomu dobře rozumím tak zrovna balíčky glibc jsou ty knihovny který bych tam měl mít aby mi fungovali 32bit aplikace že?
Prostě musíš tam mět ty balíčky co ten 32b program požaduje u každého programu to může být jiné.
Většina balíčkovacích systémů nainstaluje co třeba.
Ono to zase nani tak uplne jednoduchy. 64bit kernel musi implementovat vsechny syscally/ioct jak v 32bit tak 64bit verzi a to se nekdy nedeje. Funguje vam 32bit aplikace pouzivajici V4Linux? Pokud ano tak od ktere verze kernelu? Muzete debugovat 32bit aplikace na 64bit kernelu? Ja ano, ale nemuzu delat breakpointy v .so knihovnach. Teda ted uz to docela funguje, 32bit ptrace byl opraven nekdy okolo 2.6.23 a samozrejme ze na to potrebujete nejnovejsi GDB.
Tak tomu rozumím například mě aplikace xdtv naposledy zobrazovala obraz v kernelu tuším 2.6.17-14 nebo tak nějak a od té doby ne. Musel jsem tento kernel pustit protože v nových verzích už nebyl a hlavně nevyužíval 2 jádra CPU. Takže další problémy jo? Hmm tak já nevím. Když se mě ptají známí jestli by teda neměli jít " Do toho Linuxu když je oproti Windows tak skvělej" Nevím ani co odpovědět protože nevím jak bych jim to doporučil nainstalovat tak aby jim to běhalo minimálně stejně spolehlivě...
Aby jim to behalo minimalne stejne spolehlive jako windows - nainstalovat jakkoliv. Z toho co tu padlo vypliva ze te pravdepodobne nebude nic trapit pokud nebudes delat naky extra hokusy pokusy. Jedine closedsource aplikace co me napada a neni 64-bit a mozna ma smysl ji obcas pouzivat je java od sunu (konkretne plugin pro firefox), ale existujou opensource alternativy a konkretne 32-bit plugin pro javu se da pouzivat i na 64-bitech. Ale pravdepodobne ho nebudes potrebovat a pouzijes nekterej z tech opensource. Cili 64-bit nejsou dneska zadnej problem.
Dalsi alternativa je pouzit jiny distro ktery ma normalni pae kernel, ale nevidim pro beznyho uzivatele jedinej rozumnej duvod, proc pouzivat 32-bit OS na 64-bit HW.
15.12.2008 22:17
Salamek | skóre: 22
| blog: salamovo
kurva co to tu do něj valíte ,žádny problémy prostě instni 64bit distro a ty widlák visták nepoznáš rozdíl(kromě více alokované RAM a využívání 64bit což jsou jen výhody)
takže mázni shittovy wisty a instni 64bit distro
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
27.12.2008 22:17
14.12.2008 23:07