"Történelmi mélységbe estek a UNIX-szervereladások"

UNIX, UNIX-szerű

Az IDC friss adatai szerint a harmadik negyedévben 2,3 millió darabon stagnált az eladott szerverek száma, a gyártói árbevétel eközben 3,7 százalékkal 12,1 milliárd dollárra apadt. [...] Különösen gyenge volt a UNIX-szerverek forgalma, az eladások értéke 31 százalékkal zuhant éves összehasonlításban. A UNIX-ot futtató gépek a szerverpiacnak csak 11 százalékát adták, ami az IDC által mért legalacsonyabb adat valaha. [...] A Windowst futtató szerverek iránt némileg apadt a kereslet, az eladásaik 1,6 százalékkal múlták alul a tavalyi harmadik negyedév szintjét. Ezzel együtt továbbra is a windowsos gépek adják a szerverpiac legnagyobb részét, az eladások értéke 6,1 milliárd dollár volt, ami a teljes piac kicsivel több mint felét jelenti. A nagy cloudtelepítéseknek is köszönhetően továbbra is erős a kereslet a Linuxot futtató kiszolgálók iránt, a forgalmuk a negyedévben 3,4 milliárd dollárt tett ki, ami éves szinten 5,6 százalékos emelkedést jelent. A linuxos gépek aránya a teljes szerverpiacon belül 28 százalék volt.

A teljes cikk itt.

( Ritter | 2013. 12. 05., cs – 15:44 )

Marad még valami előny vagy érv, ami Unix mellett szól Linuxszal szemben?

A HPUX, IBM AIX és társai messze jobb rendszerek, mint a Linux. Viszont jóval drágábbak is.
Legtöbbször elegendö ugyanazt a feladatot egy ingyenes, vagy olcsóbb megoldással kiváltani.
Ezen felül pedig a világ tart a virtualizáció felé, ami ugyancsak árnyalja a képet.
Pl. egész jól lehet linux alapon is virtualizálni.

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

Tény: sok dolgom nem volt AIX-szel, bár elvileg én voltam az egyik gazdája, de kb. a tanfolyamra járáson túl csak MQ felhasználóként/adminként találkoztam vele, magával a rendszerrel nem nagyon kellett csinálni semmit. (jó, ez némileg UL kategória, mivel egy aktívan használt szervert azért időnként kell piszkálni, patch-elni stb., de ahogy olvastam/hallottam, nagyságrendekkel kevesebb gond van velük, mint bármely más, unix like rendszerrel)
Sajnálom, hogy kihalnak.

Én meg hallotam olyat, hogy Linux telepítés végére megtörték a szervert. Maradjunk annyiban, hogy vannak urban legendek, de pl. az IRIX ilyen szempontból sokkal rosszabb volt. (Ma meg a Linux sokkal rosszabb, mert sokkal többen üzemeltetnek Linuxot hozzáértés nélkül, mint az összes egyéb UNIX-szervert.)

Találkoztam már olyan SUSE linux-al is amihez évek múltán akkor kellett hozzányúlni amikor átköltöztették másik terembe. És akkor is csak azért kellett a kikapcs/szállít/bekapcs-on kívül mást nézni mert az egyik service nem volt beállítva hogy induláskor automatikusan induljon...

"Nem kell az szerver legyen, lásd pl. macintosh."
Ezt így van, magam is tanúsíthatom.
Desktop linuxon ez még nagyon hiányzik, bár Linus dícsérte a Chromebook Pixelt, de az még csak az első fecske.

Szerver viszont van. Egy IBM-től vett linux szerver megbízható és problémamentesen kezelhető.

Ez így van. Másik oldalon meg lehet nézni az IT-történelmet, mióta léteznek a Unix rendszerek, és, hogy a Linux egy finn egyetemista hobbiprojektjeként indult 91-ben, miután megpróbálta leutánozni a Unix-filozófiát.
Mai napig nincs op.rendszer, ami valahol ne a Unix-on alapulna, még ha csak kicsit, akkor is.

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

NT 4-ben és 2000-ben még Unix kompatibilitási réteg volt... Persze amikor már sikerült a unixos mérnöki munkaállomások és a unixos szerverek piacára behatolniuk és nyeregben érezték magukat, akkor ez ki is került a windowsból. A szokásos forgatókönyv: kompatibilitást teremtettek egy célpiac felé, elkezdték átcsábítani a vevőket, majd amikor már elég erősek voltak, akkor fordul a kocka, kompatibilitás megszüntet, amelyik vevőnek voltak még régi rendszerei is azt ezáltal a teljes váltásra kényszerítették, aztán innen kezdve a vevők leszarva.

A POWER masinák oprendszereiről mi a véleményed? Nem azokról a verziókról beszélek ahol AIX van, hanem az AS/400 oprendszereiről. V4R0M0 -tól V7R1M0 -ig. Azért azoktól a Unix is vett át egyet smást. Manapság meg már a Linux-ban is felbukkannak egyes egyszerűbb ficsörök.

Ellenben minden hozzáadott szoftver (httpd, php, stb.) kegyetlen régi. Ha ezekből friss verziót szeretnél rá tenni, akkor mehet a forrásból fordigatás, manuális ujrafordigatós upgrade, stb. vagy marad az elavult/sechole-os verzió firewall mögött.
Nem csoda, hogy a default installos AIXokra már csak egy DB2/Oracle-t tesznek és minden más szoftvert már inkább linuxon/Windowson futtatnak különálló gépeken/VMeken. Default installos AIXokon még szép hogy problémamentes az upgrade...

Olyannyira, hogy pl. egy Red Hat verzió upgrade -re nincs a vendor által supportált eljárás. Van 3-400 hostod amit így újra kell telepítgetni? így jártál.
Míg mondjuk AIX -nél simán megoldott a verzió váltás, és egy tizenakárhány éve telepített hostot is tudsz tovább vinni.

Én példaként mondjuk az AIX -et tudom felhozni, fényévekkel jobb a managementje/üzemeltetése. Pl. nagyon kényelmes device kezeléssel. Egy csomó művelet online, rendszerleállás nélkül elvégezhető.
A power system hardvert és AIX operációs rendszer egységes ökoszisztémaként kezelve egy nagyon robosztus, jól skálázható, és baromi erős rendszert kapni.
Mindezt olyan virtualizációs megoldásokkal amihez képest az x86 virtualizációk gyerekjátéknak tűnnek.

Feltételezem a vCentert próbálod hasonlítgatni a System Directorral. Az tény, hogy nem olyan szinten csili-vili, viszont itt nem a gui a lényeg hanem azok a virtualizációs funkciók és lehetőségek amikre a rendszer képes.
Nem muszáj egyébként Directort használni. A PoverVC meg azért egyelőre korlátozottabb funkciókkal bír az erőforrás management terén mint egy HMC. Inkább a cloud jellegű igényekre van kihegyezve.

LPAR? Meg hasonlo sincs Linux kornyeken, vagy nem tudok rola.
Aztanmeg, egyseges. Nincs olyan, hogy upgrade utan kijon a szadon, hogy 'upsz'. A gyarto leirja mit varhatsz es mi fog tortenni, legyen az HP vagy IBM...

Persze ezek a rendszerek dragak, az emberek akik ertenek hozza ritkak, ergo dragak.
Linuxolni meg mindenki tud, a google -on meg van millio leiras.

Azon nem akarok vitatkozni, hogy melyik rendszer dragabb. Lattam olyan migraciot ( HP-Ux -> Linux ), ami a jatek vegen dragabb lett, lsd. hw -ek / rendszerek megbizhatosaga.

No, megtaláltam a bekapcsolódási potot!
AIX-hez nincs google, hanem VAN DOKUMENTÁCIÓ. Elovasod és úgy van.
Vö. nem kell fórumokon turkáli, hogy én hogy csináltam.
((( A há-puxot nem sorolnám a duma körébe a pc platform stb miatt. )))
A rendszerek drágák. A zsebedhez képest. Nekem meg első félévbe tanítottak gazdasági számításokat.
Nyilvánvalóan, ha spórolni szeretnél, miközben otthonra veszel egy 100MFt-os szervert, akkor ott baj van.
Megfontolandó, miközben az IBM eladásai is csökkentek, már jó régen az Oracle DUPLA licenc díjat állapított meg /core. Nem lehet, hogy a feleannyi 2x annyit ér? Olvastam olyan tanulmányt, amiből kiderül, hogy az IBM szervereken olcsóbb a virtualizáció, min a VMware. Negatívum: az IBM írta. PO-ZI-TÍV LENNE, ha valaki mutatna egy olyan dokumentumot, ami az ellenekzőjét vezeti le. Az sem baj, ha hazudik.
Gyengébbek kedvéért: Az IBM - miközben nem szerver eladásokból él - azért a legjobb processzorokat gyártja.

PS: Azért a Windows Server 2008 R2 jobb bármelyik linuxnál.

> A há-puxot nem sorolnám a duma körébe a pc platform stb miatt.

Melyik HP-UX az, amelyik PC-plaformot használ(*)? Személy szerint én 3-ról hallottam: a régi 3000/4000-es család (ha jól tudom, tán Motorola 68k alapú - de olyat már csak "hallomásból sem láttam"). A senkiével össze nem hasonlítható PA-RISC processzoros 9000-es család - ez ki nem halt, de arra tendál; és az új Integrity szerverek, amikben valóban Intel gyártmányú proci van, csak épp nem x86 architektúra, hanem Itanium (IA64) (**). (Aminek a korai verzióit egyébként közösen tervezték, majd a gyártás és a továbbfejlesztés került az Intelhez.)
Szóval nem, nem PC-platform. Megtanulni sem nehezebb egy HP-UX-ot, mint Linuxot - illetve ha valaki hozzáfér egy géphez, akkor nem nehezebb. Az tény, hogy sokkal "fapadosabbak" a kereskedelmi UNIXok, de nem is az volt a feladatuk elsősorban, hogy a felhasználó arról hallgasson Youtube-ról ByeAlexet.

(*) Ha már it tartunk, AIX-ből valóban volt - valahol tán a az 1.2?, 2.x? verzió környékén - PC-platformon futó verzió, ami a szintén IBM-hez kötődő PS2-es gépeken futott. Elég hamar megszűnt. Pár éve itt valaki iszoonyatos küzdelmet folytatott, hogy tán QEmu x86-ban elindítsa.
(**) ez volt az, amit sok kezdő régebben előszeretettel választott, mikor kiválasztotta, hogy a lewarezolandó FreeBSD-ből melyik verziót töltse le. Mer' ugye Intel gyártmányú, és 64-bites. Nem holmi Amd64-es izé kell, mert neki Intel gyártmányú, de 64 bitet támogató procija van.

Szerk: Ami meg az utóiratot illeti: miben? Ez a mondat így túlságosan sommás ahhoz, hogy vitatkozni lehessen vele.

Az utóirat az tréfa, vicc, stb. Legalábbis a topic címének függvényében.

A PC-n futó AIX is tréfa, bár én is beszéltem olyannal aki látott ilyet. :)

Volt szerencsém olyan projektben résztvenni, amikor IBM platformról tettek át rendszert (szóval nem én voltam!) PA-RISC alapú gépre. Nyilvánvalóan nem csak a CPU, hanem a szakemberek is ludasak abban, hogy a fizikailag 15x gyorsabb gépen 3-10x lassabb lett minden. Ez azért világcsúcs! Ha olvasgatsz a joelonsoftware cikkeiből, akkor semmit nem kell mesélnem a projektről. :-)
Annak ellenére, hogy a PC platform kicsit erős, senkinek sem ajánlanék ilyen gépeket.

Mi az a fapados? Nem fut rajta a Windows, bocsánat KDE?
Az a szörnyű igazság, hogy aki ilyet mond, az nem dolgozott még szerveren, de legalábbis nem ért hozzá. Több, jobb, vagy rosszabb szakembert láttam, akiknek első dolguk volt bash-t, date-t (!), vagy egy előre elkészített csomagot telepíteni AIX-re, mert az ott található dolgok használhatatlanok. Számomra meg némelyik disztro linux tűnik annak.

A Youtube és ByeAlex igen közel áll a megoldáshoz. A felhasználók nagy részét az motiválja, hogy jó a Windows is, akár szervernek. Mert azt ismerik. Vagy úgy vélik, hogy ismerik.
Ugyanez a helyzet, amikor mondjuk egy POWER7-et összehasonlítanak más cpuval.

Hali,

Bocs, nem akartalak megserteni. Mi Zahy-val sosem dolgoztunk szerveren, ennek fuggvenyeben nem is vitatkoznank veled.
Zahy BSD zik, azt tudod, abban eros, asszem dolgozott valamit a HP-Ux -al is, de ebben nem vagyok biztos.

Enmeg egy kisebb cegnel voltam ilyen rendszergazda, de csak Linux ( azis SuSE ) meg picit HP-Ux oztam, innen ismerem Zahy -t is, meg a BSD miatt.
LINUX ROXXX

Majd én szólok, ha megsértődtem. ;) Bár nem is tudom mi okom lett volna.
Off: Windowst is használok 2002-től!!!! Akkoriban próbáltam fórumon tanácsot kérni egy HPT370 RAID linux kernelbe fordítása után fellépő gyári hibával kapcsolatban. Elhajtottak, hogy hülye vagyok hozzá. Ez a fórum.
Én csak '92 augusztustól dolgoztam AIX-en, mint üzemeltető rendszerprogramozó és konfiguráltam is néhány rendszert. Specialitásom a végesállapotú gép elven működő automata ksh+C, illetve gyors adatfeldolgozás. Legelső ilyen rendszerem 19 évet futott, 1 éve szerelték le. :((((
Van diplomám is: általános gépész üzemmérnök. Ezért hw fejlesztőként kezdtem a pályámat. (Nem csavar, hanem mikroprocesszor a gyengébbek kedvéért.;) Sebességmániás vagyok, és ezt a hajlamomat az IBM gépein megfelelő módon kiélhettem.
Egyik példa: Egy 10+ órát futó programot kellett átírni és egy kicsit gyorsabb gépre áthelyezni. ("Egyszerű filter") Egy nagyon ügyes kislány végezte a munkát, én konzultáltam. Kitűztem a célt: 2M adat legyen 14 perc. Két hónap múlva bemutatta, 20 perc alatt futott. Megkértem, hogy rakja bele azokat a módosításokat amit megbeszéltünk, így lett 14 perc. Pár évvel később némi funkcióbővítéssel együtt átírtam, így 4,5x gyorsabb lett.
Konklúzió: Ilyen szervereken a feladat ismeretében, némi gyakorlattal ki lehet számítani előre a futásidőt. Sajnos ez a kunszt nem sokat ér, az IBM nem akar elég kicsi és elég lassú gépeket gyártani. ;(
Mondom, sírni tudnék a röhögéstől, amikor fiatalok a lábujjaikon számolják az órajelet a vindózos pécéjükben, és elhiszik, hogy összemérhető bármviel ami nem csak azért szerver, mert azon fut az apache.

A PA-RISC kérdés. Nem voltam eléggé tájékozott. Úgy hittem, hogy 2005-től már nem nagyon gyártják. De kaptam ilyen rendszertől adatot 2005-2012 között. Természetesen a rendszer tervezői és az Oracle is ludas a hiperűrsebeségben. A régi gépen 1 órás feladat először 11, majd 3 órára zsugorodot. Hacsak le nem esett valamilyen index, mert akkor 19 órás futás után a legmerészebbek sem merték megjósolni a futás végét. Közben zsákszámra töltötték bele a memóriát. (Az 1 órás futásidejű rendszert én üzemeltettem. Az adatbázis kapott 384M ramot, de nem tudta kihasználni.)
Akár elfogult is lehetek.

Ha meg nem dolgoztatok szerveren, akkor érdemes meghallgatni olyat, aki 20 éven keresztül nem csak üzemeltetett ilyeneket, hanem rendszereket is fejlesztett. Nem azért, hogy a májam hízzon, hanem hátha világosabbá válik számotokra a marketing duma és a valós működés közti különbség. Ezáltal pl. a topic nyitó cikk néhány rejtelme is feltárulhat.

Erre azért van válasz. Több is.
- A HP miért használna IBM gépeket? (Bár azért van belátóbb cég is. Úgy hallottam, a Microsoft nem mindig IIS-t használ. :))
- Sajnos a POWER processzorokon nem futnak a Microsoft termékek. Szolgáltatóként nyilvánvalóan MS platformot is ki kell szolgálni. (Azért '95-96 környékén a WindowsNT szerver futott, állítólag sokkal gyorsabban, min egy PC-n.)
- Gazdaságosabb, mert kisebb rendelkezésreállás is elegendő.
- Nem minden esetben kalkulálták ki az áramfelvételt, vagy nem számít. :)

Nekem is van kérdésem: A Google miért BerkeleyDB-t használ és nem Oracle-t? Ne zavarjon meg, hogy az Oracle mint cég, pár éve bekebelezte a Sleepycat-et. Az adatbáziskezelőre gondolok.

- Amazon nem érdekelt a gépgyártásban. Ha megérné neki használhatna IBM AIX rendszereket.
- IBM System z elég jó virtualizációban és tud Windowst is, méghozzá x86 változatot. zEnterprise ha jól tudom. Na az még egy AIX gépnél is drágább. :-)
- Volt már olyan, hogy EC2 virtuális gép alatt kihalt a host?
- A nagy adatközpontok PUE mutatói azért nem rosszak.

A jó Google szerintem amellett, hogy nem akarja gazdagítani Java-perelős konkurens partnerét valószínűleg túl durvának találta az Oracle árazását. :-) Egyébként nem MySQL-t használ a G? Most majd biztosan váltanak ők is MariaDBre. Az Oracle luxusát leginkább bankok engedhették meg maguknak, most meg nézd meg hova jutottak. :-)

"AIX gépnél is drágább" ... Ez nem jó megközelítés. Virtualizációnál azt kellene megnézni, hogy
- thread/core
- a thread váltás milyen gyors
- virtuális gép/core
- ténylegesen mennyit bír a szerkezet
- mikroparticionálás/ ugyanaz dinamikusan

Így ki lehetne számolni mibe kerül egy adott teljesítményű VM.

A Google -> megetted. Ti. azért nem, mert az Oracle teljesen másra való.
Úgy lehet összehasonlítani a kettőt: Miért talicskával hordod a betont a wc padlójának a betonozásához, ha a 6 köbméteres mixerrel olcsóbb lenne?

Kb 1.5 éve volt egy projekt, ahol a meglévő IBM környezetekre kerestünk alternatívát, egy elég nagy magyar cégnél, mindezen szempontok figyelembevételével.
A vége az lett hogy a nem pSeries virtualizálás olcsóbb (nem írnék most gyártót), még a platformváltás költségeivel együtt is, pedig nem 1-2 LPAR-ról volt szó.
Persze minkét ajánlat sonderangebot volt.

Mondjuk az ügyfél marad pSeries-en. (jól tette)

Ezek a csókosok!
Az tetszett, amikor a kétszeres Windows Certified Expert bármilyen legegyszerűb kérdésre is modta: Hagyjál már, nem vagyok én rendszermérnök! A technika mai állása mellett MS rendszereknek a teljesítményigénye megjósolhatatlan.
A virtualizációval is ez lehet a gond. Nem tudják meghatározni az igényelt teljesítményt. Ettől kezdve a dobozok darabszáma számít, és egy rendes szerver csak egy doboz. Csak drága.

Azt próbáltam magyarázni, hogy a MS szakemberek szakértetlensége - és a MS rendszerek elterjedtsége szerepet játszik abban, hogy
- minek nagyobb gép, a másik is lassú volt
- minek profi szerver
stb.
Éppen egy >80 céget érintő rendszer közelében vagyok (nem, nem én voltam), és mindenhol csak windows szerverek vannak. Iszonyú erőforrászabálás folyik. "A felhasználók windowst választanak."
Mást nem lehet eladni. Én beérném az áram árával. :)
Hiába számolod ki az occsót - arra nincs pénz - és mégis többet költenek.

Ha ki lehet számolni az igényt, az jó. De ritkaság.

Ez azért nem teljesen pontos. Az LPAR-on kívül - van még néhány fajta *PAR, ami szerintem sokkal több féle és több lehetőséget kínál a XEN-hez képest. Ezen kívül a POWER processzorok "kissé" keményebben támogatják hardveresen a virtualizációt, néhányszor több szálat is tudnak. A POWER5 20vm/core illetve 1/10 vcpu léptékben konfigurálhato dinamikusan. Be kell látni, a XEN ehhez képest csak egy szoftver. Az IBM megfelelő toolokat biztosít a virtualizáció tervezéséhez.
Annak, hogy "virtualis gep egy valodi gepnek tunik, kernel szinten is" több féle megoldása is létezik POWER platformon.

Ehhez csak annyit, hogy életem egyik legnagyobb szívása (és egy 40+ órás ébrenlét) IBM zSeries vashoz köthető. És itt most olyasmiről beszélek, amit megírt az Index "Leállt az XXX Bank számlavezető rendszere" címmel. Előtte ez volt az a vas, aminek a HW és SW upgrade-je 10 hónapot csúszott, mert az IBM-nek csak negyedszerre sikerült az upgrade után is működő rendszert prezentálnia. Szóval a gyakorlatban ez a Nincs olyan, hogy upgrade utan kijon a szadon, hogy 'upsz'. A gyarto leirja mit varhatsz es mi fog tortenni, legyen az HP vagy IBM... inkább marketing, mint valóság.

Erre az a mondás illik: Ha azt mondom ugorj a kútba - beleurgrasz?
Döntés kérdése, hogy miért fizetnek, mi a Te döntési hatásköröd és mit szeretnél csinálni.
1. példa: IBM leszállította az új szervereket, hosszú lista az installált anyagról. (Benne a 128 portos soros, és FDDI csatoló diagnosztika. - Egyiket sem láttam még.) Megkérdeztem a főnököt: Mi a cél? Hibalapozunk, vagy megcsináljam? --- Hmm. Csináld meg. Egészen addig ment probléma nélkül, amíg más hozzá nem nyúlt.
2. példa: IBM leszállította az új szervereket, szoftvereket. Felrakjuk, hülyeséget írkál. Olvasgattam. Hívtam a szörvízt. Mondom hiba. - Várj egy kicsit - fiúk, már megint .. telefonál. Meg lesz egész napra a munkánk. - Tévedett. Két hétig az egész szerviz a problémáimon dolgozott.
A legkisebb probléma: Olyan clustert szállítottak, ami csak egy másik oprendszer verzióval működött.
3. példa: Fiatal szervizes versenyző indult hozzánk upgrade anyaggal. Eligazították: Add oda neki és nagyon figyelj, hogyan csinálja!
Itt azért nem az IBM hibáiról van szó, hanem a trehány vagy érdektelen, vagy rossz szakemberekről.

Érdekes módon szívás helyett főként sör mellett töltöttem az időmet. :)

A POWER kategóriában (as/400, System I, IBM I) 20-30-40 vagy még több éve van virtualizáció meg az összes olyan dolog amin Linuxon csak mostanában (elmúlt 5-10 éve) kezdtek el villogni. Az idő előny miatt jóval kiforotabbak a technológiáik is a Linux-val szemben. És ezek még nem a Mainframek csak olyan közép kategória. A baj inkább azzal van hogy egy 5-20 főt foglalkoztató magyarországi kis garázs/sufni cégnek nincs meg rá a lehetősége hogy ilyen technológiákkal dolgozzon. Egyrészt komolyabb feladatokat sem tudnak felhajtani, másrészt a szaktudású embereket sem tudják leszerződtetni. Hardver és szovftver büdzsé + szaktudású emberek hiánya. Szerintem emiatt megy az Open Source. Illetve álltalában akkora erőtartalék van egy Unix szerverben hogy nem cserélgetik/fejlesztgetik évente míg Linuxon egy PC-ből épített szerverel kezdesz, aztán megpróbáod tükrözni, fürtözni, miegymás.

Szvsz. egyre kevesebb, ezek a rendszerek nagyon erős vendor lock-ot jelentenek, hw és sw egy kézből, amit aztán nehéz cserélni. A másik szerintem, hogy mivel keveset adnak el belőle ezért a hardver nyűgjei meglepetésként tudják érni az embert és nem bitos, hogy könnyen találni akár a hivatalos support vonalon gyors megoldást. Míg az x86 platform ennél olcsóbb, gyorsabban cserélhető.

És kell is cserélni. Nekem itthon 1996-os Motorola (PowePC 604), és egy 2004-es IBM eServer p615 van. Ezeket elcseszték, mert még nem kellett cserélni. Az utóbbiban 1 eredeti és 3 "refurbished" diszket raktak. Méret 36G, áruk 1180$ és 750$. Ezt tisztelik, mert még nem romlottak el.
Azt kellene megérteni, hogy a rendelkezésreállás kalkulálható. Ugyanúgy ára van, mint a kis adag, meg nagy adag fagyinak.
Tavaly kaptam egy gépet, 1995 júniusi gyártmány - kosárban. -> IBM -> Erre csak az AIX 5.1 támogatott. Gépet összedugtam, rendszert felraktam. Nem indult. "Lassú" üzemmódba raktam, kiírta, hogy a második memóriakártya bal felső 6-os csip gyengélkedik. Megkértem, kapcsolja le azt a szegmenst. Aztán működött. Ez a helyzet, ha nedves pincében tárolsz valamit évekig. 4 processzor, hővezető paszta nem száradt ki. (Itt olyat nem használnak.) Ventillátor nem zörög. Fogyasztás 370W, tömeg 72kg.
A fiam P4-ese 225W fogyasztású volt, mert mindenből kicsit vettem...

Nen tudok ilyenről. Nem is sok értelme lenne. AIX alatt ott van a teljes SystemV, BSD parancskészlet. Talán mainframes dolgok is vannak, de ebben nem vagyok jártas.
Ami nagyon jó benne, az a bináris kompatibilitás. Van olyan program, ami fut 3.2-től akár a 7. verzióig. "Portoltam" párszor, ami főként az új cpu-hoz igazított tuningot jelentett. Azaz csak újra kellett fordítani a programokat.
A hardver (főként diszkek) kezelésével kapcsolatban vannak specifikus dolgok, amit azért nem "emulálnak" mert másik gépen nincs olyan. Viszont sokkal jobban használható, mint a linuxos LVM - kissé átgondoltabb.

Kedvencem a bigendian, sokkal könnyebb adatot feldolgozni az egyenes byte sorrenddel.

Ehhez képest döbbenetes volt az SCO-n az, hogy a xxxxxA1 és xxxxxA2 verzióban a kb. getchar putchar bonyolultságú program nem volt "hordozható" binárisban. No, ez a katasztrófa!

Remélem nem sértődtém meg!
Azért még kézzel is meg tudok cserélni néhány bájtot. Statikus adatbázisokat építettem és a természetes orderrel könnyebb volt indexelni, illetve lekérdezni. (120-220ns egy lekérdezés, 2-5 táblázat, 3-10M adatsor)
Ebbe nem fér bele a htonl, meg senki nem mondta, hogy pont 4 bájtról beszélek.

Ugyan én lehagytam a szmájlit, de tegyük fel Te is!
Tovább kérdezek: Az FPGA az nagyon kis processzorgyártó lehet az Intelhez képest?
Hiba: A cpu és a processor nem ugyanazt jelenti a műszaki szóhasználatban, pedig mindegyik valamit processzál.
Hiba2: Azér egy FPGA-val megvalósított izét - amit azért készítettek, hogy könnyedén megfejtse a lényegesen lassab kódot - összehasonlítani egy 8-12 páhuzamos végrehajtóegységgel rendelkező RISC processzorral nem tűnik valódi realitásnak. ;)
Merthogy itt a sebességről beszélünk.

Itt már tényleg a logikát kell segítségül hívni. (Igaz/Hamis.)
"Miert lenne gyorsabb a BigEndian?" - Hamis. Nem állitottam ilyet.
"Ha nem kell byteswap-elni pl. halozat miatt" - Hamis. Nem állitottam ilyet. Viszont a hálózaton kívül sok esetben kell cserélgetni nem csak 4 bájtot.
--- Viszont azt sem állítottam, hogy cserélgetni kell bármit is, hanem jó a természetes sorrend. Ahogyan olvasod.
"a természetes orderrel könnyebb volt indexelni" - Igaz.
Oracle/Java kombóval dolgozom. - Hamis.
COleDateTime variable adatstruktúrákat használok. - Hamis.
"5..50x gyorsabb programot is lehet írni" - Igaz. Nevezhetsz hazug hencegőnek, mert jogodban áll nem elhinni. Én azt állítom mértem.

Van sötét oldal is. Ha hozzászoktál az egyenes stack frame használatához, akkor triviális a paraméterátadás sorrendje. Semmi trükk, csak a side effectek figyelmen kívül hagyása. Aztan jön a meglepetés pc-n. Pl.
Function(x++,x++,x++);
Ilyet nem szabad írni, de csak pc-esetén fut le rosszul.

""Miert lenne gyorsabb a BigEndian?" - Hamis. Nem állitottam ilyet."
vs.
""5..50x gyorsabb programot is lehet írni" - Igaz. Nevezhetsz hazug hencegőnek, mert jogodban áll nem elhinni. Én azt állítom mértem."
Ha nem allitod, hogy gyorsabb a BigEndian, akkor mitol lehetne gyorsabb programot fejleszteni ra?

"Function(x++,x++,x++); Ilyet nem szabad írni, de csak pc-esetén fut le rosszul."
Ez hogy tud "rosszul lefutni"?
Tudomasom szerint a sorrend a forditotol fugg. Nincs "rossz" vagy "jo" eredmeny.

Nyilvánvalóan két egyforma sebességű cpu byteordertől függetlenül tölt, vagy ad össze.

vs.

"mitol lehetne gyorsabb programot fejleszteni ra?"
Hát attól, hogy kimarad néhány overhead:
- nincs "#include "
- nincs strncmp() és társai
- nincs atoi()
- gyorsabb a pascal string kezelés (füllentettem, csak 1-2%)
- az előbbi miatt előszeretetel használják a hossz+első karakter==balra igazító rendezést
Hiába írtam (héber,olvasod) nem jöttél rá, hogy ez text feldolgozásakor használható ki. Legjobb példa két irányítószám összehasonításakor nem használt atoi(), vagy strncmp(..,..,4) helyett *(int *) használata. Közben a text a helyén marad. Az utóbbi műveletnek a végrehajtási ideje meg 0..1 órajel!

"The order of evaluation for function call arguments is not specified. In the following example:
method(sample1, batch.process--, batch.process);
the argument batch.process-- might be evaluated last, causing the last two arguments to be passed with the same value."
Tehát nem a fordítótól függ, hanem nem tudjuk. Ha utánanézel, ez így van a legtöbb fordító esetén.
Az idézet ugyan IBM C-hez tartozik, de hasonó a gcc is. Tehát hibásan programoztam, de csak akkor derült ki, amikor ezt a marhaságot linuxon fordítottam le.

Nekem ugy tunik, hogy gondjaid vannak a hordozhato kod irasaval...

"- nincs "#include ""
Compile time overhead... semmit nem jelent.

"Legjobb példa két irányítószám összehasonításakor nem használt atoi(), vagy strncmp(..,..,4) helyett *(int *) használata."
Ez az, csupan nem hordozhato egyreszt az endianness miatt, masreszt pedig a strict alignment miatt. Ha a kernelednek kell megoldani a nem igazitott memoriaeleresedet akkor meg maris sokkal tobbet buktal az egeszen. Azt az aprosagot meg remelem nem kell mondanom, hogy az a szerencsetlen int nem feltetlenul 4B es raadasul igy semmi hibakezelesed sincs. Marhara megerte.
Raadasul ez egy nagyon durva corner case. El nem tudom kepzelni, hogy ilyen gusztustalansagot irjak hacsak nem az utolso orajelet is ki kell facsarni a gepbol... Sok sikert ennek az atultetesevel zip code-okra, meg ugy altalanossagban barmire ami nem egy 4 jegyu szam.

"Tehát nem a fordítótól függ, hanem nem tudjuk. Ha utánanézel, ez így van a legtöbb fordító esetén."
Ez pontosan azt jelenti, hogy a forditotol fugg... A szabvany a forditora bizza. Ha a forditonak ezek utan nem muszaj erre garanciat adnia neked.

"Tehát hibásan programoztam, de csak akkor derült ki, amikor ezt a marhaságot linuxon fordítottam le."
Tehat az x86, ARM, stb. mind sz#r mert a te hibas kodod nem ugyanugy viselkedik rajtuk mint a masik rendszeren ahol szinten nem szabadott volna hasznalnod. Egeszen erdekes logika.

Ez a hordozhatóság valami mániaféle lehet. A leghosszabb élettartemú rendszerem 19 évig futott POWER processzororon. Sem szándék, sem cél, sem lehetőség nem adódott/merült fel bárminemű hordozásra. Sőt, kifejezetten IBM(/Motorola - akkor még) processzorra írták az alaprendszert. Én meg a környezetét. Ezt a rendszer 15 évig ment. (Nem vindóz, nem kell havonta frissíteni.)

"Compile time overhead" - Ott írom: runtime.

A strict játszik.
Pro:
- Ebben az esetben tutkó 1 órajel lesz az olvasási idő.
Kontra:
- Azért 1995-től olyan szerkezeteken dolgoztam, ahol néhányszor szélesebb a memória, mint a mai pécéken. Sőt, egy memória ciklus alatt egyszerre több címről is olvasnak. (POWER5 12 csatornán olvas, 8 csatornán ír. Bár itt keverek egy két dolgot, de a load előtt még történik néhány dolog.)
- Természetesen index esetén használtam az align-t. (van olyan is, hogy allign power!)
- Hibakezelés? Runtime szóba se jöhet. Adatstruktúra szempontjából az előző 5 rendszer már elvégezte az ellenőrzést. Akár azt is megengedhetem, hogy szétszálljon a program. Ebben az esetben megállunk, és az előző programokat kell kijavítani.
- Igen, az int barátunk. Olvastam vagy 20 éve C tankönyvet is. Meg azért teljesen mellékesen, azt megelőzően hw fejlesztő voltam. Én már FOGTAM is bájtot!;) Legtöbb esetben 32B vagy 64B, ritkábban 128B hosszú intet használok, még 32 bites rendszeren is. 64 bitesen is fordul, nem úgy mint linuxon.
- Valahol írták, hogy átlagosan 5000 soronkén van egy hiba. Az így keletkezett kódok olyan rövidek, hogy nem lehet bennük hiba. (Hazugság! Egyszer elaludtam, és megnyomtam az egeret! :))))
- Igen, az utolsó órajelet is ki kellett facsarni a gépből. 24 óra alatt 5-6x is le kellett futtatni a feldolgozást. Olyan módon, hogy szünet is van köztük. :) Amikor kézbevettem a dolgot, akkor egy futás 19 óra volt, és futásidő exponenciálisan emelkedett. Később még a feladatok is többszöröződtek.
Mondták is, hogy felesleges ilyen rövid idő alatt lefutnia valaminek...Aztén baleset történt, és milyen jól jött. Mindig azt mondom: gépészeti tűrésszámítás. Megy - nem megy.

"a forditotol fugg..."
Szerintem azért mindketten értjük: Ez a side effect. Mindegyik fordító nem garantálja a végeredményt, tehát rossz a kód.

"Tehat az x86, ARM, stb. mind sz#r mert a te hibas kodod"
Nem mondtam ilyet. Tényleg az én kódom volt rossz. Az ellenérzés abból fakadt, hogy az atomstabil rendszerek mellé még beraktak egy linuxot, és még arra is meg kellett írnom 180 sor programot.

Az alap állításom: könnyű egyenes byte orderrel text feldolgozást programozni.
"Raadasul ez egy nagyon durva corner case" - Mármint az, hogy sorban olvasom a bájtokat?

Azért ez a hordozhatósággal kapcsolatos szöveged... szóval nagyot zuhantál a szememben.
Nem minden szoftver készül szűk körnek, előre megadott, fix környezetre.

Képzeld el a linuxos utility-ket, ha nem hordozható kódként írták volna meg őket!
(mondok jobbat: ssh, openssl - tudtommal mindkettő BSD-re készült)

Kopp.
Azért írtam már olyan programokat AIX alá, amit PC-n fordítottak hozzá az ott futó programokhoz.
Szűk körnek kellett, az egész országban használták.
EBBEN AZ ESETBEN hiába hordoztad volna. Mit nem lehet értenei azon, hogy nem létezett a szoftver más platformra. (Nem csak az enyém.) Mivel erre készült.
Komolyan mondodod, ha írsz egy csak általad használt rendszert, rögtön Windows 8.1 kompatibilissé kell tenni? (Tutkó az is POSIX :))) És mindenki fikázza, ha nem teszed?

Valahol már emlegettem hasonlót: Egyszer csak egy olyan rendszerhez lett közöm, ahol MQ-t kellett használni. Majdnem kihorpadt a mailboxom - jóindulatú kolléga segíteni akart, ezért küldte a (Windows) java frissítés az MQ integrátor 6.00->6.01 verzióváltásról. Goto IBM: ha natív C az alkalmazás = nem kell semmit csinálnom.
Tehát a java hordozható. :))))))))))))))))))))))))))))))))))
Teherautóval.

Az ssh túl nagy ágyú. Fordítotál már linuxos programot AIX alá? Általában szívás. Ha jól megcsinálták, akkor vannak trükkök:
--disable-asm
#define register
stb.
Vagy felrakod a gcc-t. Akkor mi is hordozható? A program, vagy a gcc?
Vagy inkább van a gcc, meg a világ összes többi fordítója?
Annak ellenére, hogy (többek szerint is) a C az egyetlen normális hordozható nyelv.
Vagy az IBM igensok (ipari) szabványnak megfelelő fordítója rossz?
Föl kéne ébredni! A hordozható az esetek 90 százalékában == megírták arra is.

Szerinted hordozhatóság = M68000 assembly-ben írt programnak fordíthatónak kellene lennie Z80-on is. (némileg eltúlozva).
De mindegy, hosszú...
Lényeg, hogy a hordozhatóságra törekvés nem csak egy betegség, csak nehézségekbe ütközik a kivitelezése. :)

"...fordíthatónak kellene lennie Z80-on is"
Már megint nem mondtam ilyet. Sőt azt sem értem milyen kijelentésemből vontad le ezt a magvas gondolatot. De tényleg!

Csak annyit állítok, hogy néha a deklarált igen jól hordozható dolgok nevetségesen nem hordozhatók.
Windows szerverre pl. így oldom meg: linux - (hálózat) - cygwin+windows. Know-how: nem indítunk shellt! Igen egyszerű C programok installkor fordulnak. Aztán bilibe lóg a kezem!!
Két egyforma gép, egyforma 64bites szerver, 64bites cygwin. Az egyiken 32bit, a másikon 64bit a file offset. Nem értem. Megoldom, de nem értem.

Az ember meg mindig törekedett pl. a repülésre. Jól hangzik!! Most csak a klotyóra megyek!!!
Pedig oda még a király is gyalog jár. Tehát repülés mellőzve, bárki elitélhet.
Szóval nem értem miért kell törekedni valamire, amire akkor nincs éppen szükségünk. Ha nincs pl. piaci vonzata, akkor csak játék. Ha van piaci vonzata, de mégsem működik, akkor marketing.
Olyan jut eszembe, amikor a részeg cowboy - alig bír felmászni a lovára - átlovagol az utca túloldalára.

A hozzáállásom pontosan az volt, hogy adott 12db POWER/AIX szerver. Az ezeken futó szoftver nem létezett más platformra. A rendszert kiegészítő szoftvereimet szintén erre a platformra optimalizáltam, mivel más platformon nem létezett az, amihez írtam. Üzemeltetni is kellett, és kiszámoltam a szükséges futásidőt.

Erre szememre veted, hogy nem hordozható a kód.
Csak nem derül ki, hogy hova, meg miért kellene hordozni.

A lényeg persze elsikkadt. Miért nem PC alapú volt a rendszer? Mert arra ez a megoldás nem létezett, és nem volt olyan oprendszer/vas, amely a kívánt rendelkezésreállást biztosította volna.
Ez még egy érv amellett, hogy minek kellene hordozni, amit nem kell hordozni.

Összegezve: Találkoztam hordozhatósággal. Írtam hordozható kódot. Ez a topic a "UNIX szerverekről" szól. A táblázatban benn van az IBM. Ilyen gépeken dolgoztam igen hosszú ideig. A gépekben bigendian van. Nos, ezért nem említettem pl., hogy sajnos 2 évet .NET-ben is programoztam, mert szégyelem.

Bocs, a hordozhatóságot nem én kezdtem feszegetni.
Én csak akkor szóltam bele, amikor gyakorlatilag betegségnek nevezted a "hordozhatósági mániát".
Nem vetettem semmi ilyet a szemedre, amit írsz.

A hordozhatónak nevezett kódot egyáltalán nem tartom hülyeségnek (értem ezalatt, hogy úgy megírni egy programot, hogy ha a szükség úgy hozza, akkor könnyen át lehessen tenni más platformra, mint amire készült).

-----------
E száltól (majdnem) függetlenül: a bájtsorrendet anno hardveres okok miatt kezdték cserélgetni, mert - már nem tudom, milyen architektúrán - gyorsabb volt az integerek regiszterbe töltése(?) ha a memóriában fordított sorrendben tárolták őket.

Roger.
A bájtsorrend a Motorola Intel eltérés miatt alakult. A 8080 a fetch után dekódolta, hogy el kell hozni egy adatot. Az adat elhozása közben - hoppá mégegyet. Ezért a kisebbik helyiértéket hozt el először. Oka: mikroprogramozott volt a kód végrehajtás. A rivális képes volt egyszere dekódolni.

""Compile time overhead" - Ott írom: runtime."
#include mit runtime overhead? Basszus, tanits Mester!
Tipp: ha atoi(), strncmp() stb. helyett ntohl()-t hasznalnal a peldadban, akkor (helyes adat eseten) mukodne BE es LE gepeken is, BE eseten meg mindig overhead nelkuk...

"Sőt, egy memória ciklus alatt egyszerre több címről is olvasnak."
Mikor lattal utoljara "PC"-t? Szerintem picit le vagy maradva.

"- Hibakezelés? Runtime szóba se jöhet."
Tough code

"Akár azt is megengedhetem, hogy szétszálljon a program."
Jah... jo esetben osszeomlik... rossz esetben csinal egy hibat egy adatstrukturaban ami hatassal van a rendszer mukodesere, de a hiba okat eszlelni nem lehet

"Meg azért teljesen mellékesen, azt megelőzően hw fejlesztő voltam."
Latszik...

"Én már FOGTAM is bájtot!;)"
Jujj de jo neked!!!!!!! Engem szamitogep kozelebe sem engednek...

"Legtöbb esetben 32B vagy 64B, ritkábban 128B hosszú intet használok,"
na persze a peldad hibatlanul mukodik mind a harom esetben... jah nem

"- Valahol írták, hogy átlagosan 5000 soronkén van egy hiba. Az így keletkezett kódok olyan rövidek, hogy nem lehet bennük hiba."
B+ ezt te sem gondolhatod komolyan! Ez latszolag hibatlan kodra vonatkozik. Ha eleve a hibakezeles kihagyasaval irt gusztustalan egy gepre osszeganyolt kodrol van szo akkor ott minden sor egy hiba...
Ennyi erovel mindenhol hagyjuk ki a hibakezelest mert attol sokkal megbizhatobb lesz a program.

"Nem mondtam ilyet. Tényleg az én kódom volt rossz. Az ellenérzés abból fakadt, hogy az atomstabil rendszerek mellé még beraktak egy linuxot, és még arra is meg kellett írnom 180 sor programot."
Vagy egyszer megirhattad volna normalisan...

"Az alap állításom: könnyű egyenes byte orderrel text feldolgozást programozni."
Tovabbra sem igaz, mert hibas nem hordozhato kodot eredmenyez. Raadasul tovabbra sem latom, hogy honnan jonne az a szuper 50x-es sebesseg.

"Mármint az, hogy sorban olvasom a bájtokat?"
Nem, az hogy 4B-ot (vagy 2-t, vagy 8-at...) szoveg helyett szamkent kezelsz es mukodik is. Allatira semmit nem jelent mar ha barmi mas string muveletet akarsz hasznalni.

Természetesen jogodban áll bármit úgy kiforgatni, hogy jobban tudjál fröcsögni.
Megtanitalak: Az include hiánya nem a fordító tehermentesítését hivatott biztosítani. Hanem azt jelenti, hogy mellőzöm a string függvények használatát, mert lassúak. Ha kezdő vagy, olvasgass e témában: joelonsoftware.

Tipp: ha atoi(), strncmp(), ntohl() bármelyikét lefuttatod egy utasításban egy processzoron, kérlek azonnal értesíts! A 65536 magos gép nem ér, de ilyen mán a 80-as évek közepén is volt.
"..rossz esetben csinal egy hibat egy adatstrukturaban..." - Ilyen esetben 2 perc alatt derült ki a hiba.

"...Ez latszolag hibatlan kodra vonatkozik..." Van olyan, aki képes hibátlanul programozni. Igen, olvastam a Jurassic parkot. Ezek lényegesen egyszerűbb rendszerek. <=> Nem fogadom el azt az állítást, hogy a hozzá nem értő "hibakezelés" alkalmazásával jó programot tud írni.
Ennek van fizikai oka is: Nem írok interaktív programokat. A programnak le kell futnia, nem olvassa senki a hibákat. Mire elolvasnák már késő. Ezt alapos tervezéssel ki lehet védeni.
No, ez a megbízható programozás kulcsa.

"Legtöbb esetben 32B vagy 64B, ritkábban 128B hosszú intet használok," => Nem, nem egyszerre, nem vagylagosan, nem 3 bit tárolására, hanem a célnak megfelelően.

Az 50x sebességet könnyedén kalkulálhatod, ha az itt szerplő kódot összeveted pl. 2-3 órajellel: http://hup.hu/cikkek/20131205/tortenelmi_melysegbe_estek_a_unix-szerver…

A kód hordozhatóságáról minden információt megtalálsz feljebb.

Röhögni meg akkor szoktam, amikor a "PC"-t hasonlítják össze egy szerverrel. Nézz meg már egy olyan adatot, hogy az 1.8GB/s memóriasebességet, 1 buszon 4 CPU mikor érte el Intel vagy AMD platformon! Hogy ne maradjak ennyire buta, add meg azt a pontot, amikor előnyre tettek szert.

"Megtanitalak: Az include hiánya nem a fordító tehermentesítését hivatott biztosítani. Hanem azt jelenti, hogy mellőzöm a string függvények használatát"
Ennek mi koze az #include-hoz? :) Kesobb leirtad, hogy nem hasznalsz strncmp()-t igy ez picit redundans.

"Tipp: ha atoi(), strncmp(), ntohl() bármelyikét lefuttatod egy utasításban egy processzoron, kérlek azonnal értesíts!"
Nagyon szivesen: Az ntohl() barmelyik BigEndian rendszeren 0 ciklus alatt lefut, tehat semmibe sem kerul berakni a programba.
Ez a FreeBSD ntohl man page-bol van:
"On machines which have a byte order which is the same as the network order, routines are defined as null macros."

"Nem fogadom el azt az állítást, hogy a hozzá nem értő "hibakezelés" alkalmazásával jó programot tud írni."
Nem allitottam ilyet. Viszont aki kihagyja a hibakezelest az nem hozzaerto. Baromi jo otletnek tunhet pl. nem ellenorizni egy read() visszateresi erteket, hiszen egy elagazast megsporolhatsz vele es legtobb esetben ugyis annyi adatot ad vissza amennyit kertel... Aztan egyszer nem jon ossze es mar van is egy csunya hibad amitol lehet, hogy nem omlik ossze a programod, hanem helyette csak szimplan hibakat okoz az adatbazisodban amiktol majd mashol jelentkeznek problemak...
...hetekkel kesobb.
Ugyanigy jo otletnek tunhet az int pointer cast, csak allati nagy kar, hogy igy siman lehet, hogy az ott levo adatod nem is egy szam, vagy akar a az egyik bajtod veletlenul pont egy 0 lett volna. Jok az eselyeid, hogy mire megtalalod a hibat mar tobb heti/havi valtozasok vannak az adatbazisban es lehet gondolkozni a kitakaritasan.

"Az 50x sebességet könnyedén kalkulálhatod, ha az itt szerplő kódot összeveted pl. 2-3 órajellel"
Csakhogy egy valos program ennel valamivel tobbet szokott csinalni. Premature optimization is the root of all evil.

"Röhögni meg akkor szoktam, amikor a "PC"-t hasonlítják össze egy szerverrel. Nézz meg már egy olyan adatot, hogy az 1.8GB/s memóriasebességet, 1 buszon 4 CPU mikor érte el Intel vagy AMD platformon! Hogy ne maradjak ennyire buta, add meg azt a pontot, amikor előnyre tettek szert."
Ha a rendszer elbirja a rabizott feladatot akkor teljesen mindegy hogy amugy egy primitiv vacak. Sokkal fontosabb viszont az eszkoz ara, a fenntartas ara, es hogy hiba eseten milyen gyorsan lehet javitani. Ha veszek ket cseregepet az eles rendszer melle az egy szuper szervered arabol es kozben hozza a rendszer a teljesitmenyt akkor allatira nem fog erdekelni a memoriabusz sebessege.

"...picit redundans."
Nem eléggé! Így is nehéz egyeseknek megérteni.

"Az ntohl() barmelyik BigEndian rendszeren 0 ciklus alatt lefut"
Csak úgy ismételgetem magamat. Ez a függvény - pontosabban a htonl() Zahy hozzászólásában szerepelt először - méghozzá abból az okból kifolyólag, hogy jó a nem BE is, csak futtassam le. Mire válaszoltam: nem mindig 4B a feldolgozás tárgya. Konklúzió: Igazad van, de csak akkor, ha erre a függvényre nics szükség. Akkor meg nekem van igazam: Gyorsabb a BE.

Már kétszer is jól kifogtál rajtam. Csak a két oldalas ciklusokat tartalmazó string függvényről hallgatsz.

Ördögöd van ezzel a read() hibakezeléssel. (Bár nem tudom mi köze a BE text feldolgozáshoz.)
Ha beolvasta, kezelem. Eddig rendben. Ha nem, sajnos a program kilép. -> Szerelő, hw hiba van. Más esetben az előző programot kell javítani. Ezt tényleg nem tréfának szántam.
Az int pointer cast esete dettó. Ha 0 van egy 8M soros text fájlban, (még mindig text feldolgozás) az nem lehet más, mint memóriahiba. Az meg nem lehet, mert a szerver lekezelte. (Egy ilyet láttam, 15M volt a kártya, de régen és szerencsére garanciális.) -> Az előző programot kell javítani.

"Csakhogy egy valos program..."
Okostojás. Én meg Cpu Géza vagyok és benchmarkot futtatok fejben.
A teljes programrendszeren kb. 50 optimalizálást végeztem a diszkek hangolásán, és adatszervezésen át az adattartalom javításáig. Eközben a futásidő nyolcada lett az eredetinek.
Az előző optimalizálás a C++ leváltása, a működés pontosítás volt és csak egy programot érintett a rendszerből. Ott kb. 40x lett gyorsabb a program, igaz volt egy gépcsere is.

"...veszek ket cseregepet..."
Vegyél. Az én rendszereimet 2 perc alatt tudta javítani akár egy félhülye operátor. Legalábbis teszteltük, de nem került rá sor 10 év alatt.

"Mire válaszoltam: nem mindig 4B a feldolgozás tárgya. Konklúzió: Igazad van, de csak akkor, ha erre a függvényre nics szükség. Akkor meg nekem van igazam: Gyorsabb a BE."
Igazan mutathatnal meg peldat ahol a BE gyorsabb mert nem hiszem, hogy az iranyitoszamok osszehasonlitasa ennyire szeleskorben elterjedt problema lenne. (Raadasul pont 4B-os, tehat ntohl() es meg van oldva.) A BE tovabbra sem gyorsabb csak egy corner case-t talaltal.

"Ha beolvasta, kezelem. Eddig rendben. Ha nem, sajnos a program kilép. -> Szerelő, hw hiba van. Más esetben az előző programot kell javítani. Ezt tényleg nem tréfának szántam."
Gondolom tisztaban vagy azzal, hogy a read() visszaterhet hibaval/vartnal kevesebb beolvasott adattal akkor is ha nincs hw hiba es a hivas megismetlese eseten a vart eredmenyt kapnad. Ez csak egy pelda volt arra, hogy mennyire nem mindegy a hibakezeles kihagyasa. ;)

"Ha 0 van egy 8M soros text fájlban, (még mindig text feldolgozás) az nem lehet más, mint memóriahiba."
Nem gondolod hogy ebben az esetben jobb lenne leallni mint esetleg osszefirkalni az addig helyes adatokat?
Amugy lehet mas is:
- merevlemez hiba
- elozo programban kihagyott write hibakezeles es nem is ment ki a puffer ;)
- ebben a programban kihagyott read hibakezeles es nem is lett megtoltve a puffer ;)
...elvegre a hibakezelestol csak nagyobb eselye lesz a hibaknak. :)

(Mellesleg mi a fenenek is irogatsz text fajlokat a programok kozott?)

"A teljes programrendszeren kb. 50 optimalizálást végeztem a diszkek hangolásán, és adatszervezésen át az adattartalom javításáig. Eközben a futásidő nyolcada lett az eredetinek."
Gondolom ebbol valami hatalmas darab lehet az, hogy int-kent kezelsz 4 karaktert. :)

"Vegyél. Az én rendszereimet 2 perc alatt tudta javítani akár egy félhülye operátor. Legalábbis teszteltük, de nem került rá sor 10 év alatt."
Megneznem a 2 perc alatt alaplap- vagy tapcseret amit ra mersz bizni a felhulye operatorra a sok millios gepen. Sot, azt is megneznem akar amikor a felhulye operatorra rabizod a backup visszaallitasat.

A "corner case-t" Ti találtátok, nem értvén még a példát sem.

Elfogadom a gondosan indokolt álláspontodat. Nyilvánvalóan Te programoztál többet BE cpu-n, több adattal. Én viszont hibásan mértem. (A francba! A gép naplózta a futásokat.)

Lila fingom sincs a read() tulajdonságairól. Még csak 35 éve írok programokat. Remélem megtanítasz valami újra is!

Kicsit hátulról kezdve a text fájlok azért vannak, hogy heterogén rendszerek között adatot lehessen szállítani. (Nem erről van szó, de az xml is text fájl. Újat mondtam volna? Magánvélemény: Annyival rosszabb a unix texnél, hogy a sorvéghez is algoritmus kell, de az sem biztos. :))) Vannak olyan rendszerek, amelyek eltérő algorimussal tárolnak adatokat, így ezek között formátumkonverziót kell beiktatni. Egyes rendszerek naponta többször adhatnak nagy mennyiségű adatot, rádásul van olyan agyament dolog, hogy egy adatsor egyes elemei külön úton érkeznek, ezért párosítani kell őket. Valószínűleg a mai adatok önként és dalolva vetik magukat az adatbázisba, és 0 (zérus) idő alatt betöltődnek, de régen ez nem így volt. Bár valami fiatal mesélte, hogy ma sem így van. ;) Az általam emlegetett példában meg speciális statikus adatbázisokat kellett előállítani. Ezek olyan adatbázisok, amiről nyilván megállapítod, nem is az, mert nem Oracle. :))

Vegyük a hibákat! Alapvetően egy szerver nem a Te PC-d!
Merevlemez hiba lehet ugyan, de - miközben nem állítom, hogy a program nem tartalmaz hibakezelést - nem fogom a text feldolgozó programban észrevenni, mert
- Az csak stream-ot olvas, miközben az elé kötött gzip már kilépett. No, AZT a hibát kezeli a program. Csak nem a text feldolgozás, mert annak más dolga van.
- Ha az előző programban kihagyott hibakezelés van, akkor nem futtatjuk úgy sem élesben.
- Mégegyszer merevlemez. Kiesett. 2 óra helyett 8 alatt ment le a feldolgozás, mert csak kettő maradt a tükörben.
- Ennél súlyosabb eset is volt, pulzáló 380-at kapott a rendszer. Nem a text feldolgozás jelezte, hanem maga a szerver írta ki: 001 = Hibás a hálózati feszültség.

Most már kéne egy bézbólütő. A 4 bájtos int PÉLDA VOLT.
50 optimalizálás esetén
- Részben a kód egyszerűsödik, tehát megbízhatóbb és gyorsabb lesz
- Új funkciók kerülhetnek be, lehetőleg nem lassítva -> Ezt elmagyarázom: Fut egy diszket terhelő program 1 idő alatt. Ha hármat indítok, akkor 8x annyi idő. Becsaptalak, windowson:)
Itt meg mondjuk 2,5 idő alatt. Csak ehhez jól kell elosztani a terhelést, meg hangolni a diszket.
- Összegezve 50*2% optimalizálás esetén elméletileg akár 3x gyorsabban futhat a rendszer.
- Ez a 3 nekem 8 lett.

Mint emlegettem, azok a 4 bájtos intek helyett különböző string átalakítások, rendezések, és string vagy nem string jellegű indexelések mentek.
Ezek az előfeldolgozások kb. 12%-át tették ki a teljes futásidőnek. Az utolsó gyorsítás 4,5-ös szorzót jelentett, miközben 4 előtétprogramot beépítettem, amelyeknek darabonként hasonló, vagy több volt a futásidejük. Ez több mint 22x gyorsabb mint az előző verzió.

A félhülye operátor nem nyúlhat a géphez, csak az üzemeltető. Viszont egy vagy két diszket be vagy átdughat. Meg még át kell írni pár paramétert. (El kell olvasni a doksit.) Ebben az esetben 3 rendszer fut 2 gépen, és minden rendszert át lehet dugni a szomszéd gépbe, ha a gép durranna el.
Backup visszaállítására - baleset okán - 20 év alatt kb. 50 gépen nem került sor.
Olyan rendszereket szoktam tervezni, amikor hasonló - de nem feltétlenül azonos gépeknek egy metése van. Adatokat meg gyakran azért nem mentettünk, mert - hála a kis futásidőnek - a bemenetből hamarabb lehetett adatbázist építeni, mint visszatölteni. :))))

fyi octet stringnel nincs byte order

wordkent stringet vizsgalni, meg nyilvan lehet LE-n is:

http://nxr.netbsd.org/xref/src/common/lib/libc/arch/x86_64/string/strcm…

ps.: ha meg azon mulna egy kod sebessege, hogy mennyire van kozel az irt alakhoz, akkor mindenhol BCD-t hasznalnank

--
NetBSD - Simplicity is prerequisite for reliability

Ebben a kontextusban maximum a szemmel debuggolt hexa dumpnal lehet jobb a BE, kulonben tok erdektelen a byte sorrend amig nincs interoperatibilitasrol szo. Ott meg definialod, h a data exchange mondjuk network byte order es csok. De ez is csak binaris adatkozlesnel erdekes. :)

---
pontscho / fresh!mindworkz

Ezek open source projektek voltak mind, amennyire tudom.
Szóval én inkább úgy gondolom, hobbiból készültek az ilyen emulátorok, nem anyagi haszon reményében.
Ha nagyon megerőltetném magam, talán egy R22 szimulátort(IBM S/360) még én is meg tudnék írni, nem volt annyira bonyolult a régi mainframe-ek belseje (mai szemmel nézve). Lehet, hogy az AIX-t futtató vasak már bonyolultabbak, esetleg nincs elég nosztalgikus értékük vagy nem tudom miért nem írtak ilyet. :)

Nekem valahol van egy VAX emulátorom is, az sem valószínű, hogy bármiféle bevételt hozott volna az írójának.

Ebben tévedsz, igazán gyors megoldást inkább ezekhez találsz, mint a linuxos pécékhez. A HW nyűgjei ritkán érkeznek meglepetésként, pl. a HP-UX-ban lévő diagnosztikáról pécés körökben álmodni sem mernek. Egy rákfenéje van mindezeknek, fizenti kell értük és nem keveset.

( ratbeton | 2013. 12. 06., p – 15:44 )

azert ilyen hamar ne irjuk le az unixot, foleg olyanok nem, akik nem is dolgoztak vele. linuxon dolgozni es unixon dolgozni nem ugyanaz, felesleges lenne egy meregdraga AIXot osszehasonlitani meg a legfaintosabb piroskalap uberfaintos valtozataival, mert nemhogy egy ligaban, de ugyanazt a sportot sem jatszak. a tuning corsat, amit mindennap hegeszteni kell hogy ne essen szet es el ne lopjak csak nem hasonlitanam ossze egy rollsal a futott garazsban.
erdemes utananezni pl mint tud egy PowerVM (gugli, powervm features). vannak dolgok, amiben egy biztosito, bank vagy egy energatikai ceg (itt melozok) nem akar belefutni mert van boven penzuk arra, hogy elkeruljek a kockazatot. aztan ha megszoritasokrol beszelunk ezekben az agazatokban, akkor a legjobb helyben felkotni azt a madar projectmanagert, aki a rendszer biztonsagat/stabilitasat akarja felaldozni a szaros ev vegi bonusza fejeben, majd tovabball ...
kedvenc kombom, mikor a tegnapi newsletter arrol szolt, hogy megszoritunk (divatbol) a mai meg a tobb $milliardos netto negyedevi nyeresegrol ... hagyjuk mar :-D

( b | 2013. 12. 06., p – 20:20 )

Huh túl sok lett itt az IBM-es és HP-és marketinges skacok...

na császtok...

--
GPLv3-as hozzászólás.

Nevesítenél is marketingeseket? Pl. HP-ről Saabi és én beszéltünk kb egyedül, és ha én vagyok a HP-s marketinges, akkor ezt lécci a HP-nek is jelezzed, mert akkor felvenném az érte járó zsetont.
Tehetünk mi arról. hogy jónak tartjuk a klaszikus UNIX-okat? És mi a baj azzal, ha ezt egy valamikori UNIX-portálon nagyritkán megjeleő valóban UNIX és nem Linux tartalmú cikk kapcsán hangsúlyozzuk is?

Linux Rox!Linux Rox!Linux Rox!Linux Rox!Linux Rox!Linux Rox!Linux Rox!Linux Rox!Linux Rox!Linux Rox!Linux Rox!Linux Rox!Linux Rox!Linux Rox!Linux Rox!Linux Rox!Linux Rox!Linux Rox!Linux Rox!Linux Rox!Linux Rox!Linux Rox!Linux Rox!Linux Rox!Linux Rox!Linux Rox!Linux Rox!Linux Rox!Linux Rox!

egy kis ellenmarketing, legyel boldog.