45
-
#45
Nincs ezzel semmi gáz. Mindenki a saját szerencséjének a pogácsa :) -
Rive #44 Hm. Eltérő világszemléletünk van ;)
Én ugyanis főleg Linux alatt programozok, kernel-szinten. A számomra evidens, hogy ha egy 'oprendszer' nem üvölt védelmi hibát, miután egy user-program megpróbálta pl. közvetlenül a vinyót babrálni - nos, az akkor számomra nem is oprendszer...
Ha meg egy programozó _saját_ adatformátumot alkalmaz egy _saját_ file-ban, akkor magára vessen, ha egy 32 bites értéket próbál beolvasni egy 64 bites regiszterbe (esetleg fordítva), konvertálás nélkül, miután tipizált változókat használt...
Ha meg ezt az egészet még meg is próbálja lenyomni a kernel torkán...
Nálam ez, attól tartok, az 'egyéni szoc. probléma' kategóriába tartozik, mindenki a saját felelősségére hülye.
NT kernelhez nem értek.
-
Rive #41 Pheel, azt írtam, hogy: 'Egy _normális_ oprendszernél'. Ott pedig totálisan igaz is... A méret is...
Ugyanis addig nem kerül bele a rendszerbe, amíg nem lesz _teljes_mértékben_kompatibilis_ az előző (32 bites) változatokkal.
-
#40
IMHO az Intel nem fogja átvenni ezt a x86-64-et. Totális meghátrálás lenne a részéről. -
#39
Nagyon sok helyen használnak nem OO-szerű(Serialize, etc) mentési formátumot. Az pedig igencsak lehet gond. Sőt! Ha még így is használod, akkor is gáz lehet, hogy más méretet olvas fel a rendszer, mint ami a régi mentésben van. -
Rive #38 Aha...
Egy _normális_ oprendszernél a user-level programoknak _nincs_ dolguk a hardverrel: a vinyóval se. Így aztán könnyen betartható az a régi programozói intelem, hogy: Magadra vess, ha tipizált változókat használsz!...
-
#37
Jajj, ne mar :)))
Sracok, a programok szoktak adatokat is tarolni a merevlemezen. Aztan a 32 bites valtozot a sok hulye programozo sokszor 32 biten tarolja.
Nem csak arrol van szo, hogy sok programot majd ujra kell irni, de meg konvertereket is kell kesziteni.
Igen, biztosan lesz olyan program, amelyet eleg lesz ujraforditani, de lesz szamtalan, amely atirast igenyel, es sok olyan, amivel k. nagy melo atallni 64 bitre.
Szoval, lehet fordumozni, de okosan pls ;)
-
Rive #36 Hi Lenny!
Itt: http://www.hwsw.hu/perl/ultimatebb.cgi?ubb=get_topic&f=3&t=000353 az egyik srác (igen, Elric) nagyon nyomja a fordítókkal kapcsolatos dolgokat.
Ja, és a fórumban feltett kérdésekre szívesen válaszol is, szerencsére :) -
Supergamer_real #32 ""Hmm... igazad lehet..
Akkor elég az újrafordítás. Sorry:)""
Mellesleg tudok neked pontos cikkhez linket adni, ha a linux datum dolog nem tiszta.De te magad is talahatsz errol bo dokumentaciot, de ha segitseg kell szolj. -
Supergamer_real #31 lenne=lenne a legjobb -
Supergamer_real #30 "Hmm... igazad lehet..
Akkor elég az újrafordítás. Sorry:)"
Bocsanat, nem volt idom irni.De latom idokozben a problema megoldodott.
"Sajnos az eredeti probléma másik részéhez, ami a két proci mikorarchitektúráját illeti nem tudok még érdemben hozzászólni"
Biztosan kell hozza egy uj BIOS, a legjobb a hypertreadinghez egy gyokereiben ujrairt rendszer lenne, persze ezt valoszinuleg patchelessel oldjak meg.+ informaciot talasz meg a Sun honlapjan illetve itt Riveal elegge korbejartuk a temat a mult threading eljarasokat illetoleg.
http://www.supergamez.hu/cikk.php?cid=21661
Ha valami elirtam volna sajnalom, kisse zsufolt napom volt.
-
Power #24 Lenny:
Egyetértek.
Csak a laikusok gondolják, úgy, hogy a 64 bit csak annyi, hogy van 32 bit felül ami nincs mindig kihasználva.
Akkor miért tartanák meg a 32 bites módot? Ugyanez volt a helyzet annó a 386-ossal, sok év telt el, amíg az oprendszerek követték.
Általában a sw, csak kullog a hw után. :-)
A nagyprímszámoknál most is így van pl. a titkosítás is 128, 256, 512 illetve 1024 bites kulcsokkal muxik, de itt a kódoláshoz nem kell erős hw, a sw épp elég.
Viszont a feltöréshez, meg hiába lenne erős hw, az 512/1024 bites kulcsot nyers erővel jelenleg lehetetlen feltörni, ide kellene a "gógyi". :-) -
Power #21 Azért szerintem nagyon is megszabja.
Mondjuk egy 8 bites procin láttál már komoly programot ami lebegőpontos számításokat végez.
Volt egy pár ami használt ugyan, de az inkább volt játék, mint mérnöki-tudományos terület, ahol alapvető dupla-pontosság.
Az egészeknél sokkal egyszerűbb, de 30 évvel ezelőtt kitudta, hogy ennyi program lesz? Azt se tudták, hogy százmillió számra lesznek gépek. -
Power #18 Hogy miért takarékoskodtak, hát mert a 60-as, 70-es években még egyáltalán nem volt mindegy pár ezer byte plusz.
Másrészt, ha régebbi évszámokra vagy kiváncsi, mondjuk egy adatbázisban tárolsz régi évszámokat, simán jól, jön hogy nem 1900-tól kezdődne a világ.
Szóval a te megoldásod se oldaná meg a dolgot.
Ez alapján miért takarékoskodtak pl. a karakter ábrázolással miért volt 7 illetve 8 bites?
Vagy a procikat miért nem egyből 64 bitesre tervezték???
Szóval a múltat firtatni hülyeség. Ez van és így volt célszerű. -
Power #15 Csabi: én ebben nem lennék olyan biztos.
Nem olyan triviális a dolog, mint aminek látszik, hogy az int 64 bitre változik és aztán minden vígan muxik s ez nem csak dátum porbléma, hanem még ezer más. -
Supergamer_real #11 " Szóval Ti mindketten úgy gondoljátok ezek szerint, hogy majd vesztek egy Hammert és hirtelen minden programotok
magától szebb ügyesebb okosabb és 64 bites lesz?"
Ezt a baromsagot megis ki mondta?Mar ne haragudj de a kulturalt tarsalgas egyik alapfeltetele, hogy feltetelezed, hogy a veled szemben allo legalabb olyan okos mint te vagy.Errol most nem kivanok vitat nyitni, de mond mar meg mi a nehezebb egy valtozo definiciot 32rol 64 bitesre cserelni vagy egy uj BIOS -t megirni.!? -
Supergamer_real #10 A tobbitol eltekintve egy valtozodefinicio 32bitesrol 64bitesre valtoztatasa nem egy ordongosseg.Az iNTELfele bioscserehez hasonlitva meg egyenesen semmi.... -
Supergamer_real #7 "nem kell atirni egy programot sem, eleg 64 bites architekturara upgradelni, de amire aktualis lenne a problema,
addigra ugysem lesz 32 bites processzor."
En is errol beszelek.
Lenny, elirtam y2kra gondoltam, de ez a problema linuxos... unixoknal nem problema (altalaban) mert 64 bites procikon futtatjak.Ezt a propblemat pont a 64bites proci fogja megoldani. -
Supergamer_real #3 A multi threading tamogatashoz mindenkeppen kell egy BIOS csere (az intelt ismerve ez sajnos uj chipset, alaplap) es egy olyan (optimalis esetben teljesen ujrairt) operacios rendszer ami tamogatja az eljarast.Ha ezt az alapoktol irjak ujra - aminek lassuk be eleg kicsi az eselye - akkor a szimultan tobbfonalas eljarasbol sokkal nagyobb teljesitmenyt lehet kinyerni, mint szimpla patchelesbol(valoszinuleg ez lesz majd a XP eseteben).
Az AMD megoldasa tobb proci egy magon belul ellenben mindossze egy patchet igenyel, de reszben mar igy is tamogatott az NT 4.0ota.Ez linuxoknak/unixoknak sem lesz kulonosebb problema.
Mindenesetre most vagy feldaraboljak az PC piacot - aminek nem lenne sok ertelme es a valoszinusege - vagy pedig az iNTELnek tenyleg tamogatnia kell(ene) az AMD megoldasat.Ez szamomra eleg hihetetlen, de talan az egyetlen esszeru megoldas. -
Supergamer_real #1 "AMD: Az Intelnek is támogatnia kellene az x86-64-et"
Hat ez vicces lesz... nem nagyon tudom elkepzelni az iNTEL-t, ahogy AMD technologiat licensel.Eleg volt neki a Hyper Transport.....
Mas:
Ez a 64 bit hala Istennek megoldja a linux datum prolemajat is.Bar errol meg nem kezdett el remhireket terjeszteni a sajto a Win2k bughoz hasonloan a Linux is meg van aldva egy datumproblemaval.Ez 2027 korul jonne elo, de a 64bites processoroknak hala egy ideig (meg par ezer evig) nem lesz veluk problema.