Názory k článku Podpora 32 bitů v distribucích? Možná už zbytečný luxus
Článek je starý, nové názory již nelze přidávat.
-
xxxxx (neregistrovaný) ---.142.broadband5.iol.cz
Omezím se na PC. Linux 16 bit snad ani nebyl (v principu) a jiný unix-like pro PC (tuším něco bylo) byl ještě okrajovější záležitost než později Linux. Sice procesor 286 už měl protect režim a lepši možnosti, ale bylo to takové nějaké divné, bez těch 32 bit.
U Windows byl zlom, pro W95. Tam to bylo spíše naopak. 16bit pod W95+ tuším fungují, ale pokud už se něco dělalo pro W95, tak prakticky rovnou 32 bit. A logika byla spíše obrácená, do WfW (Win 3.11) se doinstalovával win32s, aby tam mohly fungovat i 32bit aplikace (byly-li napsány kompatibilně, mohly běhat i pro w95 i w311, 32 bitově).
Ostatně, přechod 16->32 na PC byla tenkrát značná výhoda pro programátory a programovací styl a 32 bit se snažilo roubovat na i DOS jak to šlo (třeba dos4gw). Něco takového, taková výhoda, u přechodu mezi 32->64 není, alespoň ne tak citelně. Proto to jde tak pomalu.
-
mhi (neregistrovaný) 185.51.248.---
Z dostupnych Unixu byl 16bit tusim Minix, ale urcite QNX. Nedavno jsem nasel k nemu dokonce nejake prirucky ze Slusovic.
Ciste 32bit Windows (tehdy NT) byly dost peklo, padalo to rekl bych i vic nez W3.11/W95, tedy alespon ja jsem je pouzival a programoval pro ne dost nerad. Na druhou 16bit kod byl sileny, treba OS/2 byl mix 16 a 32bit kodu, silena patlanina. Jsem opravdu rad, ze ta doba je uz pryc.
Na desktopu je 64bit spis ke skode, vede to ke vzniku aplikaci ve stylu "pameti je vzdy dost".
-
No a neni snad pameti dost? K cemu potom ta pamet teda pak asi je? Prave na desktopu to ma tu podstatnou vyhodu, ze je tvorba "bezneho" softwaru cenove dostupna i malym/nezavislym vyvojarum a neprodrazuje vyvoj zbytecnymi naroky na zvoleny programovaci jazyk ci optimalizace kdyz to ta aplikace nepotrebuje. Pri cene pameti je uplne jedno jestli aplikace zere 15MB nebo 150MB, v cene pameti je to asi 20kc. Porad mi unika kde je realne "ta skoda" ke ktere to vede. Cele to je pseudoproblem a vznikla skoda je pouze v tve hlave, protoze ti to prijde jako plytvani...
Samozrejme tim neobhajuju rozbite aplikace, ktere zerou pamet, protoze maji memory leak nebo neco podobneho. Obhajuju tim aplikace, ktere jsou psane ve vyssich jazycich nebo tahaji velka data do pameti, prestoze driv by museli vymyslet zpusoby jak toto obejit, dnes jim to usnadni praci.
-
mhi (neregistrovaný) 185.51.248.---
Pisete to dost vazne, skoro bych jinak rekl, ze to je ironie.
Problem to je v tom, ze dneska udelate aplikaci, ktera pracuje treba na 10 MB daty a sezere u toho giga pameti. Za par let se ta data rozrostou na stonasobek a najednou je problem. Taky nepocitate s tim, ze blbe napsanou aplikaci pouziva treba tisicovka lidi ... a kdyz chcete o giga pameti vic, tak ji vlastne chcete vic o tera.
V praci slycham podobne nazory jako ty Vase, "koupime RAMku" a nebudeme to resit. Zakaznici koupi RAMku a nebudou to resit. Pritom jedna z konkurencnich vyhod naseho produktu je prave sviznost a male naroky na HW. Ale bojuju s tim svym "zpatecnictvim" porad ...
-
Trident (neregistrovaný) 193.86.243.---
Co je levnější? Koupit paměť a nebo platit vývojáře? Co je levnější? Koupit pár TB RAMi , do toho nahrát celou db a nebo optimalizovat či koupit plne pole SSD?
A není náhodou že kultura kolem Unixu hodně dbala na velké množství paměti. Téměř jsi si mohl být jist ,že unixak bude mít na svých strojích aspoň o třetinu víc než widlari. Proč asi. -
ass (neregistrovaný) 160.44.230.---
špatně položená otázka, nebo schválně položená tak aby vyjmula většinu kupujících aplikací?
Tak, pro mě jako kupujícího je "nezajímavá informace o platu", protože mě zajímá konečná jednotková cena aplikace, apokud optimalizace konečnou jednotkovou cenu nezvýší nad cenu paměti, tak mi je to jedno, ALE otázka pro tebe, kolik to zdražení bude?
Myslím, že u plikace 150kč navýšení na 200kč, mi neodůvodní koupi nové paměti za 1000kč. A u velkých firem, zase konečná cena na optimalizaci bude většinou menší než koupět 2xdražšího serveru...Ono je to dnes spíše o tom co se používá za programovací jazky, a jak dneska "programátoři" píší aplikace... Primárně tedy není problém optimalizace jako taková, ale nechopnost nastaveného systému produkovat, kdysy standartní programy.
-
j (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----
Se podivej kolem, naprosto zarnej priklad ... a do jde o blbej web. 10x se zvedne velikost, kod jeden bug vedle druhyho, a vysledek je jeste ten, ze je to 10x horsi nez 10let stara verze.
Kolega o vikendu patchoval ERP ... rikal, ze tentokrat to bylo OK, ze se to zhroutilo jen jednou, a ze pak travil jen hodinu odklikavanim dialogu, ze to vazne ma ignorovat ze ta stejna verze uz tam je.
-
No tak ono to není jenom o programátorovi, že...
Když píšu v C, mám třeba 10MB dat, nějaký zásobník, pár proměnných a je to. 5MB RAM + data, když to blbě jde.
V C++ je to veselejší. Taková třída, ta si s sebou nese svou identifikaci, VMT, odkaz na typ, odkaz na typ předka a další režijní věci. Takže pokud v tom člověk dělá rozumně, zase to sežere kus RAMky. Ale to se furt dá ušetřit na opakování kódu pro různá data.
Pak to povýšila technologie COM, ono se GUID + reference counter + ... asi ukládá ve vzduchoprázdnu. Pro každou instanci, že.
Ale to nestačilo, takže nastoupily frikulínský technmologie Java a C#. Ok, nic proti myšlence, že číslo je objekt, ale na int32 jsou potřeba všechny opičárny kolem (řekněme 256B). Definuješ enum se 100 položkama, v C nestojí nic (tam si hodnoty jenom pamatuje kompilátor během překladu), v Javě nakaká do výslednýho kódu 25 kilo+ jména hodnot. A to člověk nemá pod kontrolou uvolňování RAM, takže programátor nemusí něco řešit - za cenu, že nepoužívaný seznam objektů zůstane v RAMce týden, než se garbage collector smiluje (a nemůže to ani ovlivnit, ani zjistit). No a na to, že v RAMce bude binárka, zapomeňte. Ona tam je, ale ne v ASM toho konkrétního CPU, ještě tam musí jet virtuál, který potřebuje někde zahnízdit svůj kód a ukládat data, přeložený pahýl kódu,... 3x fuj.
A když nad tím někdo ještě nasadí hyperfrikulínský mega super framework, který ke každýmu znaku přidá i barvu v RGBA8888, pointer na další znak ve stringu, pointer na nadřízený objekt, název a velikost fontu, souřadnice na obrazovce, počet prohlídnutí znaku uživatelem, statistickou četnost v textu,... jenom pro případ, že by to někdy někdo potřeboval, tak je vymalováno úplně.
Klasická obluda hladová je web browser. Řekněme, že má zobrazit prostou textovou stránku, která má 1MB a je na ní 100 tagů. Narve to do DOM stromu, pro každý tag hierarchicky jedna instance nějaké třídy, velikost bez textu řekněme 250B. Jenom DOM strom pak sežere 1+2.5 = 3.5MB. Ok, máme zparsovanou stránku, jdeme na CCS. 20 stylů, každý má popis třídou velikosti 5kB, jsme na 35,6MB. A přidáváme Javascript, interpretace pomocí zásobníku, pár proměnných, no zaokrouhleme to na 38MB. No a ještě to potřebujeme zobrazit, takže jdeme udělat renderovací model. Odstavce, řádky, objekty na řádku (hyperlink odkazy,...) a prásk, model pro renderování má 2MB. Takže 40MB celkem, jdeme renderovat na canvas. 32bpp, velikost malinkýho okna řekněme 800 řádků po 1000 pixelech, zase 3.2MB, jsme na cca 44MB dat. Bez obrázků, animací, zvuku a plug-inů, jenom s textem, stylama a Javascriptem. S kódem prohlížeče není problém zabrat 50MB na zobrazení 10MB stráky.
Ale uznávám, že programátor udělá hodně. Když bude nějaký expert tvořit spreadsheet, co buňka to instance třídy velikosti 200B + obsah buňky, + velikostpointeru*(početsousedů+početnakombinovanýchstulů+počtrodičů) + uživatelskéatributy + kdovícoještě a tabulka bude mít 32768*512 buněk, tak by ho měli pověsit na hák za přirození.
-
V podstate souhlas az na ten Int32. Ten je i v jave porad Int32 (Int), takze pole int[10000] bude mit napriklad 16+4*10000 bajtu (tech 16 bajtu je hlavicka objektu, nekdy je to min nekdy vic, tady do toho padne jeste atribut len; navic i alokator v nativnich jazycich bude provadet zarovnani, takze tady je to minimalni rozdil). Navic static final int se pro prekladac chova presne jako konstanta v C, tj. ten atribut je pri prekladu nahrazen svou hodnotou (v bajtkodu se nenacita zadny atribut, ale pouziva primo jeho hodnota, treba 42).
-
Petr M (neregistrovaný) ---.145.broadband16.iol.cz
Popravdě, tohle jsem střelil od boku, v Javě jsem zkusil jenom Hello Word, dělám spíš jednočipy. A tam si kouzla s Javou člověk 5x rozmyslí... Třeba u aktuálního projektu by se pár featur z Javy šiklo, ale když CPU má max. 180MHz a Java chce min. 500MHz :/...
Jinak se omlouvám za pár chyb v tom příkladu s webovým prohlížečem. To dělá ten přechod ze zimního spánku na jarní únavu.
-
V pohodě, já jen, aby se zbytečně nestrašilo, že úplně všechno je v Javě strašně paměťově náročný - toto jsou dvě výjimky z toho pravidla :-)
Na jednočipy to určitě není, což je paradox, protože Java takto kdysi byla prezentovaná - tuším Suňáci udělali nějaké ovládání dveří v Javě, ale potom se to celé posunulo do obří JVM a k serverovým službám (kde to Javě naopak velmi sluší).
Možná ale možná by tam šlo nějak napasovat K Virtual Machine (https://en.wikipedia.org/wiki/K_virtual_machine), ale nevím nevím. Btw. jeden borec udělal interpret Javy pro Spectrum, ale samozřejmě bez knihoven :-)
-
Ono to až tak moc nebolí. Ono to nebylo jenom o Javě, tu jsem chtěl hlavně na GUI. Ovladače grafiky byly taky hodně divoký. Hardware používá ARGB, dodaný binární blob samozřejmě jede jenom v BGRA. Takže sice to mělo funkci, která dělal blending dvou bitmap pomocí 2D akcelerátoru, ale prvně to proběhlo v cyklech obrázky a pixel po pixelu přeházelo barvy, potom projelo akcelerátorem a pak zas pixel po pixelu konvertoval výsledky. A ještě to ti frikulíni zkompilovali bez podpory FPU, takže to ani nešlo slinkovat bez dvou hodin googlení, jak na to. Nechápu jejich myšlenkový pochody.
Nakonec se ukázalo, že stejnou službu udělá FT813Q připojený po QSPI, s vyhozením SDRAM pro framebuffer to cenově vyjde líp. Jako bonus ušetřený piny a menší pouzdro levnějšího CPU. A místo rozčilování s dementníma knihovnama a potroublým JVM, nakynutým jak těsto na lívance v pohádce Byl jednou jeden král, řešením licencí a podobně mám za stejnou dobu čistou aplikaci pod FreeRTOSem a šlape to jak hodinky.
A proti frameworkům v C# je to ještě furt sranda. Klika, že si vystačím s C.
-
Všichni, co reagujete, lítáte z extrému do extrému, což mě ale vůbec nepřekvapuje, vše je totiž černobíle... že? Naprosto to ale krásně ilustruje důvod, proč tahle diskuze vůbec vznikla. Ukazuje to, že pro spoustu lidí neexistuje svět mezi "dobrému programátorovi stačí 640kB RAM, pokud ne, tak je špatný programátor, kterého bych ani nezaměstnal jako uklízeče serverovny" a "nenazřaná zprzněná aplikace, co potřebuje minimálně 1GB RAM".
Příklad s aplikací, co žere 1GB nad 10MB daty je též velmi zkreslený... co taková aplikace nad těmi daty vlastně dělá? A co jsou ta data zač? Takové IDE, když se v něm otevře projekt, který má třeba 5-10MB zdrojových kódů a dat, se kterým člověk následně pracuje, se človek dostane lehce na 1GB RAM, je to špatně/špatná aplikace? Je možná paměťově náročná (a to třeba i díky zvolené technologii/jazyku), ale není to pro nic za nic. Otázka taky je, jaká je ůměrnost... 100x nárůst dat nemusí znamenat 100x nárůst paměťových zdrojů. Pokud ano, tak se zde zřejmě bavíme o nějaké specifické výpočetní úloze a tedy použití superpočítače s terabajty RAM při navýšení velikosti vstupních dat je opět naprosto pochopitelné.
Tudíž z toho mi vyplývá, že špatně napsaná aplikace by měla splňovat dvě podmínky a to za a) neměla téměř nic umět (resp. její užitečnost by neměla mít odůvodnění v množství spotřebované paměti) a za b) spotřeba paměti by měla růst řádově společně s velikostí vstupních dat bez pádného důvodu a to až do nerealistický mezí, kdy nejde aplikace nadále provozovat na původním hardware.
Zde se opravdu schodnem, že taková aplikace je skutečně špatná... ale osobně o takových moc nevím a rozhodně se běžně na mém okolí nevyskytují.S tím že aplikace žere v součtu 1TB, když běží u tisíce lidí opravdu nepočítám.... ani nevím, proč bych měl. Z pohledu tvůrce aplikace to je totiž naprosto irelevantní informace. Aplikace žere X paměti, ne X krát počet uživatelů. Pokud tedy nejde o sdílenou aplikaci, která běží na jednom stroji a jednotlivý uživatelský proces zvýší nároky o X paměti. Ale toto je snad ještě divočejší a podivný extrém než to, co už jsem okomentoval výše.
Zřejmě to budu muset říct ještě jednou a po lopatě... protože všichni okamžitě skákají do extrému. 64bitový systém a možnost naadresovat více jak 4GB (3,5GB) není na desktopu na škodu, právě protože nám dovolí provozovat DOBRÉ aplikace psané ve vyšších jazycích, které z principu použité technologie žerou i řádově více paměti. Mezi DOBŘE napsané aplikace osobě řadím i takové, kde autor vedomě a cíleně využívá dostupné zdroje (místo toho, aby vymýšlel a investoval do vývoje jak ty dostupné zdroje NEvyužívat), tedy když nahraje data do paměti celé, místo toho, aby neustále sahal na disk a odtud je pomalu načítal. Toto možná způsobí, že aplikace náhle nežere 50MB, ale rovnou 2GB, ale autor ví, že to nikdy víc jak +-2GB nebude. Vzorným příkladem budiž hry, kde diskuze o tom, že při nárůstu dat naroste i náročnost je bezpředmětná, protože data růst nebudou. Počet textur, modelů a levelů, atd. je jednou daný a hýbat se s ním nebude. Možná jednoho dne přijde modder, který do hry napěchuje nové HD textury... okay, každý pak počítá ale s tím, že hra nebude potřebovat už jen 2GB, ale třeba i 4GB. Příklad, kde velikost dat narůstá a natažení do paměti není reálné je samozřejmě správné vymyslet způsob jak to udělat jinak, asi těžko najdeš někoho kdo bude obhajovat, že pád aplikace na "Out of memory" je v pořádku (v mém slovníku taková aplikace nepostrádá optimalizaci, ale je špatně napsaná... absence optimalizace znamená akorát to, že se v některých aspektech může plýtvat, ne že aplikace padají. To jen pro objasnění, aby někdo okamžitě nezačal něco překrucovat).
Chápeme se? Nechci advokovat špatně napsané aplikace, nic takového jsem nikdy ani nenapsal.
Paměť je k dispozici za nízké částky, dnešní výrobní technologie produkují cenově nejvýhodnější paměťové moduly takové, které už prakticky svádí k použití 64bitového systému, tudíž se takové množství paměti dá téměř považovat za běžné.Paměťové nároky se též zvyšují přirozeným vývojem, co bylo dřív cutting edge a bylo náročné, protože to sežralo celých 50MB RAM!!! dnes logicky nebude žrát 50MB, ale řádově víc, protože účelem je zvyšovat přesnost (např. rendering), ne vždy jde nutně o absenci optimalizací nebo užití méně efektivních technologií. Ale přijde mi, že z tvého pohledu to vše hážeš do jednoho pytle... žere to víc jak před 15lety? Je to špatně napsaný bazmek, tečka.
Hypotetická otázka, která aplikace je horší... taková, která ikdyž napsaná v jazyce umožňující pečlivou správu paměti žere 50MB místo ideálních 5MB jelikož autor neměl čas na optimalizaci (nebo se na ní vyprdl, 50MB je přece ještě ok), tak vše potřebné natáhl do paměti... nebo aplikace, která je psaná ve vyšším jazyce s GC, vše je napsané jak má být, včetně všech optimalizací, přesto stále žere 200MB (protože VM, použitý framework,...), ale stojí o polovinu méně než ta první (protože se to debugovalo rychleji a jedna použitá knihovna hodně pomohla). Obě umí jinak úplně to samé, výkon zde nehraje roli.
Vše je relativní... a nic není černobílé. -
Trident (neregistrovaný) 89.24.136.---
Out of memory muze znamenat ze aplikace je taky blbe nastavena. Typicky limity databazi kde hodne balancujes se zdroji. I tak jednoduchy to muze byt. Taky ze frameworkovy agilni nagelovany result oriented frikulin tezko odladi zakerny memory leaky. Ale u toho disku bych se pozastavil. Ty jako vyvojar na vyssich vrstvach nemas sanci zjistit jestli pro dany soubor se skutecne hrablo na disk nebo do pameti. Pripadne jestli po write nebo close uzavreny soubor byl skutecne z pameti na disk zapsan (dokonce ani unmountu a syncu nemas tu jistotu) pokud na konci neni neco tak deterministicky jednoduchyho jako disketa:)
Denne vidim u devu ze se divi proc uz predtim spustena a znovunastavena aplikace je ted z jejich pohledu 5x rychlejsi a otazka na storage team zni jestli predtim neco neudelali. Jeden by brecel... -
Samozřejmě, určitě ale chápeš, že nemám v úmyslu popisovat každý možný případ, kdy a za jakých okolností může chybový stav znamena to, či ono a co je správně/špatně v programu nebo konfiguraci... už takhle jsem napsal slohovku.
Moje pointa je ta, že pokud vývojář vůbec nehledí na spotřebovanou paměť, může to dopadnout takhle... ať už je to memory leak nebo jen prostě nezájem nebo neznalost. To je samozřejmě špatně. To je však diametrálně odlišný případ od situace, kdy je program "pouze" paměťově náročný... z toho pohledu může program žrát celé gigabajty paměti a být naprosto ok (třeba browsery).
-
SB (neregistrovaný) 78.156.151.---
Já bych to shrnul: Je to něco za něco - když má aplikace žrát víc paměti, musím jinde ušetřit (např. na vývoji použitím vyššího jazyku), jinak je asi něco špatně.
Problémem není, že webové prohlížeče žerou moc paměti, problémem je, co jsou schopni dnes weboví designéři všechno narvat na jednu stránku. -
adam (neregistrovaný) 62.40.0.---
Správný inženýr i ve vysokém programovacím jazyce umí programovat efektivní kód. Kód, který zbůhdarma plní RAM nebo cokoliv jiného, je špatný kód. I JavaScript se dá psát úsporně, resp. může běžet efektivně!
Pokud je funkcionalita stejná, měly by i nároky zůstávat stejné. To bohužel pro většinu věcí neplatí a proto máme textové editory, které se prostě sekají při práci s textovými soubory! -
Nikde netvrdím, že se nedá nebo dokonce nemá psát efektivní kód... Ale předpoklad, že stejná funkcionalita má mít stejné nároky je trošku nerealistická, přece jen když započítáme že taková Java/C# k běhu ještě potřebují VM, hned se dostáváme na vyšší hodnoty. Nebavíme se tu o žádných gigabajtech, jak extrémisti tady rádi rozhazují, ale místo desítek MB už můžeme být i ve stovkách MB. A zde rozhodně nevidím žádný problém.
Též je diskutabilní, co je plnění RAM zbůhdarma... pokud za cenu toho, že sežereme 2x tolik paměti získáme výkonostní bonus, je to též špatně? Podle mě množství spotřebované paměti neříká skoro nic o kvalitě kódu, ikdyž se zde spousta lidí velmi snaží tvrdit opak.
-
Přesně tak. Řekněme, že se aplikace spustí, zjistí si volnou a užívanou RAM. Užívanou vynásobí dvěma a zbytek do celé RAMky si zabere. Je to korektní?
Pokud se jedná o aplikaci na střih videa a bufferuje si tam data, aby se vyhnul hrabání na disku a byl rychlejší, tak si naopak, pokud budu hodně dělat s videem, můžu RAMku přikoupit, aby se s tím dělalo ještě líp.
Pokud to ale bude kalkulačka, tak si její autor zaslouží jenom jedno. Nechat ho bez přístupu k MSDN a bez porna, dokud to svoje dílo nenaportuje do MHB8748 bez externí paměti.
-
Jenda (neregistrovaný) ---.net.upcbroadband.cz
> K cemu potom ta pamet teda pak asi je?
Aby se s ní dal cachovat disk. Aby na jednom stroji mohlo takových aplikací běžet hodně vedle sebe.
> Pri cene pameti je uplne jedno jestli aplikace zere 15MB nebo 150MB, v cene pameti je to asi 20kc.
Krát milion uživatelů.
Osobně se mi 64bit líbí i pro aplikaci co paměť zbytečně nežere, protože si můžu do paměti mmapnout velký soubor a pracovat s ním jednoduše pomocí pointrové aritmetiky.
-
Nevím jak ty, ale já paměti cizím lidem nekupuju :) tudíž mě fakt nezajímá na kolika počítačích daná aplikace běží. Jako uživatele tě pouze zajímá tvůj stroj, a to kolik musíš koupit paměti. Jako vývojáře tě pouze zajímá, zdali jsou paměťové nároky reálné a odpovídají současným poměrům.
Pokud bych chtěl být lehce sarkastický, tak bych podotkl, že jako uživatele tě možná zajimá počet uživatelů z jednoho prostého důvodu... a to že víc prodaných pamětí znamená, že RAM zlevní a tudíž dobře pro tebe. :)
-
Ovsem kdyz zlevni pameti, ze budou skoro zadarmo, tak kdyz mam stroj, kde jsem jiz dosahl HW limitu nebo do ktereho nelze nacpat nove typy modulu, ktere jsou jedine vyrabene v dane kapacite, tak mi to bude platne jak psovi kapsa a zase to skonci koupi noveho stroje, protoze programator je prase. A zase se dostaneme do mikrosoftackeho cyklu, kdy misto pocitacu stale rychlejsich mame pocitae v lepsim pripade stale stejne rychle, protoze vetsi pamet a vykonnejsi CPU jsou pouzity na zamaskovani programatorskych prasaren a na picoviny, ktere k nicemu neslouzi.
-
No já zas nevěděl, že se bavíme o globálním oteplování, světovém míru, smyslu života... a světových paměťových nárocích programu. Vždyť jde o naprosto bezpředmětnou informaci, která může sloužit nanejvýš jako zajímavost. Asi nechápu tvá očekávání,... o čem se podle tebe tady teda bavíme, když ne o přímých a reálných problémech spojených s danou problematikou.
-
Andyone (neregistrovaný) ---.isper.sk
Tebe ne ale support a ekonomicke oddeleni ano. Tva aplikace urcite nepobezi na systemu sama.
Je tam X jinych aplikaci (ted zanedbej pocet uzivatelu a nahrad je poctem aplikaci potrebnych pro chod masiny a spokojenost uzivatele), co musi na te same pameti bezet soubezne. Ekonomicke oddeleni pak musi resit koupi noveho stroje jestli nejde doplnit RAM.
A pak je mozne ze nebudou resit tvoji aplikaci a radeji zustanou na starem zeleze.Taky nemam problem jestli aplikace vyuzije pamet efektivne. Ale plytvat ji neni rozumne a taky neni rozumne spolehat se na to ze uzivatel vymeni stavajici HW (dnes se bez problemu pracuje na 10 let starych dvoujadrech).
-
Zde máš samozřejmě pravdu, toto jsem již shrnul do jedné věty - "Jako vývojáře tě pouze zajímá, zdali jsou paměťové nároky reálné a odpovídají současným poměrům." Jen bych podotkl, že ačkoliv aplikace na PC sama samozřejmě neběží, na druhou stranu platí, že pokud uživatel používá jednu aplikaci, tak s nejvyšší pravděpodobností nepoužívá druhou. Multitaskovat se dá jen do určité míry, asi těžko bude běžný uživatel hrát hru, koukat na video a zároveň browsovat v jednu chvíli.
-
Multitaskovat se dá jen do určité míry, asi těžko bude běžný uživatel hrát hru, koukat na video a zároveň browsovat v jednu chvíli.
Uplne nejvetsi svinstvo pak jsou uzivatele, kteri chteji na jednom serveru provozovat vice nez jednu sluzbu. A ti, co maji terminalovy server a tenke klienty jsou take pekne svinstvo. Oni by snad chteli, aby jim piskvorky nebo solitaire nezraly 2 GB RAM na uzivatele.
-
j (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----
Asi nejsem beznej uzivatel ... bezne mam na primarnim monitoru hru, na sekudarnim browser, kde resim jak obejit ruzny bugy + pripadne chat a na pozadi mi bezi trebas nejakej ten download. A opravdu jsem nadsenej z toho, kdyz widle zacnou zjistovat, jestli nahodou neni nejaka ta aktualizace, a potrebujou na to 6GB ram. Stejne jako me fakt tesi, kdyz po 3 hodinach potrebuju dorazit bose, a browser se zrovna rozhodne, ze je vhodna chvile pomoci nejakyho js neco refreshnout, sezere na to 100% CPU, a bos dorazi me.
-
Trident (neregistrovaný) 89.24.136.---
Pokud je vyvojar drazsi nez nakup vykonnejsiho hardwaru a jeho beh, tak nema cenu snazit se presvedcit nekoho o optimalizacich a o setreni na hw.Skutecne 100tis za vykonnejsi entry level server je v tomto pripade mesic ceskeho seniora/architekta na full time pokud si nerekne jeste vic. Pokud budes nakupovat clovekohodiny tak zaplatis i 5-20kkc za manhour. V USA vynasobit 4x a zvazit o neco levnejsi HW.
Pokud je apka nenazrana vyhradi se ji dedikovany HW. Teprve az kdyz neni mozne do nekonecna zvysovat HW tak se analyzuje kde je problem. Vitej v realnem svete IT.
V porovnani s cenou prace je hardware nesmirne levna vec.Jak vis ze aplikace pouziva pamet efektivne? Nemas od toho zdrojaky a nejsi aplikacni support. Ve velkych firmach kolikrat netusis co aplikace vlastne dela nebo je jednim z mnoha komponent(messaging,mediace atd) ohromne sloziteho aplikacniho ekosystemu.
BTW: V modernich zahranicnich firmach nakup HW neresi ekonomicke oddeleni. To to jen zauctuje do spravne skatulky a posila reporty sefovi aby neprodelal kalhoty. V moderne rizenych firmach mas IT management napojen primo na generalniho reditele/reditele dcerinky/reditele pobocky atd. Kdyby to delalo primo ekonomicke oddeleni tak firmy dodneska pouzivaji mechanicke kalkulacky. To co popisujes je typicky pripad zaprdene ceske IT firmy/statnich instituci.
-
Pokud je vyvojar drazsi nez nakup vykonnejsiho hardwaru a jeho beh, tak nema cenu snazit se presvedcit nekoho o optimalizacich a o setreni na hw.
.........
Teprve az kdyz neni mozne do nekonecna zvysovat HW tak se analyzuje kde je problem.Jestli by nebylo lepsi, kdyby to vyvojar napsal rovnou (skoro) poradne. Pokud nekdo umi psat, tak to take treba vyjde vicemene na stejne clovekohodiny a nasledne se tim usetri naklady za tu analyzu co kde zprasili, pri ktere take muzou zjistit, ze bude levnejsi to cele prepsat. To je rozdil mezi zamestnavanim lepicu a zamestnavanim programatoru. Obavam se, ze kdyby tvurci puvodnich NIXu psali tak, jak je obvykle dnes, tak by se jim na tehdejsi HW vesel tak leda nejaky DOS.
-
j (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----
Neblbni ... vis jak sou zakaznici nadseny, kdyz jim "zoptimalizuju" aplikaci a bezi jim 100 000x rychlejs? Trebas takovej databazovej index je pro spoustu matlalu sprosty slovo. A samo, idealni vazba je pres textovy pole. A vubec nejlepsi je, kdyz appka vytvari do databaze logy ... asi tak 100x rychlejs, nez je zvladne mazat.
-
j (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----
A jako spravnej patlal netusis, ze existuje neco jako server, na kterej se prihlasi 100+ useru zaroven a VSICHNI chteji pouzivat tvoji splacaninu. A pak se resi, ze proste neexistuje HW, do kteryho by se dalo dat dost CPU a RAM, aby se to dalo provozovat jako web browser v korporaci, protoze kdyz si tam 5 lidi ten web pusti, tak to sezere vsechno at uz tam je cokoli.
-
j (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----
njn, kokutek se ozval ... ty demente, bez si nainstalovat DOS. Takovy jako ty dnes a denne resim u zakazniku, ktery nehodlaj kupovat za 10M HW jen proto, ze je nekdo dment a jeho hello world ma 100M (a do toho nepocitam .NET sracky kolem).
Dment jako ty pak povazuje web browser za serverovou aplikaci ... lol. Takovych uz sem par osobne vykop, kdyz prisli nabizet tenky klienty, 100% skoncili prave na webu. A nejen na nem samo.
2Trident: Frikulini jsou vetsinou v riti, jakmile se prejde od vysmatych ksichtu stastnych rodinek na PR omalovankach, k tomu, ze to chcem (ve 2-3) vyzkouset. Ve firme predevsim resis to, ze kdyz neco trva 10minut, je to N^10krat vetsi problem, nez kdyz ti to trva 10 minut doma. N je pocet uzivatelu. Znam firmy, ktery maj tisice zamestnancu ... a resej (naprosto trivialni) ulohu - vypocet mezd. Nektery maj problem stihnout to za 14 dnu spocitat. Prave kvuli takovym frikulinum. Pak se ti i doslova milisekundy hodej, protoze v globale to muze hodit peknych par hodin.
-
Trident (neregistrovaný) ---.sa.cz
Tak pokud se to stále vyplatí, tak se koupí 100 serveru pokud se dá aplikace aspoň nějak skalovat (to je větší problém většiny webových agilnich nagelovanych frikulinu). Na druhou stranu zazijes I případy kdy optimalizace špatně udelaneho query ( za kterou můžou debilní perzistentni vrstvy) ti ušetří nákup nového hw pro další usery. A jede se dal. Ve velké firmě resis stovky aplikaci a nemáš čas zabývat se jednou optimalizaci. Je nutno rozhodnout mezi blbym a blbejsim rozhodnutím protože deva mi vzhledem k ceně nikdo nezaplati.
-
Prave na desktopu to ma tu podstatnou vyhodu, ze je tvorba "bezneho" softwaru cenove dostupna i malym/nezavislym vyvojarum...
Jestli to nahodou nezpristupnuje tvorbu bezneho softwaru lidem, kteri by zadny tvorit nemeli, protoze to neumi. A to, ze maji hafo pameti, je pripravuje o motivaci se to naucit.
-
nobody (neregistrovaný) ---.pel.cz
bych je posadil treba pred tohle ve smycce dokud jim nedojde ze jsou prasata :)
https://www.youtube.com/watch?v=GscAJsfn9qA
Amiga 500 s CPU 7MHz, 1MB RAM a cele na 1x 3.5" DD disketa 880kB ... -
nobody (neregistrovaný) ---.pel.cz
pripadne na stridacku treba s timhle:
https://www.youtube.com/watch?v=EbWG78zsALs
Commodore 64 s 8bit CPU 1MHz a 64kB RAM.. -
xxxxx (neregistrovaný) ---.142.broadband5.iol.cz
Člověk už dost zapomíná na ty méně viditelné, ale o to více zákeřném problémy co byly s 16 bit. A ten úprk a osvobození pod 32.
Problém býval třeba v knihovnách (Pod DOS přímo linkované. Dynamické, podporované OS, byly až na W95/NT. Pokud něco pod DOS, tak každý překladač, někdy i verze, si to dělal po své, pokud vůbec podporoval.). Že linkery tuším měly potíže s přechodem přes segmenty. Takže jednotlivé knihovny (a pak i jednotlivé zdrojové soubory) nemohly jít přes segment (code segment, u datového, statického, to bývala ještě větší legrace), tedy jejich délka byla max. 64K. Takže občas se dělalo umělé rozdělení logických celků, pokud to šlo do knihovny.
Pohrát si v rámci programu s velkou datovou pamětí a ukočírovat segmenty, to byl sice opruz, ale vesměs to měl člověk pod kontrolou už v rámci překladu. Ale externí věci, knihovny, statické velké bloky dat, ..., to musel člověk dělat stojku, aby to linker zchroustal.
on-topic
Sice nyní (přechod 32->64) existují věci, kdy je vhodné mít k dispozici více jak 4GB přímo adresovatelné RAM (3GB, 2GB) či větší aritmetiku (i když ta bývá řešena po svém, často jinak, jiné potřeby). A přibývá takových aplikací. Ale není to až taková všeobecná nutnost a mnohdy jde jen o pohodlí. Nic proti pohodlí /a tím i méně chyb/, ale není to /často/ Killer feature.
-
mhi (neregistrovaný) 185.51.248.---
-off-topic- 16bit: ano, to si zive pamatuji, byla taky hromada prekladacu, k nim dokonce i "extra" linkery.
Moje poznamka k Windows NT mirila spis k jejich nedodelanosti ve verzich 3.5 a relativne i 4, cesta spravnym smerem to samozrejme je.
Obdobna analogie je videt i dneska u MCU, take se misto ruznych i8051 / PIC16 prosazuji architektury, ktere maji cisty design (no, zejmena ARM). Treba u toho PIC16 je z meho pohledu zasadni problem, ze RAMka je segmentovana, takze pole udelate max. 0x100 bytu. Proti tomu PIC24 ma pekny linearni space, hezci instrukcni sadu, atd.
-
xxxxx (neregistrovaný) ---.142.broadband5.iol.cz
Díky moc za opravu. Kaji se, dynamické knihovny podporované "OS" opravdu byly už (minimálně) ve windows 3,x a tuším už i menší (w2x už byly určeny pro 286 a podporovaly chráněný režim, tak možná i tam).
Jen si vzpomínám, že se s .dll muselo nějak hodně opatrně, protože W3x už běžně běžely v protect režimu a zároveň (jak jsem zmiňoval) mohly mít po rozšíření i omezený 32 bit režim, základ však byl stále 16 bit. Nějak mi ten mix a ochrany nedělaly dobrotu pro sdílené věci, tak linkovat staticky byla jistota (ostatně ještě u w95 to bývalo lepší staticky - tam kvůli hw výjimkám /typicky koprocesoru/ kde mi to jinak z .dll padlo natvrdo - ale to mohl být problém Borladnu, protože obsluha hw výjimek (pozor, myslím na úrovni už přeloženého kódu - strojáku) nebyla sjednocena a MS ji měl maximálně jako nedokumentovanou, pokud vůbec jednotnou).
Pod DOS samozřejmě šel napsat a přeložit program (code i data) i pro větší velikost než 64K. Jen se s tím muselo opatrně. Data se dala ošéfovat už na straně kompilátoru a linker to většinou zchroustal ok (i statická data, když si dal člověk pozor). Ale u code mi to fungovalo jen pokud jednotlivé zdrojové soubory (např. .c) v přeloženém stavu nepřesáhly 64K. Totéž knihovny. Jinak měl problémy linker. Mluvím o situaci, kdy bylo odděleno linkování a překlad a použit třeba mix zdrojů a různých překladačů (c + samostatný asm přeložený bokem /ne v rámci c/, ...). Tam býval ten limit 64K code na každý z linkovaných objektů (a tuším to nešlo obejít).
Dynamické loadování "knihoven" (tedy myslím úseků programu samotného) pod DOS (ne pro w3x, díky za opravu) na úrovni OS nebylo vůbec. Pochopitelně si člověk mohl něco udělat po svém /a často dělal/ a někdy to podporoval přímo překladač+linker (např. pozdější Turbo Pascal tuším umožňoval). Ale pak bylo bez šance použít samostatný překlad a pokusit se linkovat .obj pod jiným linkerem než co přišel s daným překladačem a danou verzí překladače. Neexistoval sjednocený přístup.
-
adam (neregistrovaný) 62.40.0.---
Nemohl byste prosim odkazat na zminene prirucky ze Slusovic? Obavam se, ze RetroBSD bude taky 16bit: http://retrobsd.org/wiki/doku.php ale mozna, ze se tam nic takoveho urcit neda...
-
mhi (neregistrovaný) 185.51.248.---
RetroBSD bezi na PIC32, coz je 32bitovy MIPS, akorat ma takovou lehce zkryplenou MMU, takze tam nejde bohuzel pustit normalni OS.
Slusovicke prirucky mam jen tistene. Ostatne mam i nadherne knizky o "dospelem" QNXu + hromadu casopisu, na prelomu tisicileti jsem tim docela zil. Tehdy to byl opravdu velmi zajimavy system (ten "dospely", puvodni 286kovy QNX byl spis takove retro, i kdyz jsem jej take pouzival).
-
mhi (neregistrovaný) 185.51.248.---
Neni mi uplne zrejme k cemu by to nekomu bylo. Prirucky jsem nasel, je to na QNX2, s Unixem to neni 100% totozne (je tam dost rozdilu proti POSIXu resp. tomu co dnes clovek povazuje za Unixovy system). Datum zari 1989 :-). SWS Slusovice prelozili man pages a vydali to jako knizku, dale nejaka prirucka systemu a nakonec textovy editor.
Zrejme ten QNX - original - pujde stahnout zde: https://winworldpc.com/product/qnx/1989-demo
Mam nekde v krabici i ARCnetove ISA karty....
-
muf (neregistrovaný) ---.opera-mini.net
Přechod na 32bitů ze 16 měl nepopiratelné technické výhody i pro běžné uživatele, což se o 64 bitech velmi často říci nedá.
64 bitů je dnes bez debat výhodných pro servery nebo tam, kde provozujete aplikace nezbytně potřebující opravdu hodně paměti. Jinak slouží hlavně mladým divokým radikálům, aby mohli psát hlubokomyslné úvahy na téma, jak je "změna nutná" a uživatelé 32 bitů zaostalí... -
V podstatě masivní nástup W95 to pro BFU vyřešil celkem sám. Dal se "rozchodit" od 386 výš, většina lidí si v té době už kupovala nehorázně drahé 486 a Pentium už se taky dalo za šílený obnos sehnat, navíc ceny šly pak dolů velmi rychle, protože Mooreův zákon ještě platil bez výjimky. A i před tím už se řada SW dělala 32 bit (z té doby si pamatuju hlavně hry), především přes zmíněný dos4gw. Kdo v té době programoval, pro toho byl 32bit jasná volba, já dělal dost v assembleru a omezení 640kB v kombinaci s luxusním adresováním segment:offset mě dodnes dokáže v podobě noční můry vzbudit :D O používání extended memory ani nemluvím (naštěstí nebylo pro takový to domácí lepení příliš často potřeba). Takže stejně jako tenkrát i dnes je jedním z hlavních taháků využití více paměti. Ale zatímco tenkrát bylo běžné, že měl člověk více jak 640kB RAM (alespoň ten ušmudlaný 1MB), omezení 32bit není tak zásadní. Absolutní většina strojů si ještě nedávno vystačila se 4GB a cpát všude aspoň 8 je móda posledního roku, možná dvou (a mimochodem, většinou je to zbytečné).
-
technomaniak (neregistrovaný) ---.cust.avonet.cz
Tak u linuxu ani nijak. Ten se v ČR se rozšířil jako 32bit, 16bit byl snad jenom v úplně počátcích. Poslední počítače běžící bez 32bit, tedy na 16bit byli 286tky, 386tky už podporovaly 32bit.
Ovšem na Windows platformě to bylo docela jednoduché. Trh a realita vytvářela automaticky tlak na přechod.
1) HW zažíval výkonovou revoluci tak rychle, že se hw musel měnit cca 4 roky, což je dneska totální sci-fi
2) SW zažíval dynamiku ve funkčnosti a inovacích, o které se může lidem jenom zdát a tudíž nové verze skutečně něco zásadního přinášely.
Tyto dva důvody stačily pro přechod na 32bit, a lidé ci to prakticky ani neuvědomovaly.
Ve východním bloku hlavním leaderem 32bit byl Windows95, který nabízel přechodem něco nového. Dřív byl DOS+W3.1(či jiná kombinace) a přechodem na W95 člověk získal OS přímo s GUI a ve své podstatě takto velice snadno přešel na 32bit a ani o tom nevěděl. V té době nebyli počítače tolik rozšířené, takže to nebyl takový problém.Navíc W95,W98 nabízel zpětnou kompatibilitu automaticky s 16bit aplikacemi, což ne vždycky nyní zcela funguje. ( viz. řežim kompatibilty ve Windows )
-
No to si takhle jednou idioti od Intelu vzpomněli, že by mohli udělat 16b procesor. Zatím co u 8b se adresovalo 64kB tak, že se spojily dva registry do 16b, oni to tak nemohli udělat pro 32b aplikaci. Asi neměli dost nožiček na pouzdru DIP40. Tak udělali sadu segmentových registrů - pro data, stack, program. A výsledná adresa se počítala tak, že sečetli registr se segmentovým registrem, posunutým o 4 bity. Takhle dostali úžasných 20b adresy (2^20 = 1MiB). Z toho ještě ukousl BIOS a grafika.
A sranda byla i s tím, že při bootu byl program segment registr 0xffff, takže prbní instrukce, vykonaná BIOSem, byla na adrese 0xffff0. RAMka začínala od nuly, takže i test na NULL byl hodně zajímavý (nulu nešlo použít, byla to legitimní adresa v RAMce).
No a dělo se tam tolik divných věcí... Jako že kompletní ukazatel měl 32b, ale adresoval jenom 20b. Zato ale existovalo 4096 možností, jak se odkázat na jednu adresu. No nebyl to jeden z mnoha důkazů, že u Intelů hulej dobrej matroš?
-
j (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----
Tak to kazdopadne, ale vis co se stim vsechno dalo delat?
Treba takovy on demand generovani kodu v zavislosti na tom, jak se vyhodnotily podminky kodu predchoziho. Zadnej problem. Nebo spustit data samo. Navic prave to mapovani do RAMky byl primo genialni napad. Proste sis nekam neco zapsal, a ono se to misto do RAM zapsalo trebas do sitovky ... ;D
-
xxxxx (neregistrovaný) ---.142.broadband5.iol.cz
Moment. Tento komentář jsem moc nepobral.
Není snad mapování hw do RAM, na 8086, až věcí konkrétní implementace? (Zde od IBM, asi myšleno). Naopak už i tím, že 8080, z80 i 8086 má samostatné I/O instrukce (tehdy nebývalo vždy) oddělené od memory adresovacích, tak je to spíše znak oddělení výše zmiňovaného.
Navíc i zmiňované self-modify kódy, správně použity, ušetří spoustu místa. Právě i tou možností zvláštního mapování. Pochopitelně ne v multiprocesním použití (tam je to o hubu až neimplementovatelné), ale na to si Intel 8086 tehdy ještě nehrál.
-
Petr M (neregistrovaný) ---.145.broadband16.iol.cz
Mě hned jeden věhlasný příklad napadá. I8051. 128B RAM, nad tím 128B SFR, na jednom pointeru.
Jenomže kupodivu za čas zjistili, že 128B je málo, tak u I8052 byly SFR přímo adresovaný a nepřímým adresováním na tom samým rozsahu ses dostla k dalším 128B, použitelným třeba jako zásobník.
A ono ostatně celý 8051 je z pohledu pamětí děs běs - RAM, IRAM, SFR, ROM, XROM, XRAM, BOOL. :Q Každý z nich nepoužitelný jiným způsobem. No neměli to už tehdy blbě vymyšlený?
Btw, mohli by jsme udělat anketu o největší koninu Intelu. Moje návrhy jsou:
- Tři úrovně napájecího napětí u 8080 ve s pojení s potřebou dvoufázových hodin s amplitudou 9V
- Adresování u jednočipů řady 8048, 8049, 8051, 8052
- CISCový 8b jádra se spotřebou 12 taktů na instrukci (808x, 805x)
- Segmentování u 8086 -
xxxxx (neregistrovaný) ---.142.broadband5.iol.cz
Segmentování za koninu nepovažuji. To je celkem fajn, pokud se člověk pohybuje v rámci 16 bit a neočekává od toho něco extra více než mírně rozšířené 64K.
... Za koninu považuji fakt, že DOS (a win až do 3.0) se držel 16 bit tak dlouho. Skoro úmyslně. Vždyť i win32s, 32 bit pro windows 3.1x, nebyl ani jeho součástí, musel se doinstalovat bokem a přišel později a nebyl úplně spolehlivý. Přitom 32 bit procesor 80386 vylezl ven už někdy v r. 1986. A co si pamatuji, tak i tady, i přes kritické zaostání dané režimem do 89 (skoro 90), se boardy s 386 kompatibilní (AMD) sehnaly za normální ceny už někdy kolem roku 1992-93. Tady, v ČR (ČSR) sic!
-
xxxxx (neregistrovaný) ---.142.broadband5.iol.cz
Těžko posoudit, v kontextu doby. Pokud se nemýlím, tak 8080 (rok 1974). Konkurenční rozšíření Z80 (rok 1976), styl x86 (roky 76-79, venku tuším ale až 79).
Stále to byl jen 16 bit. Do hlav jim nevidím, ale přijde mi, že to asi nemělo být více, než mírně lepší stránkování, které se s 8080 (resp. Z80) dělalo hw. Ostatně i ta možnost stránkování už předešlé části paměti (tedy "jen" 20 bit) až nápadně připomíná celkem běžné praktiky namapování pouze 32K (či méně) z rozšířených více než 64K do adresního prostoru z80. Vyloženě jako by podprogramy /knihovny/ mohly být small model (do 64k) které neřeší segmenty a mohly být později dynamicky nahrané tam, kde bude zrovna místo, s minimální spotřebou paměti a hlavně obsluhy (bez přečíslovávání pointerů)
Nápad to není špatný. Jen, tou dobou ... 5 let po jejich 8 bitech co už měly adresní prostor 16 bit, to asi chtělo více. Asi plný 32 bit. Spíše bych viděl, že ten vývoj se táhl moc dlouho, že to mělo být venku v roce 76 (na tu dobu by to bylo fajn) a na přelomu 80 už dát plný 32 bit, zpětně kompatibilní.
-
xxxxx (neregistrovaný) ---.142.broadband5.iol.cz
Také mi přijde, že to nechtěli dál táhnout. Že to byl úkrok coby reakce na klony 8080. Taková obdoba-náhrada IX a IY (dalších) adresových registrů. A když už, tak tam doděláme i mapování trochu více než 64K. Abychom "také něco měli". Ale jako by to tam bylo spíše bokem.
Kdyby to bylo rovnou v 8080, tak člověk zajásá, jak je to /na tu dobu!/ celkem fajn. Vždyť, v té době, pro domácí a jednodušší účely, stejně nebývalo paměti tolik. Natož nad 64k.Takže spíše taková možnost mít nativní 16 bit věci + krátký program, posazené prakticky kamkoli.
Možnost mít DS dle svého, i v rámci jednoho programu, se později projevila třeba u objektů. Byla možnost překládat objekty tak, že DS ukazuje na jejich struktury (this). Celkem mi to zkracovalo paměť a zrychlovalo programy a bylo to přirozené. Pokud člověk použil objekty tam, kde dávaly smysl (ne jak dnes, kde se cpou úplně všude). Tam takové mapování vyloženě sedne. A to i přesto, že kvůli tomu muselo být dodrženo správné zarovnávání (nejen) alokace na 16 - tak akorát, ani ne moc ani málo.
-
> Dokazal by nejaky pametnik zavzpominat, jak to bylo u 16->32?
Pamatuju jen DOS.
Hry: bojovaly s omezenim 640kB a pro ziskani par kilo navic na letecky simulator byly potreba velky kouzla v config.sys a autoexec.batA mam pocit, ze v Turbopascalu byl zasadni problem strankovani - alokovat cokoliv nad velikost 64kB.
Mam dojem, ze po prichodu 32bit ten problem s turbopascalem stale pretrvaval, ze se ten 32bit rezim nepouzival "nativne", ale kazdy program dostaval svuj 16bitovy stroj. Pak snad uz slo alokovat na heapu, ale pole na stacku bylo porad omezeno 64kB.Ale taky to mohlo byt trohu jinak, je to uz davno a tohle jsou jen nepodlozene vzpominky. Jestli na to nekdo pamatujete, tak me opravte...
-
j (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----
Jenze 640kB nebylo omezeni 16bitovy arch. I v DOSu se dala pouzivat spousta MB RAM.
Od 286 vejs si moh mit 16MB+, realne ty stroje mely rekneme neco mezi 512k-8MB (nekam do pentia). Problem byl spis v tom, ze se to nikomu nechtelo psat. Ostatne uz na 8mi bitech si moh pouzivat mnohem vic RAM nez povestnych 64kB. Realne klidne 2-4MB. Jen sis musel (pekne sam) implementovat prepinani pametovych bank (a ty moduly si tam pekne rucne pripajet).
V realnym rezimu si moh primo adresovat 1MB, kde si musel jeste pocitat s tim, za cast ty pameti se premapuje ruznym HW + samo trebas mys ... kdyz si chtel adresovat vic, tak si musel prepnout CPU do protected rezimu, coz vyzadovalo to umet (a v packalu si to bez asm samo neudelal).
Kouzleni v config/autoexec pak bylo o tom, ze vetsina tech veci si alokovala nejakou ramku, neco udelala, a pak tu ramku uvolnila (castecne), takze kdyz si to nacet ve spravnym poradi, moh si ziskat tech chybejicich par kB aby gameska sla spustit. Bylo samo treba zvolit i vhodny (a dostatecne maly) ovladac pro mys, pripadne si (nekdy) vybrat, jestli radsi mys nebo zvuk ... ;D. Pak se samo jeste kouzlilo s tim, co se nacpe do himem (= nad tech 640kB), coz s necim slo a s necim ne. Kazdej spravnej gamesnik pak sebou nosil nekolik disket s ruznejma verzema vseho moznyho, a hromadu znalosti o tom, jak tu hru zprovoznit. Soucasnici by z toho umreli.
A co teprve kopirovaci ochrany ... kdy na (originalni) diskete byla umyslna chyba, a testovalo se, jestli to mechanika precte pokazdy jinak == je to orig ... (a pak stacilo v tom exaci zmenit jedno jne na je ...). Jo, a taky v ty dobe jeste existovaly viry ... skutecny, co sa samy sirily a nepotrebovaly k tomu dmenta co klipne na ano. A mely jednotky kB ... to si soucasti patlalove ani nedokazou predstavit. Dneska se do kB nevejde pomalu ani ten int ...
-
darm (neregistrovaný) ---.backer.cz
Úplně jednoduše to nejde, složitost závisí i na distribuci. Určitě bych si před tím udělal zálohu funkčního systému. Jednoduše řečeno se nejdřív nainstaluje a nabootuje 64 bit kernel (tam s 32 bit userspace nemůže dojít k problému), následně přehození repozitářů na 64 bit a opatrný přepis nejdřív základu a pak dalších aplikací. https://wiki.archlinux.org/index.php/Migrating_Between_Architectures_Without_Reinstalling
-
P K (neregistrovaný) 85.93.119.---
Mám starý 32 bitový vrak, který mi na firemní poštu stačí. No ... seriózně ... dnešní distribuce už na 32-bitových mašinách rozchodíte tak maximálně bez grafiky, takže normálního BFU se to určitě nedotkne. No a my ajťáci se s tím nějak popereme (jako kdyby se nás někdy programátoři na něco ptali)
-
Cca od roku 2010 pak téměř neexistuje důvod, proč zvolit 32bitovou variantu linuxové distribuce.
...........
Uživatelé 32 bit používají spíš omylem
A ze ja vul si na vsechny ty 32 bitove stroje nedam 64 bitove distro? Nebo bych je mohl vsechny vyhodit a koupit nove, aby byli frikulini spokojeni. Uz se treba cely tresu na to, kterou srackou s lesklym displayem a chicletovou klavesnici nahradim svuj stary Esus z doby, kdy byly jeste konstruovany poctive, jako slusne notebooky.
-
Tak jo, misto Esusu 1000H s Atomem CPU N270 si koupim modernejsi 64 bitu, jestli takovy existuje. Za jak dlouho se mi investice vrati usporou na elektrice? 20 let? Vzhledem k tomu, jak jsou dnes konstruovane netbooky, se netbook rozpadne tak nejpozdeji za 3 roky. To mame skoro 7 novych netbooku, kousek bratru za 300€.
Na desktopu mam nejake dvojjadro, zapinam to jen obcas, kdyz potrebuji trochu vic vykonu. Za jak dlouho se mi vrati investice? 40 let? Nebo 60?
Jinak te to mozna k smrti vydesi, ale i na starsich procesorech uz take obvykle jsou nejake usporne ficury. Neni nutne si predstavovat hned P4, ktere v tomto ohledu bylo naproste nestesti.
-
Tak jeste se daji koupit na ebay. Treba tajdle: http://www.ebay.com/itm/ASUS-Eee-PC-1000H-10-1-Netbook-1-6GHz-1GB-RAM-160GB-HD-Notebook-Laptop-/321987437877?hash=item4af7f26535:g:PCYAAOSwYaFWe22g 65$ + postovne, jestli muzes zit s americkou klavesnici. Rekl bych, ze az tak moc nejel, protoze na mem je par osoupanych pismenek, znacka u vypinace je skoro pryc a mam dost prosoupany mezernik a nektere klavesy. Ale mam bilou verzi, tak je mozne, ze na ni pismenka drzi hur. Ale majitel na tom ma Linu Mint, takze by z nej mozna sel vymamit vypis SMARTu, kde by snad byl pocet motohodin disku. Muj ma najeto uz pres tri roky.
-
Ja naopak bily chtel, protoze na cerne klavesnici naflakam nekolikrat tolik chyb a cerny ramecek okolo displaye dela unavny kontrast. I proto na nem tolik lpim, protoze soudruzi vyrobci museji vsechno delat pokud mozno antracitove cerne nebo aspon hodne tmave. Ze by se treba odvazili do neutralni sedi nebo bezove, jako kdysi, to ne. A koupil jsem ho s XP, protoze v nekolika kramech, kde jsem se ptal, mi tvrdili, ze bez Widli v CR neni k mani. Dokonce jeden volal do zastoupeni ASUSu v CR a tam mu rekli totez. Takze se divim, ze jsi to sehnal bez Widli.
Jinak disk:
9 Power_On_Hours 0x0032 070 070 000 Old_age Always - 26694.Tak jestli je to opravdu v hodinach a pocitam to dobre, tak neco pres tri roky. Az se divim, ze porad funguje. Je to Seagate Momentus ST9160310AS, 160 GB. Asi ty jejich disky tehdy jeste nebyly tak hrozne, aby na ne lidi podavali zaloby.
-
Jo prodávali to bez Windows, byl tam Xandros, kterej jsem se snažil tak dlouho ohnout do použitelného stavu, až tam nakonec šlo EEEbuntu. Kupoval jsem to, jako vlastně prozatím jedinou věc, od zelenýho mamrda, takže to bylo (05 nebo 06/2008) normálně k mání, ještě bych asi i našel účtenku.
Tak Seagate nebyly špatný, motá se mě tady například 80 GB Barracuda připojená k RPi v režimu 24/7 už kolikátým rokem (a je to darovanej disk, předtím to běželo kdovíjak dlouho někde v servříku, ale SMART přes USB konvertor nefunguje, takže teď přesný informace o power on hours nezjistím). Poslední roky se to evidentně zhoršilo, asi katují kosty nebo co :)
-
Petr (neregistrovaný) 80.78.147.---
Zrovna teď píšu z více než 10 let starýho netobooku, ve kterém je starý Celeron 2.4GHz pochoptelně 32 bit, jen 512MB RAM a disk je tam vyměněný za SSD (starý plotnový začal před dvěma lety umírat). Systém je Debian 8 s desktopem Mate.
Spotřeba je na dnešní dobu asi velká, 28W. Ale při ceně elektřiny zhruba 4,- Kč za kWh mě vychází zřejmě něco jiného, než si představuješ ty. Kdybych měl kvůli spotřebě kupovat nový notebook, tak i nějaký z Tesca za 10 litrů by musel vydržet v nepřetržitém provozu (stále zapnutý) něco málo přes 10 let a to by ještě musel sám mít spotřebu nulovou.
Vzhledem k tomu, že s tím notebookem pracuju v průměru 2 hodiny denně, tak pokud se nepletu, musel bych být na světě ještě 120 let, aby se nový notebook (při předpokladu jeho nulové spotřeby) zaplatil.
Samozřejmě můžeš namítnout, že cena elektřiny půjde v budoucnu nahoru. Ano, určitě. Ale ten novej NTB nebude mít nulovou spotřebu a ani životnost nebude tak vysoká. Takže kupovat nový notebook z důvodu spotřeby postrádá jakoukoli logiku. A to platí nejen u notebooků.
PS. Pokud jsem to spočítal špatně, opravte mne. Rád se poučím.
-
kchae (neregistrovaný) ---.chmi.cz
Nevím, jestli je to dobré. Chodí za mnou lidé, kteří potřebují rozhýbat počítač "jen" na internet a mají pouze počítač po vnukovi/vnučce. Pak nastává problém, že 64 bit ten počítač nikdy neviděl a ani netušil, že to existuje.
Nejedná se o lecjaké PC. Na jednom takovém starém PC zahlásil Chrome, že nemůže provést aktualizaci, protože PC nesplňuje minimální HW požadavky. V takovém případě o 64 bit nelze ani uvažovat a tito důchodci na nový PC, třeba i za 4 000 Kč, nemají.
Když jim nainstaluji (příklad) Xubuntu s FF a běží jim tam Kryštof na youtube, jsou štěstím bez sebe.
Podle článku jsem pochopil, že dokud pojede alespoň jeden internetový prohlížeč na procesoru s 32 bit architekturou a Ubuntu (i jeho odnože) těch 5 let udrží podporu, je možné že za 5 let se začnou ozývat, že jim nefunguje internet? Tedy za předpokladu, že počítač (i uživatel) vydrží. V tomto případě, prosím chápejte, internet=internetový prohlížeč.
-
Nevim, co je na LXDE neporadneho a oklesteneho. Ja na LXDE z XFCE presel proto, ze se mi vic libi a uplne dostacuje. Z XFCE mi chybi akorat casovac na pripravu caje, ktery po nejakem upgradu stejne nefungoval. Nakonec DE je jenom vec, ktera slouzi spousteni aplikaci a sprave virtualnich desktopu.
A to, ze mi prechod na LXDE usetri 100 MB pameti, znamena, ze mam vic pameti na jine veci.
-
nobody (neregistrovaný) ---.pel.cz
nepsal sem ze pustej JEN webovy prohlizec, ale ze zastanci !oklesteneho! prostredi pustej nenazrane chrome a jestli ho pustej pod Xfce nebo Lxde tak prohlizec logicky sereze stejne a to mnOOOhonasebne vice nez kolik resej na usetreni pouzitim !oklesteneho! prostredi... takze se zas uklidni a udelej 3 drepy !!! ;)
-
Jarda (neregistrovaný) ---.18-1.cable.virginm.net
Virtuals are dead :) http://blog.circleci.com/its-the-future/
-
Ale lidi, probuďte se... 32bit tu ještě (bohužel) nějakej pátek bude. Co se týče starých krámů pro babičky a dědečky na internet, většinou to chce alespoň přidat paměť, aby se to trochu slušně hejbalo a jen paměť do těch starých krámů už stojí skoro to, co bazarovej 10x výkonější netbook. Za těch pár let, kdy to opravdu zaříznou všichni, už to bude nepoužitelný úplně. Nedávno jsem zprovozňoval jeden takovej krám pro kamarádku, válela se mi na půdě stará P4, 3GHz, tuším bez HT, k tomu 1GB RAM, plotnovej disk (nějaká 160GB SATA). No co bych to dlouho popisoval, to je i na ty internety zoufalý. A to už to je 64b.
-
Paka (neregistrovaný) 80.250.30.---
Třeba u uživatelů Debianu a pod, kde je upgrade starší verze na novou běžná a fungující věc už mnoho a mnoho let, může být důvodem setrvávání na 32bit jednoduše fakt, že před mnohla lety na 32bit začali. Např u mne je hw počítače už párkrát postupně vyměněn, ale system je pořád "stejný" - postupně updatovaná s hodně starými kořeny. A upgrade OS z 32bit na 64bit není nic triviálního.
Oproti tomu třeba takový slavný RedHat EL nebo Centos, který upgrade z jedné veze na druhou zavedl až tuším loni (verze 6 na 7) a ještě to většinou způsobí tolik komplikací, že se stejně snažší čistá instalace, takovými starostmi netrpí :-)
-
Já jsem to tak taky měl mnoho let, ale pak jsem přecházel na SSD, což byl důvod k přechodu na 64 bit. Bylo to celkem snadné: zálohoval jsem seznam balíků a konfiguraci, udělal jsem čistou minimální instalaci a nechal jsem obnovit všechny balíky. Bylo to za chvíli a teď už zas asi dva roky jedu na jednom systému.
-
hm (neregistrovaný) ---.promos.cz
Jestli mám nějaké bity omylem, pak je to 64 (při instalaci jsem řekl, proč to nezkusit, když je to prej takovej kůl). Naštěstí je to jen jeden stroj, jiínde si budu dávat velký pozor. Výhody? Žádné. Nevýhody? Spoustu toho musím mít dvakrát (64 a 32), protože pořád jsou některé sw jen 32 a kvůli nim musí být nainstalované i prakticky celé "zázemí" 32. Zkoušel jsem před časem i změnit na 32 (bez kompletní přeinstalace), ale nepovedlo se. Můj názor: není faktický důvod používat 64 bitů a ještě dlouho nebude.
-
Ani nevím, jestli se prosadil ten mix architektur, kdy je procesor sice v 64bitovém módu, ale software používá 32bitové ukazatele, takže délka programů nenaroste? Pokud ne, tak přechod z 32 na 64 vyžaduje přidat 1/3 RAM, což stojí peníze, takže je to hloupost dělat (neb 64bitů žádné citelné výhody nepřinese).
Jinak aktuálně mám doma asi pět funkčních 32bitových počítačů, na které 64bit cpát nebudu. Dám tam Lubuntu/Xubuntu 16.04 a akorát budu muset oželet Chrome, takže i Flash, který je bohužel u mnoha nejen Googlích produktů pořád klíčový.
-
Jen tak BTW -- hádej, odkud si zmiňovaný pepperflashplugin-nonfree bere ten flash plugin.
Doporučuju přečíst si popis toho balíčku a popřemýšlet o tom, co nastane, až google přestane vydávat 32 bit verzi chrome...
-
Ahoj Petre. Myslis PAE? Ja to napriklad pouzivam porad, skutecne nemam zadnou aplikaci, ktera by potrebovala sama pro sebe vic nez 4 GB.
Ona i Java umi pouzivat 'compressed oops', coz jsou vlastne 32bitove reference (neprime ukazatele), namisto 64bitovych. Tam je to tedy jeste vylepseno bitovym posunem (protoze se nemusi adresovat po bajtech), ale i javisti si uvedomuji nektere prednosti tohoto modelu.
-
Řekl bych, že má na mysli x32 - 32-pointery s 64-bitovou instrukční sadou, tedy něco podobného jako zmiňovaná java, akorát bez compressed, tedy s rozsahem 4GB. Viz https://en.wikipedia.org/wiki/X32_ABI
Jedna z hlavních výhod 64-bit je relativně moderní instrukční sada, nevýhoda je samozřejmě větší nárok na paměť (a hlavně cache). x32 ABI tohle řeší elegantně, ale pokud vím, tak do mainstream se to snad nikdy extra neprosadilo. Ale v zásadě je to na aplikaci, pořád je to jen další multiarch set.
PAE - nechtěli to už dříve v kernelu zrušit? Někde jsem četl, že psát kód PAE-friendly je docela peklo, ohledně mapování HW paměti apod. Navíc samozřejmě limity - 1GB na kernel včetně cache apod...
-
Ajo no x32 by byla jeste lepsi. Oni tam ten bitovej posun pointeru dat nemuzou, protoze v C se muze adresovat libovolny bajt, kdezto v Jave si klidne reknou, ze objekty budou vzdycky zacinat treba na adrese delitelne 16 a tim padem spodni bity budou nulovy. Ale i tak to vypada (x32) zajimave, chtelo by to nejake benchmarky, jak se to chova v realnem desktopu (tj. jak se lepsi vyuziti cache projevi na vykonu).
-
Já jsem o tom psal dva články: 32 bitů + 64 bitů = to nejlepší z obou světů v x32 ABI a x32 ABI: rozporuplná architektura, kterou vlastně nikdo nechce. Dostal jsem nějaké informace od vývojářů Gentoo, kteří tvrdí, že to je výrazně méně výkonné než plný 64 bit a celkově to prostě nestojí za režii kolem údržby další architektury. Reálně se tím ušetří pár procent paměti, čili to řeší neexistující problém.
-
jj vím, četl jsem a přiznám se, že potom jsem se s tím nikdy v praxi nesetkal, takže to skutečně asi málokdo využívá (na rozdíl od PAE, ale to má jinou historii a vlastně existuje z jiného důvodu). Nakonec dneska, kdy se čím dál tím víc přechází na jazyky s vlastní VM je to asi už jedno, ty VM si klidně mohou používat 32 bitové reference.
-
anon (neregistrovaný) 89.239.31.---
Od kdy je Itanium serverova architektura? To jsou zase bludy, vzdyt by si to stacilo najet i na Wikipedii! Je to ILP odchylka od x86, ale se servery nema nic spolecneho, za pet, sednout!
Miluju laiky, kteri slintaji, jak si nekde prectou slovo "vykon". Zadny "vykon" zdarma navic to prece neni, to uz dneska nikdo nepremysli? Je trivialni napsat aplikaci, ktera dobehne diky vetsi sirce registru vyrazne drive, stejne tak je trivialni napsat aplikaci, ktera dobehne kvuli (az) dvakrat vice zaplnene cache vyrazne pozdeji. Ale to nevadi, budeme se bavit o "narustu vykonu", to pseudoajtaci milujou.
Aplikace na Windows nemivaji 64bit protejsek? No on k tomu asi bude nejaky duvod, ze? Nebo si nekdo zdejsi vazne mysli, ze je v tomto oboru vzdelanejsi nez pracovnici Mozilly? Stacilo by zase jenom pouzit Google.
Kvalita textu (at uz "nad" diskuzni carou, nebo "pod") s casem konverguje k iDNES.
-
Což autorovi článků při podrobné poctivé rešerši poněkud uniklo, což? ;-) Jinak pro openSUSE se počítá s komunitní podporou 32 bitů. Respektive nadšencům se nebrání v tom se o to starat, ale samotná distribuce už to postupně odstavuje...
Jinak bych v článku ocenil víc reálných informací a méně bla bla omáčky... :-( -
Vlnka~ (neregistrovaný) ---.freescale.com
...ale načoooo, domka na stoliku 7 rocny ntb Fujitsu, okrem pantov nema jedinu vadu, baterka este stale vladze udrzat vykopnuty kabel, hardisk v S.M.A.R.T ukazuje vsetky hodnoty OK (ma 1 rok hodin najazdenych) a Lubuntu si krasne moze roztahovat nozicky na dva gigače RAM.. co tam po tom ze je tam 1.3 GHz 32 bit procesor... na firefox eclipse, notepad++ a settlers 2 to bohate staci (:
-
Zrovna ve Fedoře se o i686 podpoře hodně diskutovalo, a výsledek je takový, že pro Fedoru 24 vůbec nebude instalační obraz pro Fedora Cloud a Fedora Server. Pro Fedora Workstation asi bude, ale nebude příliš testovaný a případné chyby nebudou blokovat vydání, takže kvalita a funkčnost může být dost náhodná (nebo zcela žádná). Balíčky v repozitářích samozřejmě zatím zůstávají, ale hlavně jako podpora pro multilib, samotné i686 už možná bude docela těžké nainstalovat.
-
Xan_ (neregistrovaný) ---.cust.vodafone.cz
Autor článku je tragický teoretik, možná spíše tragický přepisovač cizích článků a myšlenek a je zřejmě bez znalosti aktuálního stavu problematiky, o které píše. Tydle žvásty si nechte pro sebe, případně se podělte s ekonomy na lupě, ti mají rádi "pokrok a zakazování starých věcí". Ponechte root tím "odbornějším" "zpravodajským" serverem.
-
nobody (neregistrovaný) ---.pel.cz
a co treba misto takovejch f{uck|ak}anskejch komentaru ze by jsi ty sam ooo velky napsal nejaky ten brutalne odborny clanek, presentoval by jsi sve svet menici myslenky a prevratne teorie, ktere vsechny posadi do kolen a na potkani se ti budou klanet a lestit pantofle ? ;)
-
Jerry (neregistrovaný) ---.hosting-zdarma.cz
V roce 2013 jsem se snažil rodičům rozjet Linux na čerstvě koupeném netbooku Acer D270-26 a tvrdě jsem narazil s grafikou GMA3600, která je součástí procesoru Intel Atom N2600. Procesor byl sice 64 bitový, ale ovladače CedarView byly v Linuxu pouze pro x32 a ještě prý omezené verzí kernelu. Vyzkoušel jsem hromadu možností a akcelerovaná grafika fungovala (kromě Win) POUZE v Linux Mint Mate 13. V Ubuntu 12.10 nebo Mint 14 se grafický instalátor ani nerozběhl...
Vzhledem k tomu, že stejný procesor byl ve spoustě Netbooků prodávaných v té době, zajímalo by mě, zda už v současných distribucích x64 ovladače grafiky GMA3600 konečně (použitelně) fungujou nebo se 3 roky starými výrobky už nikdo nehodlá zabývat? Vtipné bylo, že zrovna tenhle netbook byl oficiálně prodáván s "Linpus Lite for Meego", nikoliv Windows, tak by to člověk nečekal.
-
zuzzan (neregistrovaný) ---.cust.vodafone.cz
Včera jsem doinstalovával na server s CentOsem 6.6 x64 podporu pro 32 bit, konkrétně gcc-lib.i686 pro starou verzi XAMMP 1.4.6, na které mi jede nějaký starý podnikový CRM vlastni výroby (jen po LAN). Sem ani nedoufal, ze to spustím, ale podařilo se. 32 bit ještě neopouštět !!!
-
Upce (neregistrovaný) ---.175.broadband13.iol.cz
Podpora 32 bitů v distribucích? Možná už zbytečný luxus
Jsem pro a rovnou zahoďme 90% mikrokontrolérů. Protože ten zbytek jsou dnes 8b a světe div se i pár 64b ARMů...
ne tohle mě fakt nadzvedlo...
Asi jako umrtvíme uměle WXP, W7 .... protože se to přeci osvědčilo... -
V téhle diskusi se myslím zapomělo na jednu podstatnou věc. Ono totiž zdaleka nejde jenom o možnost adresovat víc, než 4Gb. Architektura amd64 alias intel64 alias x64 je proti předpotopnímu x86 natolik modernizovaná, že má smysl ji používat u jakékoli aplikace. Dvojnásobný počet registrů, moderní adresovací módy a "pročištěná" instrukční sada stojí za to, i kdyby si aplikace vystačila jen s 4K.
-
Souhlasím ovšem se zdejšími názory, které jsem pochopil u diskuzí pod programy pod Javou - Kde vývojáři naprosto drze tvrdí, že na jejich drobnosti je 12-24GB RAM prostě normální. Přitom teprve nedávno se to samé muselo vejít do 2GB (32bit JVM).
Ano, bohužel 64bit a SSD disky jsou radost pro různé matláky, kteří chrlí odpad a ještě se radují, jak to jde snadno. Často vídám sobě podobné implementace, mnody tisíckrát pomalejší s nároky na RAM v stonásobcích. Další nevýhoda těchto taky programátorů je mizerná bezpečnost jejich produktů (když to neumí naprogramovat aby to žralo málo RAM a CPU tak o nějaké bezpečnosti už se jim ani nezdá - někdy "pak" se to doladí). -
backup (neregistrovaný) 217.91.91.---
ocekaval jsem v clanku neco o tom, jak prepsat vlastni aplikace do 64 bitoveho modu. My mame statisice radku kodu (C) , vse je zhruba 20 let stare a samozrejme to vznikalo v dobe , kdy existovaly je 32 bitove aplikace. Videl jsem na netu samozrejme radu clanku jak takove aplikace prepsat, ale v oblasti podnikovych aplikaci by to neprineslo zadne vyhody. Proto jsme zatim vsechny ty '64-bit' ignorovali a mame vsude centos x86. Otazka je, jak dlouho to jeste vydrzi. Proto otazka, nema nekdo konkretni zkusenosti s prepisem tech aplikaci? Na co je treba davat pozor? Existuji nejake programy, ketre to automatizuji?
-
Ivan (neregistrovaný) 165.72.200.---
Dost veci je popsano tady http://www.viva64.com. A ono je toho docela dost.
Ono to neni jen 32 vs 64. Ale i LP64 vs LL64. Linux vs Windows... -
MarSik (neregistrovaný) ---.redhat.com
Já osobně ještě používám několik Windows aplikací pod Wine (např. protože lepší simulátor antén nikdo nenapsal a pro linux neexistuje). A ty ten 32bit runtime vyžadují.
A zrovna CentOS 7 mě s tím zaříznutím 32bit docela pozlobil :/ Naštěstí máme hodnou komunitu a aspoň nejaké balíčky vznikly.. http://arrfab.net/attic/RPMS/7/x86_64/ (bohužel dnes už mírně zastaralé)
-
j (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----
Pres dva kancly mam stroj, na kterym bezi DOSova vec na tisk nejakych polepek. Primarne pak ani nejde o to, ze by to neslo prehodit na novejsi SW... ale predevsim o to, ze tam jsou tisice sablon, a ty by musel nekdo predelat.
....
Centos 7 vytaci zjevne vsechny ... dodavatel byl prave dnes vytocen tim, ze mu sam nastartoval servis, kterej zastavil. Nastesti to bylo v ramci testovani, takze jedine dobre. At zije systemd.
-
- IT Administrátor/ka - Správce sítě
- Frontend developer
- Senior DevOps Engineer - Webmethods/Linux
- Senior DevOps Engineer - SAP SD/ABAP
- Senior DevOps Engineer – SAP SD + ABAP/BSP
- Javascript / Angular / UI Developer
-
- Digitální technologie pro osobní produktivitu
- Péče o síť kontaktů a základní principy prorůstání do organizace
- Microsoft Teams 1: spolupracujte online pomocí chatu
- Jak na skečnouting aneb čmárej si (i) na poradě
- Anglické idiomy II
- Seznamy na SharePointu 2: vychytávky pro práci s položkami a seznamem
-
- Backend developer
- Senior DevOps Engineer - Webmethods/Linux
- Senior DevOps Engineer - SAP SD/ABAP
- E-Procurement specialista
- Group Head of IT
- Content specialista B2B/B2C eshop
-
- Digitální technologie pro osobní produktivitu
- Co potřebuje HR specialista vědět o projektovém řízení?
- Microsoft Teams 1: spolupracujte online pomocí chatu
- Jak si pomocí čmárání ulehčit práci
- Jak na skečnouting aneb čmárej si (i) na poradě
- Anglické idiomy II
