Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Po case na Ubutnu 7.04 amd64 prechadzam opat raz na 32b OS. Mam uz stiahnute ISO netinst Debian 4.0r1, dnes vecer by som chcel spravit prehodenie systemu. Dokumenty su uz odzalohovane na LAN disku, ostava uz len vypalit ISO a vecer sa pustit do instalacie.
DovodyZacnem zosiroka. V case ked som zacinal na Linuxe (tusim okolo 98 - 99 roku) som pracoval na RH 5.0 CZ (alebo 5.1). Vtedy nebolo ani chyru ani slychu o 64b procesoroch pre mainstream (SUN procaky uz 64b tusim boli (?)). Potom nasledovalo obdobie (za "obdobie" povazujem aspon 3 - 6 mesiacov na danej distribucii, nie nahodne 2-3 dnove skusanie noveho OS) Mandrivy, Slackwaru (tusim do 2004), objavenie rychlosti (Archlinux i686 neskor x86_64), objavenie stability a prepracovaneho balickovacieho systemu (Debian) a nakoniec klikaci fenomen menom Ubuntu (skusal som snad vsetky forky/modifikacie Ubuntu - najlepsie sa mi javilo prave samotne Ubuntu). Avsak snazil som sa pouzivat vo vacsine pripadov od cias ked som si zaobstaral 64b cpu (AMD Athlon 64 3000+) vyhradne 64b OS. Rozdiely v rychlosti som obcas postrehol, obcas nie (surfovanie po webe (tam sa mi prave zdalo ze firefox je na 64b lenivejsi), praca s mailami, oo.org, inkscape, gimp, audacity, freepascal ...). Avsak narazal som na problemy pri kompilovani programov ktore sa nenachadzali priamo v distribucii (pripisujem to prave 64b), castokrat hlavne v poslednej dobe som maval casto problemy s nedostatkom pamate (512M) a naslednou nutnostou swapovania (to som zase pripisoval viacerym spustenym programom na viacerych plochach v Gnome (pozn. nevravim ze v KDE by to bolo lepsie/horsie)). Takze som sa rozhodol prejst na moju oblubenu kombinaciu s cias Slackwara. A taktiez spat na 32bitov...
Oblubena kombinacia
Mojou oblubenou kombinaciou s cias Slackwara je Fluxbox + OO.org + Firefox + Thunderbird + ostatne oblubene programy. Pri 512M pamate by som s touto kombinaciou nemal narazat na uz spominane problemy s pamatou a swapovanim. Tuto kombinaciu si nahodim hned po sietovej instalacii Debianu. Mozno niekto namietne ci mi nebude chybat Nautilus (Konqueror) odpoved znie nie - ako file manager mi staci Midnight Commander, akurat miesto atermu pouzijem xfce4-terminal. Taktiez vymenim Rhythmbox za menej tazkotonazny osvedceny XMMS, Gwview za Gtksee, Evince za Xpdf a pod. Taktiez po dlhsej dobe pribudne Wine (a WinSCP 
). Tesim sa, ak to vecer vsetko stihnem od zajtra pouzivam opat raz po case 32b OS...
Tiskni
Sdílej:
30.8.2007 10:12
Michal Fecko | skóre: 31
| blog: Poznámkový blog
30.8.2007 10:49
Michal Fecko | skóre: 31
| blog: Poznámkový blog
maleprase sa pytal preco WinSCP a ja som mu povedal ze GFTP mi prestalo vyhovovat a neviem ci MC podporuje SFTP vzdialeny pristup. :(dnes 10:10 maleprase to winscp proboha na co? dnes 10:12 Michal "feco" Fecko gFtp mi prestalo vyhovovat... dnes 10:19 kavol proč gftp, když říkáš, že jako souborový manažer ti vyhovuje mc?
30.8.2007 13:24
Michal Fecko | skóre: 31
| blog: Poznámkový blog
jak je to se sftp nevím, musel bych se zeptat Googla, což můžeš udělat sám, ale se scp nemá mc (vážnější) problémy já jsem to právě pochopil tak, že chceš používat scp, proto chceš mít winscp, kterým nahrazuješ z nějakého důvodu nevyhovující gftpNa WinSCP mi to spojenie ide bezproblemovo, s gFtp mi vypise nejaky socket error a MC musim ako si spominal vygooglit, kazdopadne WinSCP ma lepsie/krajsie/sofistikovanejsie prostredie na prenost suborov ako MC (IMHO).
30.8.2007 10:14
Michal Fecko | skóre: 31
| blog: Poznámkový blog
to winscp proboha na co?...a snad este to Wine aj na uTorrent, lebo ten spolu s Putty, TC a WinSCP povazujem za kus dobreho kodu pre Win32.
30.8.2007 10:58
Michal Fecko | skóre: 31
| blog: Poznámkový blog
Proboha, ale vzdyt on nikde nepsal, ze je Putty lepsi nez konsole ci xterm. Pouze sdelil, ze Putty spolu s TC, WinSCP a uTorrent povazuje za kus dobreho kodu pro Windows (rozumnej vydarene/uzitecne). A pod to se muzu jedine podepsat, lepsiho alternativy k WinSCP, TC ci Putty pod windows neznam. To, ze windows vubec nepouzivam je vec jina.+1 Tak som to presne myslel tiez radsej miesto spustenia Putty (ak niesom na Windowse) pouzijem konzolu milovanu a
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
ssh - l meno ip.da.re.sa
30.8.2007 10:55
Michal Fecko | skóre: 31
| blog: Poznámkový blog
Inak prechod na Debian sa mi paci, akurat ... no neviem a co skusit testing? mozno pocase ... ? GL HF KaioTesting ma odrazda uz len tim nazvom ze "testing". Urcite sa testing debiana = stable ubuntu, mno neviem, ak nebude problem s nejakym HW tak ostanem na stable Debiane.
Inak ani si nenapisal, aky HW sa bude z deb tesit?
Kaio
30.8.2007 11:24
Michal Fecko | skóre: 31
| blog: Poznámkový blog
MD Biostar A9A-Ultra (NF4 Ultra), AMD Athllon 64 3000+, 512M RAM (2x256M moduly), 160G SATA2 HDD, SB Live 5+1, ATI Radeon X300 128M, DVDRW, Card Reader interny (ktory mi na ubuntu ani na debiane zatial neide a pouzivam ext. cez USB), 22" LCD Acer AL2223W cez DVI. Asi dam svoju konfiguraciu PC naspat do opisu blogu, aj ked sa to niektorym jedincom nepacilo a nadavali mi za to do nejako "Hulana"Inak ani si nenapisal, aky HW sa bude z deb tesit?
Kaio
30.8.2007 13:48
Michal Fecko | skóre: 31
| blog: Poznámkový blog
30.8.2007 10:19
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
Avsak narazal som na problemy pri kompilovani programov ktore sa nenachadzali priamo v distribucii (pripisujem to prave 64b)A teď si představte, že já mám 64bit OS kompilovaný celý a problémy nejsou.
Ja mel taky problemy s kompilaci - tady zalezi hodne na verzi GCC a glibc. GCC 4 trochu blbnula, ale od verze 4.2.x uz zadne problemy nezaznamenavam.
30.8.2007 10:53
Michal Fecko | skóre: 31
| blog: Poznámkový blog
30.8.2007 11:20
30.8.2007 10:35
long, int a 'void *' nemusely být stejně velké, že by měl k ukládání časových údajů používat (k tomu určený) time_t místo int nebo že by knihovna mohla být i jinde než v /usr/lib, pak s překladem jeho výtvoru budou problémy i na spoustě 32-bitových platforem.
int na 64bit procesore ma 64bit oproti 32bit, takze…
Než začnete argumentovat, bývá dobré si nejdřív ověřit fakta, ze kterých vycházíte. Takže bavíme-li se o x86_64 a gcc, pak je int 32-bitový i při použití -m64. Tím padá váš argument spotřeby paměti i rychlosti (ten je pochybný i proto, že po 64-bitové sběrnici se překvapivě 32-bitová i 64-bitová hodnota přenese stejně rychle) a zůstává jen mlhavá a neurčitá hrozba nespolehlivosti aplikací (což je ovšem spíš problém těch konkrétních aplikací, ne platformy).
A i kdyby ne, každý aspoň trochu slušný programátor si u pole o milionu položek nejdřív pořádně rozmyslí, jak velké ty položky potřebuje, a podle toho zvolí vhodný typ.
Tím padá váš argument spotřeby paměti i rychlostiNe zcela - pointery budou dvakrat vetsi, coz muze zpusobit nezanedbatelny narust datovych struktur.
(ten je pochybný i proto, že po 64-bitové sběrnici se překvapivě 32-bitová i 64-bitová hodnota přenese stejně rychle)Co se tyce rychlosti, tak to neni zas tak pochybny argument - AFAIK mezi L2 cache a RAM (coz byva pomerne uzke hrdlo) probiha vymena dat po blocich pevne velikosti (nikoliv po jednotlivych 32bit nebo 64bit slovech) a do takoveho bloku se samozrejme vejde polovicni mnozstvi 64bit hodnot nez 32bit hodnot.
A i kdyby ne, každý aspoň trochu slušný programátor si u pole o milionu položek nejdřív pořádně rozmyslí, jak velké ty položky potřebuje, a podle toho zvolí vhodný typ.V cemz mu zrovna jazyk C moc nepomaha (alespon tradicni ANSI C, v C99 je to uz trochu lepsi).
V cemz mu zrovna jazyk C moc nepomaha (alespon tradicni ANSI C, v C99 je to uz trochu lepsi).
V roce 2007 už si snad mohu dovolit si pod "C" představovat C99…
Ne zcela - pointery budou dvakrat vetsi, coz muze zpusobit nezanedbatelny narust datovych struktur.
První 32-bitový procesor jsem měl v počítači v roce 1992, paměti jsem tehdy měl 4 MB. První 64-bitový procesor jsem měl v počítači v roce 2004 a paměti jsem k tomu měl 1 GB. Takže vezmu-li v úvahu nárůst velikosti operační paměti v poměru 256:1 a velmi nadsazený horní odhad poměru velikosti datových struktur 2:1, je docela zarážející, že tehdy nikdo nehoroval pro setrvání u 16-bitových systémů, zatímco dnes je tu docela početná skupina prosazující setrvání u 32-bitových, a zdůvodňuje to dvakrát větší velikostí některých datových typů…
Co se tyce rychlosti, tak to neni zas tak pochybny argument - AFAIK mezi L2 cache a RAM (coz byva pomerne uzke hrdlo) probiha vymena dat po blocich pevne velikosti (nikoliv po jednotlivych 32bit nebo 64bit slovech) a do takoveho bloku se samozrejme vejde polovicni mnozstvi 64bit hodnot nez 32bit hodnot.
Což je ovšem vyváženo tím, že procesor dokáže v jednom kroku zpracovávat 64-bitové až 128-bitové hodnoty, zatímco na 32-bitové platformě jen 32-bitové a 64-bitové.
Nešlo mi o přechod z 16-bitových systémů na 32-bitové, ale o něco trochu jiného: za těch 12 let (ve skutečnosti více, Athlon64 jsem si pořídil podstatně dříve po uvedení na trh než 386) narostla postupně paměť počítačů v poměru 256:1, ale přesto se řada lidí podvědomě stále bojí (ve skutečnosti silně hypotetického) skokového nárůstu paměťové náročnosti aplikací v poměru 2:1. Jenže pokud si své setrvání u 32-bitových platforem budou zdůvodňovat tímto skokem, pak budou paměti stále růst a růst, ale oni nepřejdou nikdy, protože se pořád budou bát toho skoku (který je ve skutečnosti mírnější než běžný upgrade).
Je to trochu podobné, jako když zastánci IPv4 a maškarádového svinstva na věčné časy brojí proti IPv6 a zdůvodňují to větší náročností datových struktur na routerech. Jenže za tu dobu, co takto usilovně brzdí pokrok, aby mohli prodávat svá pseudořešení, už právě ty paměti v routerech narostly mnohonásobně více, než poměrem 4:1, kterým nás tak rádi straší…
Jenže pro přechod na 64 bitů není žádný vážný důvod, na to zapomínáte. Mnohé věci stejně zůstávají 32 bitové (hlavně z closed source sw)…
Pořizuji-li si dnes nové PC, bude v něm 64-bitový procesor. Takže volba platformy není otázkou dodatečných nákladů. Vzhledem k tomu, že existují aplikace, které v 64-bitové verzi běží výrazně rychleji, a pod 64-bitovým systémem mohu bez problémů spouštět i 32-bitové aplikace, opravdu nevidím důvod, proč bych měl dnes jako nový systém instalovat 32-bitovou distribuci.
Faktem je, že 64 bitové programy prostě delší jsou, zabírají více paměti také.
Momentálně nemám po ruce stejné aplikace ve 32-bitové i 64-bitové verzi, tak jsem se podíval na knihovny. Největší rozdíl je u OpenSSL, asi 25 procent, ale to je dost specifický případ vzhledem ke specializovaným optimalizacím (také je tu výrazně zřetelnější rozdíl ve výkonu). Vezmu-li třeba libc a libstdc++, dělá rozdíl nějakých 6-7 procent. To opravdu nevidím jako zásadní problém.
IPv4 prostě je zavedené, funguje a s různými triky se vyrovnalo i s nedostakem IP adres
Nevyrovnalo. To jen masáž těch, kdo se živí poskytováním obezliček, které by nad IPv6 nikdo nepotřeboval, přesvědčila většinu veřejnosti, že nedokáže-li se maškaráda vyrovnat s nějakým protokolem, je to chyba toho protokolu, a že je naprosto v pořádku, když se dva počítače v jednom segmentu spolu baví přes server na druhém konci světa.
Jinak aplikace na 64 bitech může běžet rychleji, ale i pomaleji, než na 32 bitech, záleží na mnoha okolnostech.
Poznatky z praxe (aspoň na Linuxu a AMD64) jsou takové, že běží-li něco pomaleji, jsou to nanejvýš jednotky procent a i takových aplikací rychle ubývá, jak se zlepšují optimalizace 64-bitového kódu v gcc.
Zabírat více paměti a zabírat více místa na disku jsou dvě ne zcela porovnatelné věci.
Ani s tou zabranou pamětí to podle mých zkušeností v naprosté většině případů není tak hrozné, jak straší zastánci setrvání u 32-bitových systémů. Víte, čím dál víc mám pocit, že u nich nejde o skutečné technické důvody, ale spíš o potřebu si nějak racionalizovat rozhodnutí, které je vedeno spíše pocitem.
Ohledně IPv6 vidím situaci velmi odlišně od vás, ale to by bylo na samostatnou diskusi.
31.8.2007 14:41
Michal Fecko | skóre: 31
| blog: Poznámkový blog
Jasne ze 32bit system funguje dostatecne dobre. Lidem se v jeskynich zilo take docela dobre. Podle vedcu tehdy lide travili obstaravanim si zakladnich potreb podstatne mensi cast dne nez dnesni clovek.Problem je ze 64b system robi povacsine (zatial) veci zlozitejsimi...
Problem je ze 64b system robi povacsine (zatial) veci zlozitejsimi...
Asi jsem extrémně nevšímavý, ale za ty necelé tři roky, co 64-bitové linuxové distribuce používám, jsem si toho nestihl všimnout… :-)
31.8.2007 14:53
Michal Fecko | skóre: 31
| blog: Poznámkový blog
SuSE? Hmmm a od zaciatku akoze neboli problemy s Operou, flashom, wmv alebo wine ?Asi jsem extrémně nevšímavý, ale za ty necelé tři roky, co 64-bitové linuxové distribuce používám, jsem si toho nestihl všimnout… :-)
31.8.2007 15:12
Michal Fecko | skóre: 31
| blog: Poznámkový blog
Aplikace na x64 může třeba běžet i pomaleji, jak jsem Vás právě donutil přiznat.
Ale ne o tolik pomaleji, aby to bylo aspoň trochu zajímavé. Pokud by tedy nebyla speciálně napsaná tak, aby běžela pomaleji. Zatímco ty, které běží výrazně rychleji, jsou zcela praktické aplikace z reálného života.
Ohledně IPv6 to můžete vidět jak chcete, ale praxe potvrzuje to, co jsem napsal.
Záleží na úhlu pohledu. Podle mne praxe potvrzuje, že setrvávání u IPv4 je především výsledkem dobré mediální práce zájmových skupin, pro které je toto setrvání výhodnější buď z lenosti nebo proto, že na něm slušně vydělávají.
Jsem rád, že jsme se shodli, že jde o peníze, děkuji
Nicméně sledujme pointu - a ta pointa prostě je o tom, že nejprve bylo tvrzeno, že 64 bit aplikace jsou rychlejší, než 32 bitové. Načež jsme se dostali k tomu, že oni nejenom, že nemusí být rychlejší, ale dokonce pomalejší. Tudíž rychlostní benefit není vždy plusový.
Jako celek rychlejší jsou. Pár jich je (velmi) mírně pomalejších, většina je mírně rychlejší a některé jsou velmi výrazně rychlejší.
Samozřejmě souhlas, že tohle neurčuje až tak moc zda se budou používat 64 bit systémy.
S tím souhlasím. Problém je jako obvykle spíš v hlavách lidí než v technologii.
Geniální argumentace. Nejdříve mě mírně zpochybníte jiným úhlem pohledu, abyste pak napsal naprosto to samé co já
V tom, že jde o peníze, se shodneme, ale to je asi tak všechno. Vy tvrdíte, že IPv6 nepřináší nic moc užitečného, aby to opodstatnilo jednorázové investice do přechodu, a proto se nepřechází. Já tvrdím, že IPv6 přináší naprosto zásadní vylepšení síťové komunikace, ze kterého by koncoví uživatelé v důsledku profitovali. Ale že je tady významná brzdná síla v podobě poskytovatelů určitých služeb a síťové infrastruktury, kteří si udělali výnosný byznys z poskytování služeb, na kterých by se po přechodu na IPv6 nedalo vydělávat, protože by ztratily smysl. V tom vidím mezi našimi názory velmi podstatný rozdíl.
Přirovnal bych to k tomu, že přechod na digitální televizní vysílání se u nás tak neskutečně vleče ne proto, že by divákům nic nepřinesl, ale proto, že je tady značná finanční síla v podobě TV Nova, která má enormní zájem na tom, aby byl přechod co nejpomalejší, a prostředky k tomu, aby tohoto cíle dosáhla.
A o tom to je, pane
A na zákazníky alias koncové uživatele se vcelku kašle a neinvestuje se do nich, pokud investice nepovede k pořádnému vyždímání penez z těchto koncáků.
Už dávno neplatí náš zákazník, náš pán. Ale klaníme si zisku, nikoli profitu zákazníků, pokud z toho nevyplyne i ten profit společností.
Ale raději už končím.
Ještě jsem zapomněl:
Ano, stejně tak jako si lidé mnoho let pořizovali 32 bitový procesor a ještě mnoho let na něm provozovali 16 bitový systém.
Ale ne proto, že by si to tak vybrali. Microsoft, věren své tradici tahouna pokroku, přišel se systémem využívajícím možností 386 "už" nějakých 7-8 let po jeho uvedení na trh. Linux 16-bitovou nikdy verzi neměl, jak to bylo s OS/2 nevím. Tedy úplně jiná situace než dnes, kdy si linuxový uživatel (a o těch se tu bavíme) už 2-3 roky může vybrat, zda si nainstaluje 32-bitovou nebo 64-bitovou verzi distribuce, přičemž se obě instalují a používají stejně pohodlně a prakticky stejně i vypadají.
Jako vždy uvádíte nepřesné informace.
Nepřeháníte to trochu?! Opravdu chcete tvrdit, že vždy uvádím nepřesné informace?
Kdyste to vzal skutečně z celkového hlediska jak to bylo, tak 16 bitový systém prostě na tehdejším výkonu, který měl hw běžel velice svižně, zatímco 32 bitové systémy se loudaly takovým způsobem, že jste se u práce bez problémů i nasvačil při čekání na reakci počítače.
Abych byl v obraze: o kterých 16- a 32-bitových systémech (a které době) to teď mluvíte?
Microsoft udělal naopak velice chytré obchodní rozhodnutí, když dělal systémy, které v pohodě utáhl hw té doby. K čemu byla OS/2, která byla plně 32 bitová, když vyžadovala pro slušný běh řekněme 16 MB paměti v době, kdy 2 MB RAM byl standard, 4 MB RAM luxus a každý MB paměti stál hrozné tisíce?
OS/2 jsem sice aktivně nepoužíval, ale znal jsem v té době pár lidí, kteří ano, a o tom, že bez 16 MB slušně nefungovala, se nikdy nezmiňovali. Že by se mi v roce 1994 Linux proti kombinaci DOS 6.2 + Windows 3.1 na stejném železe nějak plazil, toho jsem si také nevšiml. Kdybych měl srovnávat srovnatelné aplikace, tak třeba TeX z Linuxu byl sice o něco pomalejší než Mattesův 32-bitový emTeX s EMX extenderem (mimochodem vyvíjený právě pod "nepoužitelnou" OS/2), ale rychlejší než 16-bitový emTeX. A pokud jsem do hry zapojil (podle vás efektivní) Windows 3.1 na jedné straně a (32-bit, tedy podle vás neefektivní) XFree86 na druhé, ten rozdíl se výrazně snížil. Takže si o pravdivosti vašich tvrzení dovolím na základě osobní zkušenosti pochybovat.
Dokonce jsem některé věci dělal i na 16-ti bitovém Smalltalku, který se prostě bootoval z diskety a nahrazoval zcela operační systém, takže byl sám operačním systémem se vším všudy i s celým grafickým prostředím běžícím v protected módu 286. Jinak ale samozřejmě kraloval DOS, jeho nadstavby, konkurenční implelementace, kde byl oblíbený DR-DOS a NovellDOS s podporou adresářových práv a s multitaskingem. K tomu existovaly pak různé 16-bitové nadstavby jako Desqview a další, které rozšiřovaly schopnosti DOSu. Pak tu samozřejmě existovaly různé 16 bitové verze Windows postupně s různými adoptovanými 32 bitovými schopnostmi.
Jinak také byl hodně rozšířený Netware, tehdy začínal také jako 16 bitový systém. Do plně 32 bitového systému se Netware dostal tuším 9 let po svém zahájení. Takže i tam se začínalo na 16 bitech.
A používalo se toho mnohem více, ale nemá smysl tohle všechno vzpomínat. Jen mě prostě vždycky hrozně udivuje co vždycky o těchto dobách tvrdíte - a je to dost out of reality.
Ok, omlouvám se. Jediné co mohu tvrdit je, že vždy uvádíte pouze část fakt, která podporuje Váš záměr a nezmiňujete se o faktech proti. Od důvodu přechodu z 16 na 32 bit, ohledně údajné vždy vyšší rychlosti 64 bit programů, atd...
Můžete mi ukázat, kde konkrétně jsem v této diskusi napsal, že jsou 64-bitové aplikace vždy rychlejší než 32-bitové ekvivalenty? Pokud nemůžete, poprosil bych vás, abyste mou údajnou manipulaci s fakty přestal zakládat na tvrzeních, kterých jsem se nedopustil. Nebo jen pod slovem vždy rozumíte něco jiného než já?
Co se týče vašeho přehledu systémů, je sice rozsáhlý, ale neodpovídá na mou otázku. Takže ji zkusím zformulovat ještě jednou: na které konkrétní dvojici 16-bitového a 32-bitového systému s aspoň přibližně shodnou funkčností zakládáte své tvrzení, že 32-bitové systémy byly výrazně pomalejší než 16-bitové? A o kterou dobu se přibližně jednalo? Já jsem rok 1994 zmiňoval proto, že teprve tehdy jsem měl možnost udělat si přímé srovnání ekvivalentní 16-bitové a a 32-bitové aplikace (vyšlo výrazně ve prospěch 32-bitové verze). Pokud by mělo jít o celé operační systémy, pak jsem takovou dvojici neměl k dispozici nikdy. Jestliže vy ano, rád bych věděl, které to byly a kdy to bylo.
prostě mluvíte o plusech, aniž byste se zmínil o mínusech
Není třeba, na to jsou v této diskusi přinejmenším dva jiní… :-) A právě to, že kdykoli přijde řeč na porovnání 32-bitových a 64-bitových distribucí, objeví se pár lidí (a tím nemyslím zrovna vás), kteří začnou rezolutně prohlašovat, že 64-bitový systém nepřináší prakticky žádné výhody, ale zato spoustu problémů, cítím potřebu taková tvrzení korigovat.
Ale opravdu si myslíte, že všechny ty firmy co poslaly do světa operační systém byly debilové a jejich tvrzení, že 16 bitový, nebo částečně 16 bitový základ systému do jednoho unisono obhajovali větší rychlostí z důvodu nekompetentnosti?
Ne. Vysvětluji si to tím, že tehdy nešlo zdaleka jen o přechod z 16-bitového režimu na 32-bitový, ale hlavně o přechod z 8086 na (nepříliš šťastný mezistupeň 80286 ponechme stranou) 80386 s velmi odlišnou filosofií, systémem ochran, stránkováním paměti atd. Není divu, že to nebylo ze dne na den (i když to asi mohlo být rychlejší). Proti tomu je přechod z 32-bitového Linuxu na 64-bitový celkem oddechová záležitost. Právě proto jsem se ptal, jestli vaše tvrzení o pomalosti 32-bitových systémů vychází ze srovnání 16- a 32-bitového systému přibližně stejně schopných systémů. Protože postavíte-li na jednu stranu DOS + Windows 3.1 a na druhou Windows 95, Linux nebo 32-bitovou OS/2, pak to rozhodně za takové srovnání považovat nelze.
Proč ještě Windows 95 asi mělo v sobě 16 ti bitové části? Myslíte, že by pro Microsoft nebylo jednodušší udělat plně 32 bitový systém?
Není to zdaleka jediný případ, kdy Microsoft upřednostnil zpětnou kompatibilitu před technicky lepším řešením. Z obchodního hlediska je to celkem pochopitelné a obchodní hledisko je u Microsoftu logicky nadřazeno technickému.
Nevím co jste srovnával, ale otázkou je zda srovnáváte srovnatelné, tedy grafické systémy se vším všudy na hw, který tehdy byl. Zkuste si třeba na té nejméně výkonné konfiguraci, na které ještě plně běží svižně Windows 3.1 rozjet ten Váš slavný Linux v grafické verzi.
Srovnával jsem (na stejném počítači) rychlost stejné aplikace (TeX) pod Linuxem na jedné straně a pod DOSem na druhé straně. Nejrychlejší byla 32-bitová DOSová verze (portace z OS/2 za pomoci EMX extenderu), uprostřed Linuxová (klasická web2c), nejpomalejší DOSová 16-bitová verze. Když jsem na jedné straně přidal Windows 3.11 a na druhé XFree86 + fvwm, byla sice DOSová 32-bitová verze pořád rychlejší, ale rozdíl byl zhruba poloviční oproti prvnímu měření (20-30 procent v prvním případě, 10-15 ve druhém). Vždy ale byla 32-bitová verze TeXu (ať už pod 32-bitovým nebo pod 16-bitovým systémem) rychlejší než 16-bitová (pod 16-bitovým systémem).
Snad by bylo dobré podotknout, že většina těch 16 bitových systémů používala protected mód,
Důvodem setrvání mohla být u těchto systémů i snaha, aby systém fungoval i na 286. On je docela rozdíl, jestli se bavíme o systémech, které vznikaly na konci osmdesátých let, nebo o těch, které vznikly v polovině let devadesátých (vy to střídáte tak rychle, že si nejsem pokaždé úplně jistý, kterou dobu máte zrovna na mysli).
Plně 32 bitové Windows je zpětně kompatibilní také
Nejsou. Při přechodu na plně 32-bitové prostředí jsou s řadou DOSových aplikací potíže. Například řada her se dala spustit pod Windows 95, ale pod Windows NT ne (a netýká se to samozřejmě zdaleka jen her). Zejména u uživatelských počítačů je tohle velice silný argument.
Další odstavce nemá smysl řešit, vy prostě pořád vycházíte z předpokladu, že na stejném hardware (386) je 32-bitový kód a priori pomalejší než jeho 16-bitový ekvivalent, zatímco měření, která jsem v té době dělal, ukazují opak. Tím pádem vycházíte z axiomatiky, která není kompatibilní se světem, ve kterém jsem tehdy žil, takže nemá smysl snažit se přesvědčit vás argumenty.
Souhlasím pouze s tím, že to pro Microsoft bylo obchodně správné rozhodnutí, ale důvodem podle mne nebyla (vámi prosazovaná) extrémní pomalost 32-bitových systémů, ale kompatibilita s původními aplikacemi. Kdyby totiž byly 32-bitové systémy tak strašně pomalé, jak tvrdíte, bylo by lepší udělat 16-bitové i Windows NT. Z technického hlediska ale bylo lepší udělat systém plně 32-bitový, s plně funkčním systémem ochran a bez dalších kompromisů. Jenže zvítězila kompatibilita, stejně jako třeba u procesorů: Itanium možná bylo navrženo z technického hlediska lépe, ale prosadila se až platforma AMD64. Proč? Protože nabídla možnost spouštět nezměněný kód přeložený pro starší modely (a díky tomu tahle diskuse může vůbec existovat :-) ).
Třeba Windows95 nefungovaly na 286 ani náhodou, minimum byla 486.
Windows 95 ale také vznikly o dost později než ty systémy, které pracovaly v protected modu, ale byly konstruovány jako 16-bitové. U Windows 95 byl důvod, proč kombinovaly 32-bitovou a 16-bitovou architekturu, jiný. Opravdu si nemyslím, že lze házet do jednoho pytle pozadí vzniku 16-bitových unixových systémů na konci osmdesátých let a pozadí vzniku Windows 95 v polovině let devadesátých.
Ale no tak. Budeme se tu hádat o každou kravinu? DOSovské aplikace si zvykly sahat leckam přímo a mimo jiné i na porty hw. Windows95 tuhle vlastnost emulovaly (ale přístup na porty byl mnohonásobně pomalejší, než v čistém DOSu).
A právě kvůli tomu tam byly ty 16-bitové části. Ne kvůli nějakému zrychlení systému.
V dalším textu už zase vycházíte z postulátu, že 32-biotvý kód je a priori výrazně pomalejší než 16-bitový, což odporuje mým zkušenostem i měřením, takže na to nemá smysl, abych reagoval. Jen…
Ale fuj. Držme se tématu, prosím. A to téma rozhodně není platforma AMD64. Tam jsou zase síly rozdané jinak, proběhly věci jinak atd..
Možná jste to už zapomněl, ale hlavním tématem této diskuse ve skutečnosti je platforma AMD64 - a to, zda je na ní vhodnější používat 32-bitové nebo 64-bitové linuxové distribuce. Ale hlavně důvod, proč se Itanium prakticky neujalo, zatímco AMD64 (byť čistě technicky v mnoha ohledech horší) ano, je velmi podobný hlavnímu důvodu, proč zákaznická veřejnost nebyla ochotna v první polovině devadesátých let přijmout plně 32-bitový systém s čistou architekturou a místo toho nadšeně akceptovala paskvil Windows 95, který jim ale umožnil převzít beze změny prakticky všechen software, na který byli zvyklí.
Ad 1: v tom se prostě neshodneme. V roce 1995 byl už hardware dostatečný i na čistě 32-bitový systém, což lze ostatně doložit i několika praktickými ukázkami (včetně jedné přímo od MS).
Ad 2: přes opakované upozornění pořád mícháte dohromady dvě zcela odlišné situace, které dělí dobrých 8-9 let: rok 1986 na jedné straně a rok 1995 na druhé straně. Přes opakované upozornění dále odmítáte upřesnit, kdy vlastně mluvíte o které z nich. Takže na jedné straně sice mluvíte o vydání Windows 95, ale na druhé se tváříte, jako byste ho datoval do doby, kdy 4 MB paměti byly luxusem. Co se týká měření, jasně jsem tu napsal, co jsem měřil, vy to holt ignorujete, svá vlastní měření neukážete, ale o to razantněji tvrdíte, že 32-bitový kód je výrazněji pomalejší. Obrázek ať si udělá každý sám.
Ad 3: zase nerozlišujete, o které době z rozsahu 1986-1995 to vlastně mluvíte. OS/2 sice uměla spouštět DOSové programy, ale zdaleka ne všechny.
Ad epilog: vskutku hodnotný "argument". Prohlásíte tvrzení oponenta za nesmyslná a proti jeho odpovědi se pojistíte prohlášením, že odteď už nebudete nic číst, a tedy ani na nic reagovat. Pro mne za mne, klidně si zacpěte uši jako malé dítě, když se pak budete cítit lépe. Vaše tvrzení se tím ovšem nestanou ani o chlup věrohodnějšími.
Proč ještě Windows 95 asi mělo v sobě 16 ti bitové části?protože si s sebou vláčely kámen zpětné kompatibility a tuny starého balastního kódu win95 bootovaly z DOSu, to už bylo zapomenuto?
Myslíte, že by pro Microsoft nebylo jednodušší udělat plně 32 bitový systém?to také udělal, a ten systém se jmenuje Windows NT ... pardon že to říkám, ale zatímco MK se možná dopustil několika nepřesností tím, že nezabíhal do nepodstatných detailů, ty svoji argumentaci stavíš vyloženě na vodě
je docela zarážející, že tehdy nikdo nehoroval pro setrvání u 16-bitových systémů
Tehdy totiz bezna velikost pameti dalece presahovala 64 kB a jednoduchost adresace cele pameti ve 32bit rezimu je obrovska vyhoda. Takovou vyhodu dnes 64bit systemy pro pocitace, ktere maji 3 GB RAM nebo mene, neprinaseji.
Kdyz to shrnu - co prinasi amd64 proti i386?
1) 64bit pointry
2) 64bit integer operace
3) dalsi drobne vyhody (napr. vetsi pocet registru)
1) je znacna vyhoda pro systemy s vice nez 3 GB RAM, mirna nevyhoda pro ostatni (odmyslim-li mmapovani velkych souboru, obskurni triky jako ukladat si flagy ve vyssich bitech pointeru a operacni systemy zalozene na koncepci jednoho pametoveho prostoru pro vsechny procesy).
2) je vyhoda pro programy, ktere takove operace intenzivne vyuzivaji, ale je tezko rici, jak caste jsou takove programy.
2) je vyhoda pro programy, ktere takove operace intenzivne vyuzivaji, ale je tezko rici, jak caste jsou takove programy.
Nedávno se tu v jedné diskusi ukázalo, že nejde zdaleka jen o aritmetické operace, ale že možnost pracovat se 128-bitovou hodnotou v jedné instrukci je hodně znát třeba i na rychlosti funkcí memset() a memcpy(). Takže podle mne je takových programů více, než si myslíme.
možnost pracovat se 128-bitovou hodnotou v jedné instrukci je hodně znát třeba i na rychlosti funkcí memset() a memcpy()Jo, to je pravda - pokud nebude dana operace blokovana rychlosti cache nebo RAM.
predpokladam ze 64b je buducnost a ze buduce procesory pojdu tymto smerom, a je otazka casu ako dlho bude kralovat 32b este..
Letmý pohled do aktuální nabídky jakéhokoli prodejce hardware nám prozradí, že 32-bitové procesory (bavíme-li se o PC) už dávno dokralovaly.
30.8.2007 12:19
