Lényegében ráfogható, hogy hd video-t tudni kell valaminek lekezelni, flash igényei nőttek...
Valaki úgy tudna-e programozói szemmel erről mesélni valamit?
Hozzászólások
A programokat ugy irjak, hogy az atlagos gepeken menjen. Ha az atlag emelkedik, akkor hamarabb abba lehet hagyni az optimizalast. Ceg szemszogebol ha az atlagos gepen megy, akkor penzpocseklas tovabb foglalkozni vele (a programozok kapnak uj feladatot). Szabad szoftver eseten van esely, hogy jobb lesz valami, ha akad valaki, aki hajlando ingyen x orat beleolni, hogy 1-2%-al gyorsabb legyen. Mindig is igy volt es igy is lesz.
Nem hinnem, hogy ebben barmi IT specifikus lenne...
túl sok tényezõs a szoftverfejlesztés és tágabb értelemben maga az értékelõlállítás, hogy ilyen egyértelmũen kijelenthessük, hogy amikor a jövõben változni fognak a paraméterek (emberek hozzáállása, énközpontúság, harácsolási vágy, környezeti tényezõk, nyersanyag, gazdaság, ...), egyik se indukálná az általad vázolt helyzet változását.
Nekem ugy tunik, hogy mindenhol a cel minoseg teren az az "elfogadhato". Nem a "nagyon jo", es megcsak nem is a "jo". Nem feltetlenul munkasok (jelen temaban a programozok) tehetnek errol, ha a projekt elfogadhato szintre kerul, akkor kezdodik a kovetkezo projekt.
Ezert irtam azt, hogy a szabad szoftver-nek van eselye jobb lenni, ugyanis ha valaki nem penzert, hanem hobbibol dolgozik valamin, akkor tobb idot eltolthet egy kodreszlet optimalizalasan mint amennyit egy cegnek megerne kifizetni. A hangsuly az "esely"-en van, vagy osszejon, vagy nem. Egy ceg ezt szinte soha nem fogja megengedni maganak (kiveve, ha a fonok egy perfekcionista, akinek nem szamit a penz, de a termek tokeletes legyen; na ilyen nem sok setal az utcakon...).
Ez a szabad szoftver hobbiból fasság mikor fog kikopni a köztudatból? Semmi köze a kettőnek egymáshoz.
Hobbibol irt szoftver gyakran lesz szabad szoftver. Sokkal kevesebben dolgoznak hobbibol zart szoftveren. (Szerintem)
Azt nem allitottam, hogy szabad szoftveren csak hobbibol dolgoznak.
Másrészt a kódminőséget és a dokumentáltságot legjobban a Q&A és a szigorú policy betartatása adja meg, nem a hobbi.
Nem a kodminosegrol es a dokumentaltsagrol beszeltem, hanem a futasideju hatekonysagrol. Nem feltetlenul van kapcsolat a ketto kozott.
A cég meg akkor fogja megengedni magának, ha bevétele lesz abból.
Mivel egy bizonyos szint folott mar nem hoz extra bevetelt, azon a ponton tul mar nem engedheti meg maganak. Ha valaki nem munkahely miatt csinalja, es nem erdekli a bevetel, mert az hobbi, akkor megcsinalhatja.
Ha csak a webet nézzük, régebben voltak egyszerű szöveges oldalak, néhány képpel. Semmi layout (ha csak a paragraph-ok egymás utániságát nem annak vesszük), semmi style (emlékeztek még a css előtti időkre), minimális szkriptelés (amikor még mindenki azt hitte, hogy a javascript az java) és a legbonyolultabb dolog egy animált gif volt, és az átlag felbontás az 800x600 volt.
Egy mostani weboldal az nagyságrendekkel bonyolultabb, változó layout-ok, style-ing, javascript könyvtárak tömkelege, videók, jó minőségű képek, nagy felbontás (1920x1080).
A régi böngészők nem is ismerték a tabokat, egyszerre csak egy oldalt néztél, nem volt olyan, hogy 200 oldalt betabozva tartasz, mert elfér.
Ja, hogy te operát használtál :) Ettől függetlenül sokkal bonyolultabb oldalakat kell lerenderelni, illetve régebben még csak 16-32 mega (vagy 4-8, attól függ mennyire
megyünk vissza) állt rendelkezésre, most az alap az 1-2 giga, tehát bőven van hely, ahova be lehet cache-elni dolgokat a gyorsabb működés érdekében..
Mondjuk már akkor is 60 GB-s hdd-m volt. i815 nek hála, csak 512 MB ramot tudtam használni, pedig a koliból hoztam rendesen tartalékot.
Mondom 3 slot van akkor 3x512 menni fog, de csak 256-osak voltak ezért 3x256-ot akartam bele rakni. Na ebből sem lett semmi.
Ekkor maradtam a 2x256MB-nál.
2006 környékén nekem 120G-s hdd-m volt, 512M rammal egy olyan lapon amit 4-ig lehetett bővíteni. Az akkori majdnem legjobbnak mondható nvidia kártyám volt 128M-val, meg egy 2,6-os celeron. A procin kívül minden megvan mai napig. A videókártya pedig megsült, de a gép többi része még mai napig jól fut, bár már korántsem abban a szerepben amit megvételkor kapott. A táp is csak a második benne. Kompletten új házba került 2007 környékén, mikor még a moddolt gépekre voltam rákattanva. Kapott világítást, világító aluventit, emiatt meg egy nagy, 450W-os tápot. Azóta a világítás kikerült, és bekerült egy 3Ghz-s P4 CPU, még 2G ram és egy 80G-s hdd, és ő lett az egyik home szerver...
A másik, hogy 10 éve mondjuk 320x240-es videókat néztünk (ami kipörgette 100%-ra a cpu-t), most meg 1920x1080-ast, közben a háttérben megy a torrent, chat,
stb.
Na na nem pörgette ki a cpu-t az.
volt egy időszak mikor a 480-as videó lazán ment még linux alatt is nekem, és egy idő után már nem.
Akkor jött az, hogy 360-ra visszaléptem.
Lényegében sok minden volt ami belassult. PLD ubuntu 10.04 rendesen kínszenvedés volt már,
9.04 meg hasított.
Oké, értelmesebb lenne, ha időszakot mondanánk, amihez képest. Linux alatt többször éreztem (amikor még linuxoztam), hogy egy update után kicsit lassabbb
lett a rendszer, mint előtte, de ez valamilyen hibás/rosszul megírt komponensre vezethető vissza...
Egyszer egy ismerősöm megkért, hogy fabrikáljak neki egy webshopot Paypal-os fizetéssel kell árulni egyetlen egy dolgot. Mondtam neki, hogy nekem nem ez a profilom, nem is szívesen csinálom meg. De a Paypalos fizetés miatt kicsit mégis érdekelt, úgyhogy azt mondtam neki, hogy megcsinálom ingyen, de a grafikai design-nal nem törődök, azt csináltassa meg mással. Úgyhogy összeütöttem a weboldalt plain HTML-ben CSS nélkül. Az lett a vége, hogy az ürge teljesen oda volt, hogy micsoda jóság ez a minimal design, és hogy hogy kell ilyet csinálni, mert ő is szeretné tudni :-).
Gondolom még nem használtál két full egyforma gépet egymás mellett Win és Linux rendszerrel.
A Win-esben hamarabb elhullik a diszk. Fingom sincs mi a konkrét oka, mégis. 2 diszket nyírt ki az XP míg ugyanaz a típus (egymás utáni sorszámmal, mert egybe rendeltem egy 10-es pakkot) Linux alatt vígan szolgált. szinte ugyanaz volt a két gép dolga, ugyanannyi időt is mentek (egy-két perc különbség volt a lekapcsolás hossza miatt)
gondolom kollega az xp azon remekul marketingelt memoriakezelesi trukkjere celoz, hogy "takarekosan hasznalja" a ramot, azaz a szerinte sose kello lapokat az elott kiszorja a swapfilebe, mielott elfogyna a rendelkezesre allo memoria, aztan gyorsan visszacacheli, mert hatha megis kell. ettol viszont tenyleg elfogy a memoria, es nekiall swappelni.
de az is tokjo feature, hogy egy relative szuz xp ( na jo, office 2k7 azert telepitve ) folyamatosan piszkalja a registryt.
Sosem értettem, minek az a registry-baromság. Még anno Windows-3.11 idején, ha killódott a win, egyszerűen törölni kellett a reg.dat-ot, utána kutya baja se volt egy jó darabig. Persze, akkoriban még nem volt ilyen fejlett ez a feature, csak telepítéskor és programindításkor piszkolgatott bele.
-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba
Kb. arra, mint a ./randatorpe/minden/kutya/farka/mindengombraegystatusz.xml fájlok írogatása: aki arra igényt tart, annak kinyalja a hátsóját, aki nem tart, azt bosszantja.
Mint említettem kettő, az utolsó csavarig azonos gépről van szó. Ok. Az első diszk hiba után tápra gyanakodtam, cseréltem is, egy szintén ugyanabból a pakkból származóra, mégis meghót, ergo a win a hibás...
Egymás utáni darabokról beszélek. Ahogy a gyárból kijött dobozolva az 50 hdd, az első 10 hozzám került. Ott vették ki előttem a dobozból. sorszámaik egymást követték, úgy került a (pl.) x1-es a winesbe, x2-es a linuxosba, majd a winnél cserélve lett x3-asra és így tovább... Amúgy mindegyik a wines gép alatt azonos, cache és fejhibával halt ki, linux alól badseccel halt ki. mondjuk durván, mert 500-ból hirtelen (értsd ~1nap leforgása alatt) 300G használhatatlan lett.
Arra is.
De mi a bizonyítéka annak, hogy ugyan ez nincs benne bármelyik GYŐZELEMdows-ban is?
Hiszen zárt a forráskódja, nem tudhatod pontosan mit is csinál.
Oke, hogy atestel az agymosason, miszerint a master race Linuxot hasznal, mindenki mas pedig segghulye es a Microsoft szolgaja, es ettol felsobbrendunek erzed magad, de ez meg nem jelenti azt, hogy innentol te tudod, mit csinal a geped. Ahogy az mar oly sokszor kiderult, kurva gyakran a (nyilt es zart egyarant) fejleszto sem tudja, hogy mit csinal a kodja, nemhogy egy ilyen mitugrasz, akinek fingja sincs a szoftverfejlesztesrol, es azt hiszi, a forraskod a valasz mindenre, anelkul meg semmi nincs, csak 20 ev sotetseg.
Azonos szériájú lemezeknek jellemzően a legyártó műszak az ellensége, ritkább esetben az egyik alkatrész beszállítója, még ritkább esetben annak a vezérlőnek/alaplapnak a gyártója, amire az diszkeket aggatják.
A gyártó műszak frusztrált dolgozója odaverhet egy egész sorozatot a polchoz, de gyakoribb, hogy (a JIT korunk hőse, de a kamion nem vár) a kiszállítandó mennyiség csak úgy kerekedik ki adott időre, hogy elmaradnak tesztlépések. A ló túloldala, amikor követési hiányosságok miatt éppen túltesztelik a lemezeket, ami átlagos üzemórák ezreit veszi el az életükből.
Nem mérés volt, csak tapasztalat. 2 gép ment egymás mellett. Egyik win, másik linux. Egyszerre voltak bekapcsolva, és leállítva, a munka is közel ugyanaz volt mind2-n, heti 5 nap, 10-12 órában. az eredmény 1 év 3 v. 4 hónap alatt 2 diszk halál az xp-s gépben, utána még 1 évet mentek a gépek ugyanígy, még két diszket megevett az xp-s és a linuxos is elfogyasztott egyet. Samsung hdd-k voltak, amikből amúgy itthon is megy 12 darab, 0-24-ben 1200+ üzemórával egy linuxos gépben (igaz ezek nincsenek mostanság hajtva, csak pörögnek szépen).
Nálunk vannak céges gépek, amik egész nap mennek (estére sem szoktuk kikapcsolni őket), XP-vel, 5-6 évig, mindenféle vinyó probléma nélkül. Simán lehet vinyó (vagy esetleg táp, alaplap, akármi) probléma.
Persze hogy lehet. Cseréltem is tápot, mint említettem. De akkor is fura. Igaz az is, hogy a win esetén sokkal többet kerreg a cucc, nyilván azért a fej halál (egyet szétkaptam, konkréten eltört a fej a házon belül, és a lemezbe egy szép vájatot kreált a törött darab, és mindegyik így halt ki. Ezt minek szabad betudni, ha nem az állandó felesleges terhelésnek?
A 2 gépet is ki kellett volna cserélned (hiszen ugyan olyanok), hogy ténylegesen bizonyítani(?) tudj valamit. Ha a csere után is a Windows gépben hal meg elöbb a HDD, akkor(!) talán van valamid, amit bizonyítéknak még mindig nem neveznék...
Azt mit kellene bizonyítani? Pont leszarom az egészet, csak megemlítettem egy általam tapasztalt dolgot, csak már jöttek habzó szájjal a MS fanok. Szal leszarom a témát. Lényeg, hogy perpill megint többet ment egy ugyanolyan diszkem, ami win alatt rég kihalt.
jó de ő egymás mellé rakott egy wines gépet és egy linuxos gépet és hát a gonosz win megette a vinyót viszont a linux meg minden oprendszerek istencsászára :DD
Nekem vannak lemezeim, amelyeken kizárólag linux ült, nagy magabiztossággal. Nem lesz olcsó, de nem hiszem, hogy a biztonságnak ezért a fokáért sajnálnád a piaci ár dupláját.
Némi felárért kigurulok az állatparkba, és kérek kiegészítőnek pár lapát pingvinszart is.
huh, ezt nem gondoltam volna, hogy ilyen hamar tud valaki szerezni. tenyleg jo ez a kozosseg. most igy az unnepek elott akar a 2.5 szereset is hajlando vagyok megfizetni, azonban van egy kis bokkeno: csak egy fel lapattal van itt a sarokban. esetleg lehetne hitelrol szo? igerem, szilvalekvarral fogom a pingvinjeimet etetni, hogy minel hamarabb fizethessem a maradek reszletet
---
Egy jól megállapított probléma félig megoldott probléma.
- Charles Kettering
Félreértettél - nagy üzleteknél előfordul -, a pingvinguanót is én adom. Legalábbis biztos vagyok benne, hogy a nyíregyházi állatparkban felismerik az open source és a closed penguin szimbiózisában rejlő marketinglehetőségeket.
Laptopokat érinti a probléma, Linux alatt. Egy csomó laptop modellen a vinyó kapott egy optimális, energiatakarékos viselkedést. Előfordulhat, hogy a Linux ezt nem veszi figyelembe, vagy nem úgy, ahogy kéne, ezért simán előfordulhat, hogy 1-2 másodpercenként leparkoltatja tök feleslegesen a vinyót. Ez elkezdi pörgetni ugye a load cycle countot is a SMART-ban, ami hosszú távon nem egészséges. Mármint nyilván nem maga a SMART-os érték, hanem amit mutat. :)
szerk: Ami lényeges dolog, de kimaradt. Ez szerintem ott gyakori, ahol a gyártó eleve windowsra optimalizál, bár ez már csak megfigyelés, nem mérés.
Linux nem parkolja a fejet önmagától, általában a default a winyón van úgy beállítva, hogy fél percenként eltegye a fejet. Én is mire észrevettem az új Seagateken, már 10000 fölött járt a Load Cycle Count. De hdparm-mal szerencsére beállítható (legalábbis ezeken, aztán volt a WD, amihez volt gyári szoftver). Szerinted Windowson nem ugyanez történt volna?
Ez a "gyártó Windowsra optimializál" wichester esetén most hogy? Fogalma sincs arról, hogy mit futtatsz a gépen...
Há' én csak ezt láttam (mellesleg ugyanezt tettem én is a sajátjaimmal):
It's not exaclty a bug, therefore there's no fixing it, rather there is hacking it. Windows machines also suffer from it. Solution for me, at least is running every time when my machine boots, or putting in /etc/rc.local this:
hdparm -B 254 /dev/sda
Valahol bizonyíték arra, hogy a Win kikapcsolja ezt az energiatakarékossági szart? Vagy tudod is, miért nem érinti a Wint, azon kívül, hogy "Windózra optimalizálták a HDD-t"?
Bizonyítékot nem tudok adni, mert nem szeretnék belemenni a reprezentatív / nem reprezentatív című vitába, ami itt elég gyakori.
Viszont két különböző típusú (bár mindkettő Lenovo márkájú) laptopon kipróbálva Ubuntuval, Fedorával és Windows-zal ez utóbbi _lényegesen_ kevesebb load cycle-t produkált. De, mint pár poszttal feljebb írtam, ez megfigyelés, nem mérés.
Na ez az, hogy amiről az ember nem tud biztosat, arról inkább ne írja, hogy biztosan így van. Esetleg a Win laptop kevesebbszer ébresztette fel a HDD-t, ezért kevesebbszer is parkolt le újból a fej, de attól még nem viselkedik eltérően a winyó a két rendszeren. Ezt a magyarázatot még el is hinném.
De nem is akarok erről vitatkozni. Ha neked nincs ilyen gondod, örülj neki, a szál viszont onnan indult, hogy a Windows _direkt_ tönkreteszi a merevlemezeket.
Erre írtam, hogy először poénnak gondoltam, aztán kiderült, hogy nem annak lett szánva :) Úgyhogy ehhez meg inkább nem szólok hozzá :)
Szerintem sokkal egyszerubb dologrol van szo: defaultban a Windows 20 perc idle utan lekapcsolja a diszket, ami rendkivul egeszsegtelen. Ez az elsok kozott van, amit le szoktam tiltani.
Nálam windows alatt is, 2 laptopon is. WD meg Hitachi diszk. Mondjuk egyiken már valami 250k körül jár a load cycle count, a másikon van hdparm, az 20k körül jár.
A gép, amit használok, pont linux alatt nem kattog, windows alatt igen. Előző gépemen meg fordítva volt, még régen. Már a legfiatalabb hdd-m is 4 év körüli, max lecserélem, ha megunja a kattogást/nem kattogást.
Jómagam nem vagyok járatos adattár-üzemeltetésben.
Adataim biztonságát rendszeres (többszintű) backup policyval igyekszem biztosítani.
A diszkekre néha nyomok ugyan egy smartctl-t, de többnyire csak a Reallocated_Sector_Ct, Reallocated_Event_Count és UDMA_CRC_Error_Count értékekre vetek egy pillantást (szeretem őket nullán tudni).
A thread-et olvasva lekérdeztem a Load_Cycle_Count értékét, ami bizony az egyik diszkemen már 1M fölötti (1,209,091).
Kíváncsi vagyok, hogy a témában jártasabb kollégák mit olvasnak ki a smartctl kimenetből.
Kb: 4500 óra üzemidővel ezelőtt valahol a 2639+25(max) szektor környékén nem sikerült olvasni (legalább) egy szektort. Ezt a diszk hibára jegyezte elő, amely a következő írási művelet esetén kihelyettesítődik. Ugyanakkor a hibás szektor bekerül a defect listába -> Reallocated Sector Count +1. Jó esetben.
Ez a hibás szektor - amiről kiderülhet, hogy több - egy ritkán olvasott és nem írt területen található, mivel 4500 óra alatt nem keletkezett újabb hibanapló bejegyzés.
A 193 Load/Unload counter megítélése vegyes. Egyik szemszögből ez a diszk már réget túljutott a garantált élettartamán, amit a Load Cycle Count függvényében specifikálnak. Másrészt ez nem biztosan ungyanaz. Mindenesetre os és diszk részről egyszerre, egymást keresztező pm teljesen felesleges. Erre itt talász magyarázatot.
Ez egy desktop gép, kb 2 naponta bekapcsolod. A diszk 2,5-3,5 éves.
Valóban, ez egy desktop gép. Az itthoni munkaállomásom.
2008-ban került bele az ominózus diszk, ezen van az oprendszer (Gentoo) és a home könyvtáram.
(Van benne még egy 2TB-os Samsung diszk is az adatoknak.)
Kapcsolgatva viszont nincsen, always-on megy. Csak akkor van megbootolva, ha áramszünet van (kéne már új akksi az UPS-be). Fut rajta pár service (pl. privát FTP), hogy távolról is elérjem az adataimat.
PM igazából ezen a gépen nem érdekel, hadd menjen csak, a lényeg, hogy mindig rendelkezésre álljon és minél tovább éljen.
Van pár ilyen öreg diszkem, amik 7/24 mennek (pl. seed szerverben), némelyiken már a Reallocated_Sector_Count sem nulla.
Szerencsére eddig - látszólag - hiba nélkül teljesítenek.
Az üzemidő 15146 óra, 631 nap, azaz kevesebb mint 1 év 9 hónap, ha folyamatos üzemet feltételezünk.
Az 5 év = 1826 nap. Ehhez képest csak 658x indult el a diszk, és 421x volt ki-be kapcsolva.
Valaki téved. Vagy a diszk..
Ehhez a típushoz product review-t csak 2009 évben találtam.
Megmondom őszintén, hogy keresem, de nem találok egyértelmű információt.
Arról van szó, hogy ezek így néznek ki:
Standby Actuator is unloaded and spindle motor is stopped. Commands can be received
immediately
Sleep Actuator is unloaded and spindle motor is stopped. Only soft reset or COMRESET can
change the mode to standby
Nomármost, ha a "spindle motor is stopped", akkor utána induláskor a start/stop count növekszik eggyel. Ez így tisztességes, mert a felpörgetés gyilkolja a csapágyakat, tehát az élettartem miatt illik megszámolni.
Az üzemidő nem is üzemidő, hanem "power on hours count". A fenti két üzemmódban power van, csak eléggé csökkentett az áramfelvétel. Jó kérdés, hogy ez az állapot bekapcsolt-e vagy nem, de egyértelműen van rajta villany. Ha nem így lenne, akkor a power cycle count növekedne.
A számokból úgy néz ki, hogy a felpörgések száma 658, míg a ki-be kapcsolások száma 421. Ha folyamatosan ment a gép 5 évet, és a sleep üzemmód nem számít bele az üzemidőbe, az csak úgy lehetséges, ha a sleep átlagosan minden esetben akár több napig is tartott. Természetesen ez idő alatt működhetett a gép, de semmit nem írt a diszkre és nem olvasott. Ez nem életszerű.
Pótlehetőség: A számláló 2 byte hosszú (inkább 31 bit abszolút érték) és körbefordult. Ekkor a diszk 5 éves és 2 hónapos. Akkor ez egy vendor specific fícsör, mert nekem vannak 40-45000 órás diszkjeim. Ebben az esetben igen gyakran van felétek áramszünet - 5 év alatt kb. 400 esetben.
A magas számú load cycle count egy olyan laptop pm, amikor kihúzza a fejet, hogy mozdításnál ne szántson bele az adatterületbe, de a motor megy tovább. (actuator unloaded) Ezzel csak kopik a rendszer, de spórolni nem lehet.
A SMART Power On Hours sora - legalábbis a Hitachi lemezeken akkor is növekszik, ha amúgy a motor áll. Ezt onnan tudom, hogy idén január vége felé vettem két lemezt, amik azóta 24/7-ben mennek. Ezek közül az egyik 7911, a másik 7920 órát ír. (Amíg az egyikre költöztettem át a rendszert a régiről, a másik nem volt benne a gépben.) Az előbbi lemez rendszeresen alszik, az utóbbi viszont folyamatosan üzemel.
A Load Cycle értékek: a 7911 óráson 245, a 7920-ason 40.
A második lemez 40-es load cycle értékére az a magyarázat, hogy itt is többször van olyan áramszünet, amit a gép előtt levő UPS nem tud áthidalni. Főleg a nyáron volt ez gyakori, amikor a főtér és az elkerülő út átépítése miatt fél napokra áram nélkül volt a város nagyobb része.
Szerintem meg az az egyik fő oka, hogy ma a programozók nagyrészt sokkal magasabb-szintű, deklaratív elemeket bevezető nyelvekkel/librarykkel dolgoznak. Ma már a legtöbb procedurális nyelvhez is csináltak pl funkcionális (lambda) eszközkészletet, és kifejezetten "divat" használni őket.
Ennek előnye, hogy sokkal gyorsabban lehet fejleszteni, elég bonyolult dolgokat is könnyen le lehet írni. Sokkal jobban lehet általánosítani és újrafelhasználni is a már megírt funkciókat. Ezenkívül a kód karbantarthatóságán is sokat javítanak. És a cégek számára ez mind szempont. (Persze nem értő kezekben a deklaratív paradigmákkal is lehet orbitálisakat gányolni - tehát nem csodaszer. Konkrét - teljesítménygyilkos - példáért érdemes elolvasni innen bevezető pár mondatot.)
A hátrányát meg nem kell részleteznem. Elég csak annyi, hogy a programozó a legtöbb esetben egyáltalán nem is érzi, hogy az egyes - látszólag ártatlan - műveletek költsége mennyire nagy lehet. Az utólagos optimalizálást pedig nagyon alaposan meggondolják, mert nemcsak befektetett munkát jelent, hanem a kód "szépségét" is károsan befolyásolja, ami a karbantartásnál hatványozottan visszaüt.
Szóval ez egy csúnya tradeoff a fejlesztés és a futás hatékonysága között, ami azért lehetséges egyáltalán, mert a gépek teljesítménye (egy darabig még) növekszik és képes elnyelni a futási hatékonyság romlását.
--- Régóta vágyok én, az androidok mezonkincsére már!
Tegyük hozzá: igények is változtak. Régen örültek annak is, hogy van betű meg szám, aztán jött a kisbetű, nagybetű, mert 7 biten elfért, aztán jött az, hogy de jó lenne, ha minden nyelv használhatná a saját karakterkészletét és a többi és a többi és a többi. Grafika ugyanígy nőtt szépen 24/32 bitig. Régen elég volt az, hogy ott van egy fájl, ma már kell az is, hogy jogosultságokat kezeljünk, naplózzunk hozzáférést, a fájlrendszer legyen védett az összeomlások ellen, deduplikáljon, kezeljen árnyékmásolatokat, lehessen fájlrendszer szinten transzparensen tömöríteni, stb. stb. stb.
Szóval nem csak a kódolás szintjének áttevődésében van itt a különbség, hanem az igényekben is. És persze, minden tegnapra kell.
Amit te írsz, hogy nagyon sok esetben olcsóbb az erősebb hardver, mint az optimalizálásra költött idő, az természetesen igaz.
Harmadrészt, én egyáltalán nem látom annyira vészesnek a helyzetet: mindenki mondja, hogy egy P1-esen is lehetett szöveget szerkeszteni. Igen, emlékszem, kb. több, mint fél percig tartott, mire a Word elindult. Most rányomok a Wordre, hideg indításból 2 mp és fut. Másodikra a fele sem.
Persze, a magasabb-szintű nyelvi konstrukciók bevezetését nyilván a programmal szembeni felhasználói igények növekedése hajtja. Ma már például alap, hogy korlátlan undo van egy editorban, ami sokszor egészen kézenfekvő optimalizálásokat tesz lehetetlenné.
Tehát ami igaz a programnyelvekre, az igaz felhasználói feature-ökre is, néha látszólag apró dolgok járnak óriási költséggel.
--- Régóta vágyok én, az androidok mezonkincsére már!
Szerintem teljesen hibás az összehasonlítás. Érezhetően lassabb a sw a korlátlan undo miatt? Nem hiszem. Régebben gyorsabbnak tűnt a progi? Vagy ugyanolyan sebességű egy gyorsabb gépen? Ja, hogy akkor 640x480-as képeket nyitottunk meg egy rajzoló programban, most meg 5000x3000-eseket...
A korlátlan undo csak egy lehetséges példa volt arra, hogy nem tudsz helyben adatot módosítani, hanem visszamenőleges állapotok tömkelegét kell memóriában tárolni.
Vagy minden command-ot reverzibilisre csinálsz meg (szívás implementálni, sok esetben nem is lehet) akkor elég az aktuális állapot.
Vagy, ha nem megy, akkor sajnos minden műveletnél copy van, amivel durván nő a memóriahasználat.
Vagy megcsinálhatod úgy is, hogy valójában nem tárolod az aktuális állapotot, hanem mindig egy kezdőállapotból kiindulva előrefele lejátszod az összes commandot. Ez meg lassú lesz, cserébe akár a user számára hasznos feature-t lehet belőle fejleszteni (rajzolóprogramnál példa: adjustment layer).
Persze lehet ezeknek mindenféle trükkös kombinációjával optimalizálgatni, akkor meg a fejlesztési munkabefektetés lesz magas.
Lássuk a te példádat:
Egy 640 x 480 x 8bit képet a DeluxePaint kezelt DOS alatt < 640 kB memóriában. A kép mérete 300 kB, vagyis kb a memóriaméret fele.
Egy 5k x 3k x 32bit kép mérete ~59MB. Próbáld meg Gimppel, Photoshoppal, akármivel megnyitni egy 128MB-os gépen. Vagy akár 256MB-ossal, hogy a bonyolultabb oprendszernek is legyen helye alatta.
--- Régóta vágyok én, az androidok mezonkincsére már!
No igen, csak a feature-ök, azzal van a gond.... a deluxepaint-ben talán még undo sem volt,
tudtál pixeleket rajzolni, azt annyi.
Ráadásul deluxepaint dos alatt futott, ahol mondjuk pár 10k volt az egész alaprendszer, most meg egy fullos ablakozós, tcp/ip stackes oprendszer alatt fut, aminek kapásból kell vagy 512 mb ram. A deluxepaint kb. annyit tudott, mint most egy mspaint.
Volt undo, de csak egy lépésre visszamenőleg.
És dpaint saját ablakozó GUI-val rendelkezett, saját widget libraryt használt (kb win 3.1 szintjét tudta), valamint benne volt a driver kb 20-30 korabeli grafkártyához.
Továbbá az MS paint ma szeretne csak töredék annyit tudni, mint a dpaint tudott 1992-ben. Az EA eredetileg a játékfejlesztőinek belső használatra csinálta, ezt adták ki később termékként - szóval elég komoly professzionális felhasználóbázisa lehetett. Az egyetlen baj vele, hogy a későbbi verziók már csak Amigára jöttek ki.
Szóval nem mondanám feature-szegénynek, de valóban, nem tipikusan fotók feldolgozására volt kihegyezve. Viszont a benne levő feature-ök ügyesen voltak megválogatva, hogy a felhasználó számára hasznos is legyen, de a meglevő erőforrásokba éppen bele is férjen. Mára szerintem alapvetően ez a szemlélet szűnt meg, most ha valami feature kell, akkor kerül amibe kerül, a vas majd valahogy úgyis elbírja.
--- Régóta vágyok én, az androidok mezonkincsére már!
"Igen, emlékszem, kb. több, mint fél percig tartott, mire a Word elindult. Most rányomok a Wordre, hideg indításból 2 mp és fut"
Ez az office-futás nem rossz skála. Pár évvel ezelőttig azt hittem, a hw-sw versenye eldőlt, és irodai alkalmazás soha többé nem lesz képes érdemben várakoztatni a felhasználót. Aztán jött a Lotus Symphony, és mintha két generáció kimaradt volna a hw evolúciójából.
Sajnos egy bizonyos szintű optimalizáció felett fel kell áldozni a kód szépségét. Ez a későbbi fejlesztéseket eléggé megnehezíti és ilyenkor jön a jól ismert kérdés, hogy legyen egy komolyabb refactor a szép megoldás érdekében vagy gányoljunk, hogy ez a feature még működjön valahogy... Idő hiányában többnyire az utóbbi nyer.
Azért szerintem ekkora szakadék nincs a hatékony meg a szép kód között (jó, ez most baromi nagy általánosítás volt), az esetek túlnyomó részében 1-1 rejtett hiba fogja le a sebességet.
Ha egy adott rész lassú, azt ki kell mérni (profiling) és meg kell optimalizálni. Az esetek 99%-ban algoritmus optimalizálással, vagy algoritmus váltással meg lehet oldani, vagy valamilyen módon el lehet rejteni a felhasználó elől.
Az általad említett példa is ezt mutatja, leírják, hogy mielőtt agyatlanul deklaratív akarsz leírni valamit, nézd meg, hogy imperatív módon lehet-e szépen, ha igen, akkor ott állj meg (először néztem is hogy a sz@rt akar, aztán megláttam az imperatív kódot, és röhögőgörcsöt kaptam. Kiváló példája annak, amiről azt gondoljuk, hogy hű, ez jó lesz, aztán idővel kiderül, hogy mégsem). Alapvetően nem rajongok a deklaratív jellegű programozásért, különösen nem java-ban, annyival nem lesz szebb a kód, mint amennyi problémát behozhat.
... a sok hülye feature, csak azért, hogy idióták is tudják "használni" a számítógépet, hadd lehessen őket is HD flash reklámokkal bombázni, hogy minél több potenciális vásárló-robot legyen. ... meg a korlátos neten minél hamarább lepörögjön a kiszabott korlát, hogy aztán netezhessek 10x, 20x annyiért, aminek a 80%-a meginn csak flash reklám.
Érdemes megnézni pl. egy facebook html forrást, aztán csodálkozni, hogy miért van több 100kbyte html/css/js rizsa <-- --> között.
A pörgő processzor ugyebár jobban pörgeti a villanyórát is, úgyhogy akár a kőolajmaffiára is visszavezethető a dolog.
Erre magyarázat csak a kapitalista üzletközpontúság lehet, mert ha egy programot/rendszert ténylegesen fejlesztenek, nem pedig üzleti irányvonalakhoz terveznek, akkor a régi funkcióknak ugyanazon a vason ugyanazzal a sebességgel kéne futniuk, vagy esetleg gyorsulniuk.
-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba
Persze, nyilván az igények egyre nagyobbak lesznek, a programozó fizetése pedig több, mint a gépek bővítésének költsége. Nem tartom ezt nagy problémának egyébként -- változik a világ.
Egyrészt az Intel meg az AMD sorban f0sta ki az egyre inkább felskálázott (órajel) single core procijaikat, ezzel szinkronban mindig egyre több RAM állt rendelkezésre (ez tartott kb. a 386 -tól majdnem mostanáig). Ez a dolog levette a programozó válláról a hatékony és skálázható kód írásának terhét: nem baj ha közepesen szarul teljesít a kód, mert a holnapután kapható procin kitűnően fog üzemelni.
Másrészt ezzel összhangban a mai programozó nemzedék nem igazán törődik a hatékony kóddal, megírja, leunitteszteli, működik aztán jónapot.
Szerencsére ennek kezd vége lenni, mert 2-3 ghz környékén elkezdenek a fizika törvényei beleugatni a dologba, és nincs más megoldás mint a 2,4,.. magos SMP procik kiadása. Ennek a megfelelő kiaknázáshoz viszont meg kell tanulni programozni, ismét. Aki pedig nem teszi, az előbb-utóbb végzetesen lemarad.
Vagy majd lesz egy rohadt vastag szoftver réteg, ahol egy queue-be etetik a parancsokat leosztani a magok közt - és ott majd az lesz lassú. Majd akkor jöhet a 128 mag. Aztán majd a shared memória lesz a szűk keresztmetszet (addigra már az SSD-k régen azok). ...és mégsem kell majd annyira éretni hozzá.
Ez persze csak az egymás után következő utasítások közül azokat hajtja végre párhuzamosan, amiknek nincs semmi közük egymáshoz (gondolom), tehát sokat nem segít.
... viszont nem minden programnál/rendszernél nőttek a gépigények. Nemrég fordítottam le egy új kernelt, meg alap linux programokat, (glibc, coreutils, util-linux, bash, sed, grep, findutils, gcc, m4, make, autogen) és meglepődve tapasztaltam, hogy ugyanazon a vason, ugyanazon optimizációkkal jobban teljesítenek. (linux-2.6.35 -> linux-3.10.9, glibc-2.11.2 -> glibc-2.18.0)
Meglepődtem pl, hogy a sed 1:32 alatt lefordult, ami korábban kb. 3 perc körül mozgott.
Úghogy, a programozók nem minden esetben "trehányak" ...
-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba
Van olyan, ahol nem látszik ez a tendencia.
Pl. AIX alatt gyakran feleakkorák a programok. Egyszerű unix alatt futó dolgokhoz gyakorlatilag mindent belepakoltak a libc-be. Több mint 20 éve precíz dependenciák (ha el nem cseszik). Pontosan szabályozhatod mit akarsz felrakni.
A mese: Mindenkinek az a baja, hogy feleslegesen túl gyors programokat írok. Az az alapelvem, hogy diszkről olvasva 1uS késlekedés egy egész fordulat lekésését jelenti. Átadtam egy rendszer, amely úgy 1000x kisebb terhelés mellett oldotta meg ugyanazt a feladatot, amit a kiváltott rendszernek kellett volna. A megrendelő mint a hülye, nem is értette mit mondok. (Mutogatok grafikonon.)
Ez az ember nem volt ennyire buta, csak
- nem tudta mennyi a feladat
- mennyi erőforrás kell hozzá
- a fentiek szerint mennyi idő kell
- és mindez nem is érdekelte
Vajon 386-oson miért volt probléma az 1x sebességű CD írása, amikor minden sallangot figyelembevéve akár 100x nagyobb buszsebesség is rendelkezésre állt?
A hd video sem bonyolultabb logikai kérdés ennél.
Nem, nem aludtam el.
Azaz: Ha a programozó
- nem tudja mennyi a feladat,
- mennyi erőforrás kell hozzá,
- a fentiek szerint mennyi idő kell,
- és mindez nem is érdekli,
igen lassú programokat tud írni.
Tapasztalatom szerint az elvileg rosszul működő program alá hiába raksz alá nagyobb vasat, nem lehetséges gyorsítani.
Kedvencem a jdownloader. A hozzá képest 10x lassabb router ki tudja rakni a grafikont a letöltési sebességgel.
"A Winamp jó, alig terheli a cpu-t mp3 lejátszáskor." Az mp3 tömörített formátum. Kitömörítés nem terheli a cpu-t, csak a rosszul megírt program.
Hdvideo -> ha le tud jönni a diszkről, a renderelést a gpu végzi, vajon mitől lassú az egész, ha a kritikus helyeken elegendő a sávszélesség?
Ezek a költői kérdéseim.
Ilyen dolgokon nem segít az absztrakció. Az ilyen megoldások csak a teljesítményt zabálják, a feladat ismerete nélkül. A programozók sok esetben nem értik a feladatot, ezért hibás megoldásokat választanak. Megkaptam már én is: Miért nem nézel körül? Használjál modernebb eszközöket! Amit választottam egy igen nagy guru elé került elbírálásra: Megmondta, ez az eszköz zseniális a feladatra. (Nem én!) Csak aki kifogásolta a döntésemet nem tudja a mai napig miért volt jó a választásom. (Nem zsákbamacska: Oracle vs. BerkeleyDB)
"Hdvideo -> ha le tud jönni a diszkről, a renderelést a gpu végzi, vajon mitől lassú az egész, ha a kritikus helyeken elegendő a sávszélesség?
Ezek a költői kérdéseim."
az igen és ez tényleg igaz :D
Egyébként az mp3 rendszerkövetelménye tudtad mennyi?
Pentium90mhz...
De ennél mehetünk lejjebb is, 8bites PIC-en is láttam már mp3 lejátszó alkalmazást, szóval.
Sajnos csak "pci" kártya fogadására alkalmas slot van a régi pentium3-asomban, akkor itt lehetne-e valamilyen gpu-t belerakni, hogy fusson az a hdvideo?
Tudom elvetemült, én már meg nem csinálom, de érdekel.
Nem, mert nem találsz olyan GPU-t, ami programozható shadermagokkal rendelkezik, es felhasználható GPGPU-ra, ami alapvető szükséglete ahhoz, hogy a GPU-n dekodold a filmet. Ld. CoreAVC codec, ami jobbra volt megírva az akkor használt Open source ffmpeg helyett, de GPU-t csak akkor használt, ha nVidia kártyád volt, CUDA támogatással.
P3-min HD felejtős.
Egyebkent az ARM bizbaszok is csak celharsverrel képesek lejátszani a HD-t.
:) Látom, kötözködni nem csak én szeretek. :)
A PCI kártyákban is van GPU, de valószínűleg nem elég gyors. Sőt a régi kártyákba a kép sem fér bele, meg felbontása sincsen.
MP3 -> rendszerkövetelmény (azmiaz?) -> Pentium 90MHz <- Az meg egy CPU, és nem rendszer.
Mivel az MP3 sem szoftver, hanem formátum. A Winamp az szoftver. A formátumot meg dekódoljuk.
A dekódoláshoz meg CPU sem kell. Tudtad?
A PIC annak ellenére, hogy 8 bites, elég nagyágyú. Az MP3 44,1kHz sztereo és 16b esetén olyan 0,23MB/s adatsebességet jelent. Egy nekem tetsző szerver memóriasebessége >100GB/s. Ez félmilliószoros különbség. Ha létezik olyan MP3 játszó szoftver, ami a középmezőnybe tartozó gépek bármilyen terhelést okoz, az biztosan nem a gép hibája. Márpedig van ilyen, és egy MP3 játszó elég aprócska egy videojátszóhoz képest.
Talán arra céloztál, hogy nem is ez volt a kérdés? Pedig pontosan erről az arányról van szó. Ha a hardver a Moore-törvény szerint gyorsul, akkor a szoftverfejlesztés silánysága is, csak kicsit nagyobb kitevővel. Ugye, a kamatos kamat...
Minden fiatal programozóval előfordul, hogy megírja élete nagy rendszerét. Szintén tapasztalat, hogy az első továbbfejlesztésnél kb. 70% kihullik a kódból, miközben újabb funkciókkal gazdagodik. Ez a "jó" eset. A valóságban általában nincs idő a takarításra, így a felesleg bennmarad. És csak látszólag nem zavar senkit.
:)
Nézz utána, hogy az Apollo 11 holdraszálló moduljában milyen CPU volt. Tanulságos. Két speciális nyelven programozható 8 feladatos realtime gép! Összesen 4800db NOR kaput tartalmazott.
NOR -> Y=!(a|b)
Programozott feladatot el lehet végezni céláramkörrel, kis- és nagynomású pneumatikával, hidraulikával. Áramkörileg sequencer-rel. Olyan is van, amit analóg
Még annó volt egy pneumatika vizsgamodulom, ott tanultunk pneumatikus vezérléseket, semmi elektronika nem volt benne a kompresszor motoron kívül.
Ugyanaz az "analógiája" mint a ttl/cmos digitális elektronikának.
Hidralika meg ugyanaz logikailag mint a pneumatika, csak ott az olajat vissza kell csatolni, nem úgy mint a levegőnél ahol gyakorlatilag kimegy az atmoszférába.
Analóg logika is létezik igen :)
PLC egyébként részben ezeknek a borzadályos szuszogós cuccoknak a virtualizálására lett kitalálva. Most tekintsünk el attól, hogy akár szegmenses kijelzőt is lehet plc-vel vezérelni.
Egyik tanárom csinálta ezt, elég jó fejtörő feladat.
Apollo 11 CPU-jára kíváncsi vagyok nagyon.
NOR -> Y=!(a|b) no comment :D programozóknak részletezted ennyire? :D
A szoftver kb. hol kezdődik:
Néhány hétszegmenses kijelzőt hajtottam sorosan 74ls259 kimeneteken keresztül. Kötőgép vezérlés, fonalak, elektrosztatikus zavarok. A kijelzőn néha megjelent a 888888. ?? A hiba oka, hogy a Texas gyármányú bufferelt, a Fairchild meg nem, vagy forditva, és a hosszú kábelen bejövő zavaroktól a kimenő D flip-flop elbillen. De ez mindegy, mert be volt forrasztva, drótozva. A megoldás firmware csere, ahol az 1ms realtime vezérlés még azt is megkapta, hogy dinamikusan frissítse a kijelzőt - így eltűntek a nyolcasok.
Tudom még ajánlani a Signetics 8X300 CPU-t, ami 8 utasításos risc like. Rakétairányításra készítették. "...could fetch, decode and execute an instruction in only 250 ns. Data could be input from one device, modified, and output to another device during one instruction cycle..."
Ez egy 1978-as technológia. Ha jól megnézzük, a mai processzorok utasításkészlete elbújhat mellette. Akkor még nem volt cél a "magasszintű nyelvek támogatása" == jobbára az volt a kódban amit meg kellett valósítani, sallangok nélkül.
Ezekből is látszik, hogy mindazt az elméleti tudást, amit a mai fejlett módszerek képviselnek meg lehetne valósítani sokkal gyengébb eszközökkel is.
Ahogy a mosógép, a kávéfőző, a csirke, a paradicsom meg a kenyér, a szoftver is értékelemzett és futószalagos lett. Ahol bioszoftver kell, ott megfizetik a bioprogramozó biomódszereit, ahol meg nem, ott bíznak abban, hogy a 4-5-6...GL több hasznos anyagot tesz bele, mint engedélyezett adalékot.
Ha megnézzük, hogy hol tart ma a Windows/Total Commander, és hol a Dos Navigator, jól számít aki a sokGL-be fektet inkább, ha nincsenek speciális igényű kapcsolatai.
Fantasztikusan jó az írásban felhozott analógia, örülök, ha elolvashattam!
A gépigény növekedésének valóban az az egyik fő oka, hogy mára közepes vagy rosszabb a programozók java része. Na nem az eddigi jó programozók romlottak le, vagy születne kevesebb potenciális jó programozónak való ember, hanem ugyan úgy felhígult, mint az informatika úgy általában. Mert ugye ez egy olyan szakma, mint a foci - ehhez mindenki ért...
A sok átlagos ember pedig a saját átlagos módján megoldja az adott feladatot átlagosan, vagy gyengébben - ahogy a linkelt írás is ecseteli. Az a pár nagyon jó képességű, aki valóban programozó, pedig leginkább javítja a hibákat, mert az átlagos nem biztos, hogy rájön, mint rontott el. Vagy elmegy mást csinálni, mert elkeseríti, hogy milyen tudásért kap más mennyi pénzt.
Jó példa a víruskeresők területe (mert az igen gyakran változik és elég látványosan nőnek az új belépők). Megjelenik egy új gyártó egy nagyon jó termékkel ami gyors és hatékony. Sokan megveszik, elégedettek vele. Aztán eltelik egy év, max. kettő, és vagy saját maguk nőnek vélt vagy valós plusz igények kielégítése miatt (hogy a kezdeti robbanásszerűhöz mérhető legyen a további növekedés), vagy felvásárolja őket egy nagyobb szereplő, azért "nőnek meg". Akárhogy is alakul, a következő 2-3 verzió során annyira leromlik a minőség (itt leginkább az azonos funkció mellett megugró gépigény tűnik fel), hogy az első licencek lejártakor váltani kell az akkor épp induló újra gyártóra, mert a "frissített" verzióhoz új gép is kellene, annyira rosszul megírt a kódja - a megfelelő képességet nélkülöző sok új fejlesztő bevonása miatt.
A mesterségesen felpörgetett üzlet miatt a tesztelés is a fizető felhasználókra hárul a fejlesztő helyett, de ez már annyira általánossá vált, hogy senkinek nem jut eszébe pereskedni egy kifizetett, de rossz/nem működő szoftver miatt, mert hát ez mind ilyen. Társadalmilag elfogadottá vált, hogy minden szoftverben rengeteg a hiba, ezzel csak együtt lehet élni, nincs mit tenni ellene...
A programozás igazából nem egy megtanulható szakma. Valakinek vagy rááll az agya (van hozzá érzéke), vagy nem. Hiába tanul meg akármennyi nyelvet és programozás-elméleti ismeretet. Ha az agya nem úgy működik, mint egy programozónak, akkor sohasem fog jó programokat írni, akármilyen kitartó.
Aki azt mondja, hogy a jó programozóvá váláshoz csak kitartás kell, az szerintem téved.
Viszont annyi jó programozó valójában nincs (ilyen gyorsan), amennyire a szoftvercégek növekedni szeretnének a profit-maximalizálás érdekében.
Mi lenne, ha a mai átlag programozó visszakapná az operátortól a nyomtatott programlistát, hogy "542-es hibával zárult a végrehajtás, keresd meg, mi okozhatta"... :-)
+1
A programozásról alkotott véleményed jó, csak egy kicsit kiegészíteném.
Mindig magyarázom a laikusoknak, hogy a programozás csak egy szerszám, olyan mint a lapát. Persze absztrakció is, de hát az írás is a szimbólumok szimbóluma.
Úgy lehetne tanítani, hogy gondold végig mit kellene tenni! Nagyon nehéz idegen nyelven kifejezni magad, ha magyarul sem tudod megfogalmazni a gondolataidat. De ha valaki képes megoldani egy problémát, és van egy kis érzéke a rendszerkörnyezethez, akkor még a gyengébb program is jól működik.
"Mi lenne, ha a mai átlag programozó visszakapná az operátortól a nyomtatott programlistát"
:)
Odra 1024, Algol60. De valójában egy Ti57 zsebszámológépen kezdtem programozni. Tegnap.
Valóban szerszám, de azért nem olyan, mint a lapát. Mivel a lapát egy dologra jó, és nem túl bonyolult megtanulni a használatát arra az egy dologra.
Viszont a programozás nagyon összetett szerszám, használni sem egyszerű emiatt. Pláne szerszámként használni feladatok sikeres megoldására. Pláne a sikeres megoldás alatt jó minőségű kódot is értve.
Ha már szerszám a hasonlat, akkor inkább mesterlövész puska. A puska kezelését, a belevaló lőszerek fajtáit, szét- és összeszerelését, szabályos tárolását, terepen való álcázását, stb. meg lehet tanulni. Sőt, a környezeti változók figyelembe vételét is meg lehet tanulni idővel. Viszont egy találathoz ennél sokkal több kell.
Ha már szerszámos analógia, akkor inkább a szerszámos ládát mondanám, egy eszköznek tekintve az egészet a tartalmával együtt. Ott van, bárki bemehet bármelyik boltba és vehet egyet, de ha nem tudja, hogy mit húzzon ki belőle, akkor bizony kalapáccsal fogja a csavar rögzíteni.
Értékelemzett helyett funkcióelmzettet lehetne mondani.
Amikor tanultam, a modell egy villanykapcsoló volt. A magyar gyártók is átvették a módszert: ideálisan minimális alkatrésszám, de a falra szerelve nem működik. Az anyagválasztás és a mechanikai kivitelezés -1. Ellenpélda: Legrand kapcsolók 1200, 1500, 1900Ft funkció szerint. Ugyanaz Kopp esetében 780Ft, és az összes funkciót tudja, és még szebb és stabilabb is. (Elnézést kérek, az árak nem naprakészek.)
Minden villanyszerlelési boltban NEM KOPP kapcsolót lehet kapni!!
Gondolom, nem erőltetnéd meg magad, ha szoftverekkel és szoftvergyártókkal kellene a fenti példát behelyettesíteni.
Mert egy terméknél nem elég az hogy jó legyen, olcsón kell tudni gyártani, nagy mennyiségbe, és a legfontosabb: el kell tudni adni. Anélkül lehetnek a legokosabb
fejlesztők, a legjobb termékkel, ha a konkurens butább emberekkel egy fele olyan jó terméket fejleszt, de azt el tudja adni, akkor nekik lesz pénze, az okos
fejlesztőknek meg nem.
Na ez jó példa.
A Kopp katalógus kb 20 oldal. Választhatsz szinekből és ennyi. KB megfelel egy fullos alaplapra integrált számítógépnek.
A Legrand alapban 4-6 fajta kapcsolócsaládot tud amiből a hétköznapitól a spec igényekig is el lehet menni. Pl a Galea család már 2000 körül tudott szerelvénydobozba építhető világítás vezérlésre alkalmas mozgásérzékelőt, kulcsos kapcsolót, redőnyvezérlést, többféle analóg és digitális (akár kvarc kijelzős ( ebben az időszakban kb 40000 volt darabja)) termosztátot, komplett fényerőszabályzó rendszert, ma már tud riasztót, hangrendszert, folyadékérzékelést, nővérhívót...
Azt csinálsz belőle amit akarsz. Ez kb megfelel egy célfeladat ismeretében hw optimalizált gépnek...
Szerk.: plusz jelzőlámpák, irányfények, csengő,
kombinált gyengeáramú aljzatok.
És a Kopp-al ellentétben nem szakad meg benne a csavar. Van hozzá telefonos/helyszíni support.
- - - - - - -
"Nagy kár, hogy az informatika abba a korba ért, hogy lehet nyugodtan pazarolni az erőforrásokat." Saxus
Bár kissé félreértetted a funkcióelemzés és a divat/összefonódás jellemzését.
Nem arról szólt, hogy a villanykapcsolón android vagy windows fut-e.
De sajnos rossz Kopp katalógust néztél meg! Valószínűleg egy kapcsolócsalád prospektusát.
Ez a tudásszint kb. olyan, mint text mode linux boot esetén kijelenteni, hogy fujj ezzel nem is lehet internetezni.
Mindkét gyártó termékét szereltem. (No jó szerelgettem.) A Kopp-ban kevesebb csavar van, ugyanakkor csavarmentes kötéssel villanytűzhelyet is visz 20 éve.
Ha a választék érdekel - teljesség igénye nélkül - a Kopp-nak is van távirányítós "lakásvezérlő rendszere". A többtápos szerveremhez is Kopp túlfeszvédő elosztót használok, de ez véletlen.
Ettől a villanykapcsolók áraránya és elérhetősége a legközelbbi boltokban igaz maradt.
És ez a fontos, mert speciel sokkal több egyszerű kapcsolót használok, mint nővérhívót. Elég nekem egy is. :)
Mondtam én, hogy olcsóbb?
FPGA != CPU => Ez igaz.
Az FPGA ebben az esetben egy fejlesztőeszköz, az általa megvalósított logikai áramkör egyszerűsíthető, nagy sorozatban legyártható. A végtermék olcsóbb és kisebb fogyasztású, ára PIC árával összemérhető.
A PIC egy általános felhasználású egycsipes mikrogép. Nem erre való.
Szóval a pendrive méretű MP3 játszóban nincsen sem Core i7, sem PIC.
(Fejlesztőeszköz: Ha írsz egy szoftvert, ugye nem adod minden példányához a Visual Studio-t?)
És az ilyet adják el úgy, mint mp3 lejátszó chip. Te meg PIC-ről beszéltél. Idézet tőled:
"8bites PIC-en is láttam már mp3 lejátszó alkalmazást" tehát továbbra is várom, hogy hol láttál 8 bites pic-en mp3 lejátszó alkalmazást, mert az,
hogy egy külső mp3 lejátszó chip-nek átdobom az adatokat, az nem az.
Oh, ezt benéztem, bocsi. Miért ne lehetne? Gondolom a memória is kicsi, a sebesség
is gyenge, valószínűleg ez az oka. Ha meg csinálunk egy felgyorsított pic-et nagy
memóriával, az már nem pic.
No igen, csak nem mindegy, hogy mennyi idő alatt, mekkora lesz a végtermék, milyen egyszerű gyártani, stb. Úgy látom, hogy te nagyon a villamosmérnök oldaláról fogod meg a szoftverfejlesztést, ami nem baj, csak az esetek nagyon nagy részében nem ez nyerő stratégia. Nekünk nem végtelen időnk van hogy a kódot reszeljük, hanem fix határidőre kell egy adott terméket leszállítani, ami stabilan, elfogadható sebességgel fut adott gépen, ki van tesztelve, esetenként skálázódik is, valamint több másik cég termékéhez
kapcsolódik, majd a kiszállítás után a customer még egy marék feladatot talál ki, hogy ezek nélkül nem akar élni, és tegnapra kéne.
Na, ebben a környezetben kell értelmezni a hatékonyságot. Az Apollo 11 lényegtelen ilyen szempontból, rá lehetett állítani több száz mérnököt, és lényegében végtelen erőforrást az adott feladatra. Ez rohadtul drága. Ugyanúgy, ahogy valószínűleg az analóg számítógép (vajon használ-e még valaki ilyet, történelemkönyvben olvastam róla), de az is iszonyat drága: drága fejleszteni, drága hibajavítani, drága sorozatgyártani)
Úgy gondolom, az Apollo 11 eléggé feszített program volt bármilyen mai projekthez képest. Most kiszámoltam: 2,5 év alatt készült el. És nem csak egy szoftvert kellett írni, hanem eléggé kaotikus viszonyok között dolgozni kismillió jó/rossz visszacstolással. Biztosan jól megfizette a gyerekeket a NASA. A szoftverfejlesztő gárda pedig: "I and my good friend Don Eyles were two of the 'young experts' at the MIT Instrumentation Lab - Draper Lab - who worked on the software for the LEM guidance computer." (Apollo 11 Program Alarms)
Ez két fő.
1988-ban harmadmagammal 3 hónap alatt készítettünk olyan szerkezetet, amiért a cég 450MFt-ot kaszált. 1995-ben 1500MFt-os rendszerrel "voltam kapcsolatban". Megsúgom, nem én voltam a vezérigazgató. :((
Szóval úgy gondolom, nem látod az egyes korszakok közti különbséget.
Manapság a káoszt a tervezés hiánya, küzdelem a módszerekkel és toolokkal okozza, meg az, hogy nics specifikáció. Da van szívás!
Ja, és a villamosmérnök, amikor megtervezi az ármkört, a firmware-t, mindig önszervező. Ennak az az oka, hogy át kell latnia a feladatát, más meg úgy sem látja át. Ezzel szemben a szoftverhez mindenki ért, vagy legalábbis úgy hiszi. A végeredményt meg tapasztalod.
Na, nem ezt írták. Ők a teljes kódolás egy részét csinálták:
"Because the more experienced people at the lab were concentrating on getting the Command Module Computer software right, the two kids were given the responsibility for programming the LM powered-flight routines."
Ez azért nem mindegy.
A tervezés hiánya: ezzel egyetértek. Csakhogy, most sokkal olcsóbban kell előállítani termékeket, sokkal kevesebb fejlesztővel, folyamatosan változó igényekkel, olyan ügyfelekkel, akikkel 30 évvel ezelőtt nem kellett foglalkozni, mert hogy egyszerűen nem léteztek. Az, hogy 20-30-40 évvel ezelőtt hogyan fejlesztettek szoftvert, az nagyon szép és jó, csak sajnos a megváltozott körülmények között a régi módszerek (teljesen specifikált rendszerek kódolása sok fejlesztővel, sok idő alatt) már egyáltalán nem működnek. Én is láttam telefonközpont specifikációt, és láttam, hogy a terméket is milyen brutál jól megcsinálták (futó alkalmazást menet közben lehetett patchelni újraindítás nélkül), és láttam azt is, hogy a termék utódja hogy készült, és milyen lett, de ez lényegtelen, a lényeg az, hogy az adott termékből mennyit lehet eladni, és az mennyi pénzt termel.
Villamosnmérnök önszervezősége: amíg a feladat olyan méretű, hogy 1-2 ember meg tudja csinálni, lehet önszervező módon csinálni. Csak amikor 5-8-10 ember munkája függ egymástól, ott már hiába az önszervezőség, nem fog működni a dolog.
Nem mindent csináltak. Mellékesen több nagygépen is szimuláltak, azokat a gépeket is programozta valaki. Meg két számítógépről beszélük, mert a parancsnolki modulban és a holdkompan is volt egy.
Itt arra a srácra gondoltam, aki pár másodperccel a holdkomp lezuhanása előtt eldöntötte, hogy folytathatják. Eltörött/szakadt az egyik radar, és a hibaüzenet mindig előjött, nem látták mikor kell tankolni. ;) Ő biztosan egyedül, legfeljebb másodmagával írta a leszállóprogramot. Ami biztosan kisebb volt a legkisebb mai programnál, mert nem volt több memória. :))
Mondok konkrét példát: VIDEOTON lézernyomtató fejlesztés. Kb. 15 fejlesztő és 3 beszállító cég. Projektmenedzsment nuku. Ugyanakkor a HPLJ fejlesztésnél (Ha fiatal vagy ezt nem ismered, egy leporellóra nyomtató 45 lap/perc teljesítményű gép) 12 fejlesztő csoport volt.
Gondolom ott volt projektmenedzsment.
Azért - ha már Moore-törvényt emlegetünk - mielőtt szívlapáttal egyengetjük ki a szoftverminőségért felelősöket, tegyük hozzá, hogy a vasak nem csak gyorsabbak, de komplexebbek is lettek, nem utolsósorban azért, mert minden, saját házi szabványt összekalapáló cég eszköze tudni akarja a többi gyártó háziszabványait is. Az implementáció vagy tökéletes, máskor teljesen hibás, megint máskor csak peches esetekben aktivizáló bugot rejt, és van, amikor működik csak sokkal lassabban, mint kéne - a kernelek és moduljaik pedig (mi egyebet tehetnének?) úgy patkolják ezeket, ahogy egyáltalán lehet, ami nem mindig jelenti azt, hogy szépen és jól.
(Évek óta nem fordítottam háznál kernelt, de emlékeim szerint sacc/kb. a fordítási egységek 5%-a volt, ami hw lyukakat tapasztott be.)
De kérem!
Műszaki adatokkal soha nem poénkodok!
Nem csak én mértem, hanem olyan kolléga, aki céges környezetben is 10000 nagyságrendű installációt végzett, és teszteli a különböző a verziókat. (Garantálom nem tökhülye a windowshoz.)
Sőt. A linux (ez itt most nem pontos) 2-3x gyorsabban olvassa az NTFS-t. A find cygwin alól legalább 10x, ha nem lényegesen gyorsabban keres a directory struktúrán. Ezt élesben, 80 rendszeren mérem nap mint nap. A rendszerem méricskéli a válaszidőket, és visszafogja magát, ha túlterhelné a rendszert.
Pedig lassanként az összes 64 bites szerver lesz...
Szóval nem jó szöveg, hogy a hardver egyre bonyolultabb.
En negyed eve uzemeltetek Oracle-t, de az eddigiek alapjan nem nagyon tudok olyat mondani, ami ennel szarabb. Egyszeruen gyalazat, hogy ezzel az otvar gane hulladekkal kepesek penzt keresni. 36 karakternel nem lehet hosszabb az install path? Elerheto szabad hely random atvalt negativ szazalekba, es leall az enterprise manager? Uninstaller kerdes nelkul letorol minden adatbazist? ... WTF?!
:)
Szoptam vele közel tíz éven át, tudom, hogy komoly hülyeségei, rigolyái vannak, de így leszarozni... ehhez mérhetetlen nagyképűség és dilettantizmus szükségeltetik.
Negyed év? Nem lehet, hogy kissé elkapkodtad az ítéletalkotást? Mondjuk 3-4 évvel? Annyi idő alatt leszűrődhetett volna, hogy az adatbáziskezelők frontján - ha lehet - még nagyobb a küzdelem, mint az irodai alkalmazásokén. Az újabbnál újabb fícsöröket a versenytársat megelőző hájp érdekében nem ritkán ismert hibákkal adják ki abban a reményben, hogy a tényleges piaci terjedés idejére meglesz a fix. Nem csak az Oracle, mindegyik. Én a nagy riválisának az oldaláról tudnék említeni olyan bugokat, amelyek vagy azt igazolnák, hogy alapvető teszt maradt ki, vagy azt, hogy megvolt a teszt az eredménnyel, de a marketinges felmutatta a T alakot formázó kezeit.
Emellett pár év alatt az is belátható lett volna, hogy a több platformon is létező rendszerek jellemzően minden platformon olyan kompromisszumokkal léteznek, amelyekkel a többi platform lehetőség szerinti egységes kezelése érdekében tanulnak megy együttélni az alaklmazók.
Aszondom, szánd rá azt a pár évet az ismerkedésre ezen szempontok mentén figyelve az eseményeket.
Szerintem pedig az az ok, hogy "hígul" a szoftverfejlesztői szakma, és egyre kisebb és bizonytalanabb tudású emberek készítik a szoftvereket, amik meg egyre nagyobbak. Néha olyan megoldásokkal találkozom, hogy elgondolkodom rajta, hogy miért is nem mentem inkább halásznak. Igaz, hogy a halászok korán kelnek, büdösek, de nincsenek ilyen problémáik, hogy pl. javíts bugot egy olyan szoftverben, amiben a változókat és az osztályokat nem aszerint nevezték el, amire használják őket, a terminológia nyomokban sem emlékeztet az üzleti terminológiára, és ha bővíteni kellett valamit, akkor nem plusz egy oszlop a megfelelő táblába, hanem plusz 3 tábla összejoinolva orrba szájba ID1, ID2, ID3 oszlop nevekkel, rendszerterv persze sosem volt, a felhasználó meg folyton panaszkodik, hogy lassú a szoftver (tényleg lassú), mert 20 millió soros táblákból joinol össze 5-öt (!), hogy megszerezzen olyan adatokat, amikből 10x annyi van táblánként, mint amennyi a tényleges adat lenne 1 táblában.
Na ezért lassú. Mert a profit az első, programozóból meg jó lesz az egyetemista is, tesztelni meg ugye minek, majd a júzer, QA hallomásból sem, elbírja ez, elbírja.
Mert például nálunk a felsőoktatásban is (Óbudai egyetem) az a fontos, hogy szoftver szigorlatra ismerj 15 féle rendező algoritmust, meg fejből tudd a b-tree kezelő algoritmusokat, de csak olyan megoldást fogadnak el, amit a tanár leadott órán, ha más (pszeudo)kódot írsz a vizsgán, lepontoznak, hiába jó a tied, a tanáré meg szar. B*meg, mi a búbánatnak kell 15 féle rendező algoritmust tudni??? Sokkal fontosabb lenne megtanítani a palántákat GONDOLKODNI, nem bemagoltatni velük a sok használhatatlan nyavaját, illetve egy szoftverfejlesztőnek tudnia kellene rendszerben gondolkodnia, képes legyen a problémát (feladatot) emésztető méretűre felbontani és tisztességesen megoldani. Amíg a modul fan in/fan out minimalizálás csak a szoftvertechnológia vizsga egyik kérdésében merül fel (lexikális tudásként), de soha többet sehol sem említik (a gyakorlati tárgyakon sem), addig nagy baj van.
Nagyon kevés jó fejlesztővel találkozom. Manapság a szoftvergyártás futószalagos tömegtermelés lett, olcsóbb, de persze sokkal szarabb minőségű is.
Assembly-ben is lehet lassú szoftvert írni, csak aki neki mer állni assemblyben megoldani egy komolyabb problémát, az valószínűleg már nem a szakma alján van. Volt szerencsém olyanhoz is, hogy "perl mágusok" kitalálták, hogy majd ők hiperszuper Java fejlesztők lesznek. Nem lettek. Nem azért, mert perl-ben nem tudtak megírni akármilyen text file manipuláló cuccot, vagy ne lettek volna képesek akármilyen algoritmust megírni Java-ban. Még a polimorfizmust is majdnem megtanulták. Hanem azért, mert aki perl scripteken szocializálódik, és el van telve önnön tudásával, a bödös életben nem lesz képes egy nagyságrendekkel bonyolultabb, 3 rétegű alkalmazást hatékonyra, könnyen tesztelhetőre és könnyen módosíthatóra megírni, semennyi pénzért sem.
Bocs a kirohanásért, csak mostanában gyakran futok bele olyanba, hogy mikor már az összeomlás szélén áll a projekt, kell valaki, aki kirángatja őket a szarból, persze akik okozták az egészet, nem ismerik be; ha már leléptek felmarkorva a zsíros pénzt, akkor az ügyfél lesz már rohadt ideges, hogy mivanmár és miért fog még ennyibe kerülni, hiszen egyszer már kifizette; ha meg még ott van még a szarkavaró brigád, akkor a gatyábarázás után meg hirtelen már nem kellünk, és nem hogy "köszönöm szépen, hogy segítettél megmenteni a munkám" hanem "büdösek vagyok, és különben is miattatok van minden" módon kiutál, mert a StyleCop full fasiszta beállítását nem vagyok hajlandó tolerálni, de hát valamibe bele kell kötni, mert a kódomat nem érti a drága.
+1, különösen az OE-s, miért kell 15 féle rendezőalgoritmust tudni. Mert a 15 féle rendezőalgoritmus 15 féle módon 15 különböző jellemzőkkel működik. Az meg külön vicces, mikor a bemagolást emlegeti: nem bemagolni kell, hanem megérteni, ha bemagolást várnának el, nem részleteznék előadáson az egyes algoritmusokat, nem iratnának láncolt listákat, fákat, hanem csak leadnák, hogy ezt magold be. Az még viccesebb, hogy arról magyaráz, hogy hülyülnek a fejlesztők, de nem érti, miért vannak ezek a tárgyak. Gondolom az adatstruktúrákból sem kellett volna semmit sem leadáni, hanem csak használni a .NET/Java/STL/stb. beépített dolgait, nem megérteni előadáson.
A pszeudokódos rész meg... Nos, igazából szerintem ezeket az algoritmusokat, amelyeknek kódja többnyire 8-10 soros, nem nagyon lehet másképp megírni. De sebaj, várok konkrét példákat.
Ettől függetlenül nem állítom, hogy az OE-s képzésen nem lenne mit javítani, mert bőven van. De ez bármelyik egyetem képzésére igaz.
Felreertettel, en nagyjabol egyet ertek azzal, amit mondott. Tudom, hogy az algoritmusok azert vannak, hogy megertsuk oket, de ettol meg ez a legtobb esetben nem sikerul, a szamonkeres pedig szinten nem errol szol, hanem hogy ird le papirra ZH-n, o meg "egy hiba -> egyes" algoritmussal kijavitja :)
En az egyetemen max egy hozzaallast kaptam, de gyakorlati tudast zerot. Ha szuksegem lenne valami algoritmusra, akkor ugyanugy utana kene neznem, az ilyet az ember ugyse jegyzi meg hosszutavon, csak ha kurva sokat hasznalja elesben.
Nos. Nagyon is értem, miért vannak ezek a tárgyak. A leadott anyag minőségével, eloszlásával és számonkérésével nem vagyok megelégedve. Amire gondolok: a bűnbaknak kikiáltott 15 féle rendezőalgoritmussal az a probléma, hogy aki az iskola elvégzése után nem szoftverfejlesztőként akar elhelyezkedni, annak ez teljesen felesleges tudás, akinek pedig programozó/fejlesztő lesz, annak pedig ez a tudás nem hasznos. Nem sok emberrel találkoztam az esti tagozaton, aki az iskolában tanult volna meg programozni / jól programozni.
Amire nem tértél ki, hogy szerintem hiányos a szoftvertárgyakban a rendszerben gondolkodás kihangsúlyozása. A munkám során ennek a hiányát látom mindenhol, és sajnos sok fejlesztő nem képes ilyen szintű gondolkodásra. Az oktatásban szerintem nem kap kellő hangsúlyt, pedig hiába működnek jól önmagukban az egyes függvények/osztályok/modulok, ha a kohézió hiányzik.
A "pszeudokódos" részhez majd küldök példát, csak elő kell bányásznom az archív jegyzeteket.
+1. En is jobban orultem volna, ha nem eroltetik a szoftszigot, hanem pl. archi vagy halozat szigo van....
Mindegy, mar egy par eve megvan, hogy az utolso alkalommal sem sikerult a szoftszig, igy feladtam a sulit.
"A leadott anyag minőségével, eloszlásával és számonkérésével nem vagyok megelégedve. "
Ezzel nem tudok vitatkozni.
"a bűnbaknak kikiáltott 15 féle rendezőalgoritmussal"
Lépjünk egy picit túl a rendezőalgoritmusokon és jussunk el az adatstruktúrákig (ugyanúgy PPT-n volt mindkettő). Sajnos hallottam már olyat is a folyosón valakitől, hogy "minek ezeket a szarokat tudni". Azért szerintem, amikor már valaki a láncolt listákra, hash mapekre, fákra, stb. is ezt mondja, ott már súlyos problémák vannak.
"Nem sok emberrel találkoztam az esti tagozaton, aki az iskolában tanult volna meg programozni / jól programozni."
Tény, de ezt el is mondják, hogy órán nem lehet megtanulni programozni, ott csak el tudják indítani az embert egy adott irányba. És ezzel vissza is térünk oda, hogy a szak neve mérnök informatikus.
"szerintem hiányos a szoftvertárgyakban a rendszerben gondolkodás kihangsúlyozása."
Nem, konkrétan egy szak hiányzik a felsőoktatásból: szoftvermérnök. De ez már sokszor téma volt itt.
Egyébként megkérdeztem egyszer Molnár Andrást, hogy miért a villamosmérnök szakból kiemelt/továbbképzett mérnök informatikus szak van (szoftvereseknek -szerintem- irreálisan sok elektro/villtan anyaggal) illetve a matematikus szakokból továbbképzett programtervező informatikus (ahol meg mindent tudnak elméletben, de ...) és miért nincs kifejezetten szoftvermérnök szak MO-n. Nekem a válasz alapján úgy jött le, hogy pontosan képben vannak azzal, hogy mi a baj most az oktatással, mit kellene hozzá tenni és miért nem lehet megtenni.
Tévedés ne essék, nem arra próbáltam utalni (elnézést, ha ezt sugallja a bejegyzésem), hogy felesleges alapvető algoritmusokkal, struktúrákkal foglalkozni. Ezeknek a megtanulása, megértése alapvetően segít a későbbiekben a megfelelő gondolkodásmód kialakításában, a problémamegoldó készség fejlesztésében. A problémám a a tananyagon belüli súlyozással, illetve a számonkérés módjával van (meg néha a tananyaggal). Nem azért "rinyálok", mert nehezen vettem a szoftveres tárgyakat, hanem mert már jó ideje szoftverfejlesztőként dolgoztam, mikor elkezdtem az iskolát, és az "iparban" eltöltött idő tapasztalata alapján alakult ki a fentebb is említett véleményem.
Molnár András pedig nagyrabecsülendő ember, mind a hozzáállása és a tudása alapján. Bárcsak több hasonló emberrel hozna össze a sors.
Amúgy egyetértek veled, csak úgy tűnik, másképp fogalmaztuk meg a gondolatainkat.
Digitális rendszerek + Digit I + Digit II + Irtech I + Irtech II stb... jobb lett volna ezekből kevesebb, cserébe pl PPT és AAO lehetett volna több/mélyebb - főleg a gyakorlatok.
... lassan hosszabb commentjeim lesznek, mint polinak ... no offence
"csak aki neki mer állni assemblyben megoldani egy komolyabb problémát, az valószínűleg már nem a szakma alján van"
Ez jól esett!
Csúcson vagyok!
De miért is?
Egyebkent a fap-fap faktoran kivul nem veletlen, hogy nem irnak ASM-ben sűrűn kódot: annyi architekturalis es subarchitekturalis nuansz van mar es akkorák a kodok, hogy egy butabb C fordító is átlagosan jobb kódot fordít, mint amit egy atlag kóser a legjobb pillanatában kepes lenne összerakni. Bar, ez manapsag nem feltétlen baj, de az mar igen, hogy egyeseknek viszont fogalmuk sincs róla es ohy meg csak halvany lila dunsztjuk sincs, hogy hogy mukodik a processzor (persze, ehhez kell meg egy kis digittech ismeret is).
Régen az ember gondosan kiválasztotta a platformot. (Ami a fiókban volt:)
Olyan szempontok játszottak, hogy a 12 centtel olcsóbb maszkprogramozott processzorban pontosan 3872B programterület és 96B RAM van. Sűrűn számolni kell egy bazinagy képletet, amire egyrészt nincs idő, másrészt van két 8 bites regisztered az A meg az X. (akkumulátor és index) Egy 16 bites összeadás néhány szubrutin hívásból meg is van ...
A kolléga tervezte a bipoláris videoprocesszort. 16 bit 8MHz órajel. Egy karakter alatt 8 videociklust tudok futtatni ...... 22 bites utasításkészlet kell. 300 db IC, 500 szó program, és két hétig rajzolgatott. A műszerésznő összerakta 2 nap alatt, a 2 elkötés kimérése komótosan 1 nap. Aztán működött. Utána csinálod?
Régen a C kódot asm lista alapján optimalizálták. A pipeline megjelenése után súlyosabb lett a helyzet. A Motorola meg G5(?) platformon, tán 128-ból 96 rename regiszter, olyan fordítót készitett, hogy megháromszorozta a futási sebességet. (Ez olyan nem Intel, hanem Motorola-IBM platform:)
Egy biztos: Ilyen módon megszerzett tudással jobban meg lehet érteni, hogy a 2x akkora kód miért fut 2x annyi ideig! Ezt a szoftveresek túlnyomó többsége nem látja.
Ime egy gyönyörű hardvertámogatott interrupt rutin fénykoromból, elég gyorsan futott:
org 18h
lda ncdcd ;reset decoder
ret
Jó reggelt! Ez itt az asm subnode, amelybe hardverfejlesztői sztorikkal nosztalgiáztam.
Azótai is torz hardveres szemüveggel nézem a viágot, és sajnálkozom az SAP-n, mert nem asm-ben írták. Bár, ha belegondolsz, akár írhatták volna és akkor 10-100x akkora költség mellett (ez már kész) még hatékonyabb és gyorsabb lenne (erre még várni kell). A szupergyors java kódokat meg nem videoprocesszoron GPU-n futtatnák.
Bevallom, igazi szoftvert még nem is írtam, csak adatfeldolgozásokat két nagyságrenddel gyorsabban, mint a "szegény unalmas életű szofveresek". Meg automatikus rendszereket, olyanokat amik egyszerre sok gépen futnak sokkal gyorsabban, mint az elődeim rendszerei. Azoké, akik informatikusok meg szoftveresek.
Hogy ezt mi okozza? Talán az, hogy hadrverfejlesztő voltam, vagy gépészmérnök vagyok, esetleg pontosabban dolgozom? Ki tudja.
De ami biztos: pillants fel a topic címére, aztán töprengjél még egy kicsit.
Jó nagy ökörség lett volna a SAP-ot assemblyben írni. Először is iszonyatosan drága lett volna. Gondolj bele, hogy ha csak 1 millió dollár volt a kifejlesztése (aminek valószínűleg a sokszorosa lehet), akkor ebből csináltunk volna 100 millió dollár költséget. Ha 5 millió dollár, akkor 500 milliót? Hol hozta volna be ezt? Sehol. Gyorsabb lenne? Talán, nem biztos. Drágább lenne? Sokkal-sokkal. Lenne esélye egy 20x drágább SAP-nak a mostanival szembe? Semmi az égadta világon, ki az a hülye, aki elfogadható sebességű szoftver és egy gyors szoftver közül azt választja, aki 20x annyiba kerül? Senki.
Mennyi ideje fejlesztik a SAP-ot? 30 éve!!! A világ negyedik legnagyobb szoftverfejlesztő cége, csak magyarországon 350-en dolgoznak nekik...
Azt gondolom tudod, hogy a SAP az csak egy keretrendszer, és az egyes cégekre testre kell szabni. Milyen iszonyatos költségeket jelentene, amikor assembly programozók garmadáját kellene felvenni egy ilyen fejlesztéshez/testreszabáshoz.
És ha még meg is van a szipi szupi x86 assemblyben megírt kódod, aztán jön, hogy bocsi, de nekünk Solaris van, fut rajta? Ja, nem? Akkor nem vesszük meg. Vagy mostanában történik egy nagy váltás intelről arm architektúrára. Jó esetben csak újra kell fordítani a kódot (ha egy része java-ban van, akkor azt sem). A te megoldásoddal újra kellene kódolni az egészet.
A szupergyors java kód kommentet sem értem, meg a GPU-n futást sem, ez teljesen érthetetlen.
Aztán még egy dolog. Lehet hogy van néhány szuper ügyes assembly programozó. Nagyon szép. Csak amikor nem néz balra, aztán elcsapja a villamos, akkor ott áll a projektvezető/cégtulajdonos, hogy honnan a szarból fogunk egy hasonlóan zseniális és assemblyhez értő embert találni.
Szóval az, hogy valami gyors, az csak egyetlen picike paraméter egy szoftvernek.
A nagy projektekhez. Nekünk van egy régebbi, nem túl nagy projektünk. 3-5 ember dolgozott rajta, most egy gyors metrika (java nyelven írva):
közel 5000 fájl
közel 1.2 millió sor
SLOC-P: 760 ezer
SLOC-L: 500 ezer
Deployment Solarisra: F5, enter. Deployment Linuxra: F5, enter. Deployment Windowsra: F5, enter. Ha arm platform lesz, valószínűleg ott is így fog történni.
Csak összehasonlításként egy linux kernel: 15 millió sor, 37000 fájl.
1.3 milliárd dollárba kerülne a linux kernel 15 millió sora (6.7 millió SLOC) ha piaci alapon fejlesztetnénk. A SAP simán lehet akkora, mint a linux kernel.
Ez nagyjából meg is mutatja, miért nem fog soha senki assemblyben nagy - vagy akár csak közepes méretű kódot írni, piaci alapon.
Az ASM <-> SAP egy irónikus poénkodás. Kb. olyan, mint amikor az ember ilyet mond: "Akorára dagadt a fejem mint egy ház". A ház 8m magas, a fejem meg ennél lényegesen kisebb és 1cm növekedést sem mutat, mégsem fogsz odarohanni egy mérőszalaggal bizonygatva, hogy műszakilag hülyeséget állítok.
A topic pont nem erről szól, de azért meg kell említenem egy tipikus és súlyos szemléletmódbeli tévedést: Nem a piacilag legsikeresebb termék a legjobb!
(Megvan a mondás a sok léggyel, szarral, meg hülyeséggel???)
Hány magos cpu kell egy tabletbe? Hát rózsaszín, mert a nők a szín alapján választanak!
Az első modern gyártósort feltaláló Ford is ebbe bukott bele, mert a nők piros meg zöld autókat szerettek volna.
Az asm-ről. Pontosan azért írtam le a korábbi példákat, hogy a fiatalabbak is megérthessék amit soha nem tapasztaltak: régen milyen szempontok miatt volt szükséges használni. Messzemenően nem arról beszéltem, hogy hülye aki ma nem asm-ben írja a rendszereket. Hanem arról, hogy aki kénytelen volt kihegyezni a programot ÉS meg is tudta tenni, az más környezetben is képes hatékonyabb kódot előállítani.
A programok magas sorszáma sem hatott meg teljesen. Láttam, dolgoztam ilyenben. A saját kódolásom többnyire nyolcada a hasonló kódoknak. Nem nő vagyok, nem kell rózsaszín tablet. Éppen ezért előfordult olyan, amikor 400.000 sor kódot helyettesítettem úgy 20 sorral.
- hamarabb elkészült
- kompatibilisebb volt
- kb. 20.000x gyorsabban futott
- nem kellet hozzá még egy-két gép és szoftver
- abszolút hordozható volt
- pontosan a feladatot oldotta meg, side effect nélkül
Ne általánosítsunk ilyenből, de itt azért két mezőt kellett kitöltenem és továbbítani a hálózaton.
Erre ma a tipikus megoldás Sun alkalmazásszerver és java. Mert az hordozható. Már ha elég izmos valaki. :)))))))))))))))))
A hordozhatóságról. Itt is volt olyan topic, ahol nemtudni miből kikeverték, hogy ellene vagyok a hordozhatóságnak, valamint nem is értem mi az. A rövidség kedvéért: nem és nem.
"A sebesség pici paraméter." Egy projektben szóvá tettem, hogy az adatbázissal nem jól dolgoznak (azért írom így, hogy kerüljem a részleteket). A srác bemutatott egy (windózos) tesztfuttatást, miközben a másik igen nagy (országos hírű, egyetemi tanár - adatbázisok) szakértő elmagyarázta, hogy az a sztoridzs olyan gyorsan működik, amit el sem tudok képzelni. Extrapoláltunk a valódi gépre és rekordszámra, így kijött 14 perc futásidő. A valós futásidő 11 óra lett, az előírás <1 óra volt. Én csak azért pofáztam bele, mert a kiváltandó rendszert 8 évig üzemeltettem, és a 12 tervező között is ott voltam. Kérdés?
Az adatbáziskezelő Oracle volt. A legjobb. :))) (Ezen most ne nyissunk topicot.)
A leglassabb rendszereket éppen ilyenben láttam. Tehát
- Ebből nem következik az adatbáziskezelő jósága vagy rosszsága.
- Nem következik, hogy milyen adatbáziskezelőt kellene alkalmazni.
- De következik, hogy a végeredmény enyhén szólva dilettancián nyugszik.
Ez csak a duma. Én magam gyakorlatlan vagyok az sql terén, de azt látom a jól megkomponált adatbázishoz éppolyan mély szakértelem kell, mint az alacsonyszintű programozáshoz. Nem véletlen, hogy a 20-30 programozó mellé 1-1 napra egy még nálam is öregebb fószert hívtak optimalizálni, mert kezdett megállni a rendszer. Az öreg spiller drága, de 1-1 napra kifizetve a projekt "költséghatékony". Üzletileg rendben van, az eredmény siralmas.
De legalább az sql szabványos, hordozható. Az MSSQL villámgyorsan fut egy AIX szerveren. Ki tudja, tán az F5 enter segít.
"a mérnöknek az a célja hogy gazdaságosan oldja meg a problémát" - Igen, ez a mai szemlélet hibája! Régen a mérnöknek a fő feladata a probléma megoldása volt, méghozzá gazdaságosan. Ha olvasod a híreket, néha-néha a megoldás elmarad. Viszont az gyorsan elkészül. :))))
Le a kalappal a munkásságod előtt, de az, hogy egy komolyabb üzleti szoftvert megírjunk / átírjunk asm -ben, C -ben, teljesen lehetetlen küldetés ebben az évezredben.
Mérnökileg sem indokolt, mert a mérnöknek az a célja hogy gazdaságosan oldja meg a problémát, ha nem gazdaságos akkor nem veszik meg tőle és nézhet más munka felé.
Ha most egy .NET / Java -ban is évekbe telhet egy-egy komplexebb projekt befejezése egy profi csapatnak, szerinted asm -ben / C-ben hány emberévezred kellhet hozzá?
Ez nagyszerű, de ha mar SAP, es társai... Ha villanyvadasz szemlélettel próbálnál meg egy ügyviteli R ndszert fejlszteni, elvesznel. Itt nem az az elsődleges igény, hogy milyen gyorsan fut, hanem az, hogy ha kell valami, Mikorra van meg.
Kell pl egy lekérdezés, összerakni mondjuk 2 perctől 2 óra, de aznapra kell a kimutatás. Ott nem fog érdekelni senkit, hogy az 2 mp-ig vagy 2 percig futott.
A lekérdezés hagyján, de ilyen rendszerekkel ma már a szó legszorosabb értelmében olyan jogszabályokat kell üzletvitelileg betarta(t)ni , amelyek tegnaptól hatályosak. Holnap meg még egyet csavarni a folyamaton, vagy cakkpakk vissza az egész.
Ha látod, nyilvánvalóan rokonságban lehetsz Uri Gellerrel.
Ezek technikatörténeti sztorik több mint 25 évvel ezelőttről.
És igazad van!
Én akkor is, most is en_US kiosztású billentyűzeten tudtam kis- és nagybetűket írni.
No, meg ékezetest is. DOS alatt, Windows alatt, linux alatt, terminálon.
Semmit nem fejlődtem!
Tudom, tudom, mobilról írok....csak nem tudod használni. EZ A FEJ-LŐ-DÉS!!! :))) :(((
sztorizgatas, persze, fent buszken verted a melled hogy mennyire nagy majer vagy a 20 eves technikaddal, amivel lenyomod a php pistikek ganyolt szarjait...
ekezetek meg nagybetut meg tudnek, csak nem nem erdekel, HTH
Persze, terelek. Ez a mai fiatalok másik problémája a szövegértés.
Elmagyarázom: Ott fönn azt írtam, hogy bizonyára látnok vagy, ha pár ősrégi sztoriból kitaláltad ma mit csinálok.
Elárulom, nem a php pistikéket, hanem a java bandikákat döngölöm a földbe.
Amit 25-30 éve megtanultam, azzal a tudással írok 10-20x gyorsabb programokat, amelyek a sebesség mellett 1000x kisebb terhelést okoznak. Ezt azért tudom megtenni, mert más a rendszer- és adatszemléletem, mint egy dzsaván nevelkedett titánnak.
A technika amit használok nem 20, hanem 45 éves. A logika meg az ókorból származik.
Mellékszál, de kíváncsi lennék, hogy a költői túlzásokat kigyomlálva a szövegedből
- valójában mennyit ér a régi, talán kissé elavult tudás
- mennyire vagy te magad hatékony
- lesz-e élő ember, aki szükség esetén bele tud nyúlni helyetted a kódodba
"lesz-e élő ember, aki szükség esetén bele tud nyúlni helyetted a kódodba
Es nem csak helyette, mellette. Mai skalazodo vilagban azt felejti el mindenki, hogy nemcsak a szoftvernek kell tudnia a vasra felskalazodnia, hanem a fejlesztocsapatra/cegre is, valamint költségekre.
Az a fejlesztő, aki meg a fejlesztés költségein es a karbantarthatosagot ignorálja, es csak a futási idot nézi, az nem feltétlen jo csapatjatekos es alkalmazott. Es egyebkent is, nem csak sebességre, de memoriahasznalatra is lehet optimalizálni. Van, hogy az a cel. (Es sokszor a ketto egymast uti). De a lényeg: azert nem fogok órákat, esetenként napokat elpocsolni mondjuk egy servicevel, hogy 10 helyett 5 mp alatt induljon, ha nem éri meg es az adja meg az erteket a szoftvernek, hogy X featuret tudja vagy sem. De erre jo pelda a webshop, amit fejlesztünk, uzemeltetnk. Kiszamoltuk, egyszeruen nem éri meg azon gorcsolnunk, hogy most mennyire hajtja meg a gepet, mert abból penz nem lesz, abbol viszont igen, hogy jobbak vagyunk-e, mint a konkurencia. Persze, neha ra kell szanni az időt es itt-ott visszanyesni es szándékosan szar kódot se írunk, de az idő eddig minket igazolt: elobb lett csereerett a gep, mintsem, hogy csúnyán belementunk volna a tartalékokba.
Az emberi részéhez meg egy -bar nem fejlesztokkel, de attol meg jo- pelda házon belülről: cegcsoportocskank bővült egy taggal, ugyanaz a rendszer, metodika lett bevezetve ott is, mint a masik ketto között. Maga a rendszer alapvetoen mukodik, sokat tud, persze vannak hibák, megoldandó új problemakorok es folyamatosan fejlesztünk. Jelenleg viszont az egyik legnagyobb akadályozó tényezőnek az tunik, hogy túl sokat tud a rendszer es nagyon nehezen tanulnak bele az új kollégák. Pedig ez nem egy sokezres multi.
Persze, hogy igazad van. Szerencsémre olyan rendszereken dolgoztam, ahol nagy adattömeget kellett gyorsan feldolgozni. A gép adott volt, és éppen az egyik marha aláírt egy olyan szerződést, amihez 1 órán belül kellett volna futtatnunk. Éppen az előző nap készültem el azzal, hogy 26 óráról 6 órára vittem le a futásidőt. A cél csak annyi, hogy 24 órás perióduson belül üzemeltetni lehessen a rendszert. (Az elsőt NEM én készitettem:) A szerződés ott volt, vehetett volna a cég 60..90 ezer dollárba kerülő bővítést, amihez kellet volna írnom még egy működésképtelen másik programot. Erre nekiálltam és megoldottam ugyanazt kevesebb munkával 10 perc futásidővel.
Abban a szituációban ez volt a nyerő.
Ugyanezt a megoldást a török IBM is sikerrel tesztelte 2,5x akkora adatbázison. Csak ezek a törökök alkudni szeretnek, de vásárolni nem. :(
Jó, ilyen nálunk is van, csak nálunk általában úgy néz ki, hogy "oké, ez volt a terv, de ez kellene". Volt ilyen nálunk is, hogy volt egy éjjel futó PHP-s, SQL-es job, amire végül egy picit több adatot bíztak, mint amennyi az eredetileg tervezett volt, így az éjjel 4-kor induló job nem futott le reggel 8-ig. (Vége az lett, hogy átírtam C++-ra, így utána lefutott kb. 10 perc alatt. Mostanra ez kb. fél-háromnegyed óra.
De akkor az első esetben az egyszerűbb megoldás volt a nyertes. A C++-os megoldás már support időszakban született, 3 hét fejlesztési idő mellett. A másik volt kb. 4 nap. Lefordítva: kb. 2-2,5 héttel hamarább lehetett termelésbe állítani a rendszert.
Ha kíváncs vagy, szívesen megválaszolom.
Csak a költői túlzást nem értem.
Tréfás vagyok, bár a hülye humoromat sokan nem értik. De.
Ebben a topicban már írtam, műszaki adatokkal soha nem tréfálok. Hajlott korom miatt talán pontatlanul idézek dolgokat, de a jellege azért megmarad. :)
Tehát, ha azt írtam, hogy 1000x kevesebb a terhelés, akkor az nem olybá tűnt, hanem megmértem.
Pont.
Elavult tudás.
Nemrég kaptam meg: Ma az ilyen tudás eladhatatlan, ami eladható az a felületes tudás!
Az elavultat kiegészíteném az alapossal.
A fenti vélemény, - és nem tagadom, látom az igazát - pont olyantól hangzott el, aki mindenhez ért, de semmit nem tud.
Régi tudás.
Nemrég készítettem egy olyan rendszert, amelyik 80 windowsos komplex ügyviteli rendszer naplóit és adatbázis metéseit/tr logjait menti egy központi gépre. A fejlesztők 5-10 percen belül innen nézegethetik tetszőleges rendszer naplóit (tetszőleges szakaszt), tölthetik le a mentéseket.
A rendszer végesállapotú gép elven működik, teljesen automatikusan. Takarítja a beállított paraméterek alapján saját magát és a klienseit is. (Azaz a windows szervereket.)
Jelenleg 17.300.000 mentést kezel, tömörítve >2TB. Az adatlekérés azonnali. Egy vékony keresztmetszete van: az sql szerver, amibe egy-egy mentésről egy sort írok be.(Az ugye azért van, hogy php-ben jobban le tudd kérdezni, én a saját indexeimet használom.) Felügyelet nélkül működik, ha elmegy a villany utána crash opcióval kell újraindítani. Adatvesztés nincs.
Hasonló rendszereket írtam az elmúlt 20 évben, összesen kb. 17 példányt, a leghosszabb élettartamú 19 évig működöt. Persze, néha továbbfejlesztve. :)
A fenti rendszer hasonló technológiával készült, mint az a CDROM vezérlő, amit 1988-ban készítettem.
Hatékonyság.
Lassan, pontosan dolgozom. A fenti rendszer 7 hónap alatt készült el. Bár ebben közrejátszott, hogy a megrendelő nem teljesítette a saját részét, így a specifikálatlan formátumokat és folyamatokat is nekem kellett kitalálni. Egyik részlet: Kaptam egy 600kB méretű xml-t - ügyes gyerek vagy, kitalálod! Ebből készült egy 13 rövid sort tartalmazó tábla. :)
Másfél év alatt másfél bugot fogtam, azt is azért, mert valami marha beleírt az apache logjába.
Rendelkezésreállás.
De nem is ez volt a kérdés. "lesz-e élő ember..." No, ez jó kérdés! Valaki egyszer azt modta, tanult mindenféle szervezési, tervezési stb. módszert, de ha nem találod meg azt az embert, aki meg is tudja csináni akkor b.od.
Itt több részre szakadhat a téma.
- Sok esetben kellett szerződésekből, kormányrendeletekből dolgozni. Szinte dokumentáció sem kellett, hiszen a rendszer pontosan úgy működött, ahogy elvárták. Ha valaki programot sem tud írni, meg azt sem tudja mit kell csinálni - akkor ne nyúljon bele a kódba. Ellenkező esetben meg képes lesz rá. Többször nyúltak bele a rendszerembe - aztán rosszul működött. A folyamatot nem ismervén rosszkor rossz adatot vettek ki.
- Az emlegetett rendszereknek nincs "felhasználói" csak üzemeltetői dokumentációja. Abban szerepel a paraméterezhetőség, meg az is: "A rendszer működése a továbbiakban automatikus."
Négy nagy rendszeremre az utolsó két évben nem volt support hívásom.
- Megesett, hogy egyedül dolgoztam három cég csapatával közösen. A csapatok egy-egy töredékrendszert készítettek, én hármat. Gondolom üzletileg ésszerűbb lett volna, ha helyettem még három céget alkalmaznak. Persze ilyen esetben még én is kellettem volna, hogy konztultáljak ezekkel a csapatokkal. Szóval a megrendelőnek esze ágában sem volt mást alkalmazni.
- Egyszer így dícsértek: Ami nem elég egyszerű, az már neked nem is jó.
Szóval buta vagyok és félénk. A szoftver és a rendszer úgy készül nálam, mint a hardver. Apró részáramköröket készítek, kipróbálom, belövöm. Aztán hirtelen összerakom, esetleg olyan bonyolultsággal, amit a mai jó szakemberek nem mindig tudnak követni. Pedig ők azonnal láttak az egész rendszer és a megoldást is. :) Ne kritizáld, mert ezekben az esetekben a szükséges folyamatok megvalósításához így kellett megoldani a feladatot. Aki másképp tette, annak nem sikerült.
Ami igaz, sajnos ez a tudás manapság nem adható el. :(
"mert 20 millió soros táblákból joinol össze 5-öt (!), hogy megszerezzen olyan adatokat, amikből 10x annyi van táblánként, mint amennyi a tényleges adat lenne 1 táblában."
Az igen ritka eset, hogy a tárolt adatokról hosszú távon az derül ki, hogy túl sok; az se gyakori (de megtörténik), hogy az derül ki, hogy a táblák "túl" vannak normalizálva; az viszont kifejezetten jellemző, hogy a fejlesztő (és a tanára) a tanuláskor apróbetűs résznek (a.m.: ugord át, bammeg, mert a lényegesre is szűk az idő) vette az indexeket, Pascalban/C-ben/mittoménmiben még írnia is kellett ilyesmit, de az adatbáziskezelés tantárgy 500 rekordos vizsgapéldáján végleg bebizonyosodott, hogy felesleges sznobéria az egész - a db admin (vagy az a szerencsétlen, akit arra a posztra kisorsoltak) meg vagy képes analizálni, hogy hol hiányzik index, vagy nem.
Ahol az említett aggályos részek nem állnak fenn, ott mindegy, hogy 20 vagy 20 milliós táblákból kapcsolják össze azt az 5-öt.
Nem tudok egyetérteni. Kifejezetten szerettem annak idején a prog. 1-2 tárgyakat, meg az algelt is. Ugyan nem ma volt, de - kis túlzással - ha hajnali háromkor kitrombitálsz az ágyból, akkor is lekódolom neked C-ben bármelyik ott tanult lista- vagy fakezelő eljárást, rendezést. Igaz engem mindig is érdekeltek az "alacsony szintű" dolgok, ezért aztán a ZH meg a vizsga túlélése helyett a megértésre hajtottam.
A munkámhoz most épp nincs szükségem semmi ilyesmire, de a hobbi szintű Atmegás meg FPGA-s matatás közben nagyon hasznos tud lenni, hogy a tanult algoritmusokhoz hasonló problémák megoldása során van honnan ötleteket merítenem. A fene se tudja, lehet egyszer még olyan melóm lesz, ahol szintén tudok majd velük mit kezdeni.
Talán a szoftverfejlesztőknek sem teljesen felesleges. Nekem is van olyan gányolós ismerősöm, aki úgy használja pl. a Java adatsrutktúrákat, hogy halvány fogalma sincs róla, hogy néz ki a megvalósításuk. Így aztán nem is túl gyakran sikerül kiválasztania az optimálisat.
Nálunk a TVben nemrég lett lecserélve a feliratozó szoftver egy újabbra a digitális+HD átállás miatt. És hát voltak érdekes dolgok.
A régi feliratozó gép egy Core2Duo gép volt benne egy Decklink SDI kártyával ami tudja a HD-t.
A programot megkaptuk próbára aztán jött a döbbenet: Az egér úgy akadozott mintha egy 10+ éves gépen futtatnék egy mai játékot és még egy szerencsétlen szöveget sem tettünk ki 'adásba'. Üresjáratban gyakorlatilag felfalta a fél gépet. A Decklink kártya meg nem akarta kulcsolni a feliratot. Felhívtuk a fejlesztő céget. Mondták, hogy 'oda már i7-es gép kell meg egy Decklink 4k Extreme kártya'.
Megvettük a cuccot, elküldék az új Decklink kártyát is, és jött a pofáraesés: Kék halál!
Megint telefon. válasz: '...de mi kék halált nem tudunk csinálni.' Rá egy héttel már ők hívtak, hogy valóban gondok vannak, mert az Asus lapok nem kompatibilisek azzal, vegyünk MSI-t. Itt már biztosra mentem, megkérdeztem, hogy pontosan milyen alaplapjuk van nekik a referencia gépben és akkor olyat veszek.
Megvettem, kékhalál, telefon: 'válasz: ...hááát, lehet, hogy a kártya lesz a szar mert ezzel a típussal most már nálunk is kékhalál van, de egy eggyel régebbi kártyával jó lesz.' Érdekes, eddig jó volt náluk azzal most meg hirtelen nem? A régebbi SDI kártya pedig már kifutó széria - de nagy nehezen beszerezték.
Betettük. Öröm és boldogság, sikerült kitenni a feliratot! De azért 15-20 percenként még mindig befigyelt a kékhalál. Üresjáratban pedig még mindig ott volt a 10-15% CPU terhelés az új gépen.
Egyébként a régi Decklink SDI kártya vígan megy HD-ban a feliratozónál jóval gyengébb képújságos gépben.
A Régi Darim FS1000 adáslebonyolító is érdekes. .NET keretrendszer kell neki, és a vártnak megfelelően lomha. De legalább az tette a dolgát és nem fagyott. Új Darim FS4000, erősebb gép -> már nem annyira lomha.
Tehát nem tudom, hogy a mostani fejlesztők miket varázsolnak össze, de ez így nagyon nincs rendjén.
A .NET-ről jut eszembe, viszonylag friss tapasztalat. Egy villamosmérnök barátom a szakdolgozatához egy "valós idejű" adatmegjelenítő programot (értsd: statikus késleltetés nem érdekes, de amennyi adat egységnyi idő alatt beesik, az egységnyi idő alatt jelenjen is meg) írt, abban segítettem neki. A .net-re esett a választás, guinak windows forms, mert abban tényleg csak összedobálod a guit a builderrel, aláteszed a logikát és kész vagy (még egyszer mondom, villamosmérnök). Az én segítségem a logikai részben merült ki, vagyis hogy hogyan hozzuk össze a bejövő adatot a guival.
Bevallom őszintén, az első megoldásom bár működött, de nem hozta a követelményt. Ugyanis mivel az adatokat fogadó szálból nem lehet közvetlenül metódust hívni a gui szálon, bevezettünk egy delegate-et, hogy lehessen indirekt módon. Ez persze ahogy kell jó lassú lett.
Aztán végiggondoltam, hogy az adatokat be lehetne pakolni egy szálbiztos collectionbe is, amit a gui szál tud olvasni. Ez a megoldás már hozta a követelményeket, ráadásul a kód rövidebb és érthetőbb is lett.
Nyilván a jó megoldás eszembe juthatott volna elsőre is, csak amikor arra koncentrálsz, hogy tökmindegy hogyan, csak jelenjen meg valami, akkor a ronda megoldás is elfogadhatónak tűnik. Ha pedig nem sikerül elég rosszul, nagy az esély arra, hogy haladsz tovább a feladataiddal, és a kód csak évek múlva kezd el problémákat okozni.
Manapság 1kg búza megtermeléséhez sokkal több energiát használnak mint 200 éve.
Bezzeg a régi parasztok, azok tudtak! Igaz, hogy egy hétig izadtak azzal amit ma egy kombájnosnak pár perc, de akkor még volt tisztelete az emberi munkának, nem ám ez a pazarló automatizmus!
Hozzáértés volt, nem csak a gázpedált nyomták agyatlanul!
És mi fejlődött kérdem én: ugyanolyan búzát eszünk ma is! Az energiát meg öntjük ki a kukába?
"ugyanolyan búzát eszünk ma is!" off, de tudtommal a búzát időközben nemesítették, ezért nagyon nem ugyanolyan, mint 200 éve. Lehet ezekről olvasni a neten "modern wheat gluten" keresőszavakkal.
Sok érdekes felvetés született, nagy részük a legtöbb esetben valóban megállja a helyét, úgy mint nagyobb igények, több feladat, kevesebb fejlesztési idő, több, de kevésbé tehetséges fejlesztők, stb.
Viszont amit nem nagyon láttam megemlítve, de szerintem fontos dolog, az az absztrakciós rétegek számának drasztikus növekedése. Mivel mind a feladatok, mind a programok környezete, amiben futnak egyre komplexebbek, ezért ahhoz, hogy a fejlesztési időt és ráfordítást adott szinten lehessen tartani, szükség van rájuk. De minden réteg plusz overheadet jelent, vagyis elvesző teljesítményt. Pl. egy ilyen manapság istenített absztrakció a web. Mindenki mindent a webre akar kipakolni, és nem is ok nélkül, mert webre fejleszteni olcsó, nagyjából multiplatform, deployment egyszerű, jól skálázható, stb. De ennek megvan az ára, amit a kliensekkel fizettetnek meg, mert a böngésző fogyaszt egyre több erőforrást.
"az absztrakciós rétegek számának drasztikus növekedése. Mivel mind a feladatok, mind a programok környezete, amiben futnak egyre komplexebbek, ezért ahhoz, hogy a fejlesztési időt és ráfordítást adott szinten lehessen tartani, szükség van rájuk."
Szerintem az újabb és újabb absztrakciós rétegekre valójában csak azért van szükségünk, mert az meglévők rosszul vannak megtervezve. Vagy nem elég platformfüggetlen, vagy nincs automatikus szemétgyűjtés, vagy nincsen rendesen befejezve. Erre valaki fogja magát, hogy majd ő megoldja, és rátesz plusz egy réteget. Mivel az oprendszerek nem oldják meg a programok szeparálását tisztességesen, ezért kellenek a virtuális gépek. Másik oldalról, a programok előszeretettel függenek oprendszerszintű beállításoktól, ezért is kellenek a virtuális gépek. C/C++-ban nem lehet (nem egyszerű) platformfüggetlenül fejleszteni, pláne sandboxban telepítés nélkül futtatni, ezért kell a web. A web megvalósítása viszont diverz, ezért kellenek rá a Javascript keretrendszerek.
Amúgy az absztrakciós réteggel nem csak az a baj, hogy önmagában lassít (egy keveset számít, de ez még simán beleférne), hanem az, hogy a programozók nem értik a végén már, hogy valójában mi fut, és ezért nem tudnak optimalizálni. Például a Javát szokták emlegetni, hogy milyen lassú. Meglepően gyors programokat lehet benne írni, ha valaki odafigyel, és érti is, hogy mit csinál. De ettől még a Java fejlesztők jelentős része gány dolgokat csinál, és ez visszaüt magára a nyelvre.
Hozzászólások
A programokat ugy irjak, hogy az atlagos gepeken menjen. Ha az atlag emelkedik, akkor hamarabb abba lehet hagyni az optimizalast. Ceg szemszogebol ha az atlagos gepen megy, akkor penzpocseklas tovabb foglalkozni vele (a programozok kapnak uj feladatot). Szabad szoftver eseten van esely, hogy jobb lesz valami, ha akad valaki, aki hajlando ingyen x orat beleolni, hogy 1-2%-al gyorsabb legyen. Mindig is igy volt es igy is lesz.
Nem hinnem, hogy ebben barmi IT specifikus lenne...
túl sok tényezõs a szoftverfejlesztés és tágabb értelemben maga az értékelõlállítás, hogy ilyen egyértelmũen kijelenthessük, hogy amikor a jövõben változni fognak a paraméterek (emberek hozzáállása, énközpontúság, harácsolási vágy, környezeti tényezõk, nyersanyag, gazdaság, ...), egyik se indukálná az általad vázolt helyzet változását.
~~~~~~~~
Linux 3.2.0-4-486
Debian 7.1
Nekem ugy tunik, hogy mindenhol a cel minoseg teren az az "elfogadhato". Nem a "nagyon jo", es megcsak nem is a "jo". Nem feltetlenul munkasok (jelen temaban a programozok) tehetnek errol, ha a projekt elfogadhato szintre kerul, akkor kezdodik a kovetkezo projekt.
Ezert irtam azt, hogy a szabad szoftver-nek van eselye jobb lenni, ugyanis ha valaki nem penzert, hanem hobbibol dolgozik valamin, akkor tobb idot eltolthet egy kodreszlet optimalizalasan mint amennyit egy cegnek megerne kifizetni. A hangsuly az "esely"-en van, vagy osszejon, vagy nem. Egy ceg ezt szinte soha nem fogja megengedni maganak (kiveve, ha a fonok egy perfekcionista, akinek nem szamit a penz, de a termek tokeletes legyen; na ilyen nem sok setal az utcakon...).
Ez a szabad szoftver hobbiból fasság mikor fog kikopni a köztudatból? Semmi köze a kettőnek egymáshoz.
Másrészt a kódminőséget és a dokumentáltságot legjobban a Q&A és a szigorú policy betartatása adja meg, nem a hobbi.
A cég meg akkor fogja megengedni magának, ha bevétele lesz abból.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Ez a szabad szoftver hobbiból fasság mikor fog kikopni a köztudatból? Semmi köze a kettőnek egymáshoz.
Hobbibol irt szoftver gyakran lesz szabad szoftver. Sokkal kevesebben dolgoznak hobbibol zart szoftveren. (Szerintem)
Azt nem allitottam, hogy szabad szoftveren csak hobbibol dolgoznak.
Másrészt a kódminőséget és a dokumentáltságot legjobban a Q&A és a szigorú policy betartatása adja meg, nem a hobbi.
Nem a kodminosegrol es a dokumentaltsagrol beszeltem, hanem a futasideju hatekonysagrol. Nem feltetlenul van kapcsolat a ketto kozott.
A cég meg akkor fogja megengedni magának, ha bevétele lesz abból.
Mivel egy bizonyos szint folott mar nem hoz extra bevetelt, azon a ponton tul mar nem engedheti meg maganak. Ha valaki nem munkahely miatt csinalja, es nem erdekli a bevetel, mert az hobbi, akkor megcsinalhatja.
Ha csak a webet nézzük, régebben voltak egyszerű szöveges oldalak, néhány képpel. Semmi layout (ha csak a paragraph-ok egymás utániságát nem annak vesszük), semmi style (emlékeztek még a css előtti időkre), minimális szkriptelés (amikor még mindenki azt hitte, hogy a javascript az java) és a legbonyolultabb dolog egy animált gif volt, és az átlag felbontás az 800x600 volt.
Egy kiváló példája az ilyen gyöngyszemeknek:
http://www.dpgraph.com/
Egy mostani weboldal az nagyságrendekkel bonyolultabb, változó layout-ok, style-ing, javascript könyvtárak tömkelege, videók, jó minőségű képek, nagy felbontás (1920x1080).
A régi böngészők nem is ismerték a tabokat, egyszerre csak egy oldalt néztél, nem volt olyan, hogy 200 oldalt betabozva tartasz, mert elfér.
Most mondasz hülyeséget mert opera alatt nekem még több oldallal is ment a csikicsuki(2006-2011).
Ez volt a szép időszak :)
"Remélem, előbb-utóbb téged is utolér valami kellemes betegség..."
Ja, hogy te operát használtál :) Ettől függetlenül sokkal bonyolultabb oldalakat kell lerenderelni, illetve régebben még csak 16-32 mega (vagy 4-8, attól függ mennyire
megyünk vissza) állt rendelkezésre, most az alap az 1-2 giga, tehát bőven van hely, ahova be lehet cache-elni dolgokat a gyorsabb működés érdekében..
Mondjuk már akkor is 60 GB-s hdd-m volt. i815 nek hála, csak 512 MB ramot tudtam használni, pedig a koliból hoztam rendesen tartalékot.
Mondom 3 slot van akkor 3x512 menni fog, de csak 256-osak voltak ezért 3x256-ot akartam bele rakni. Na ebből sem lett semmi.
Ekkor maradtam a 2x256MB-nál.
Jó az a nagy fénykor nekem WinXP alatt volt.
"Remélem, előbb-utóbb téged is utolér valami kellemes betegség..."
2006 környékén nekem 120G-s hdd-m volt, 512M rammal egy olyan lapon amit 4-ig lehetett bővíteni. Az akkori majdnem legjobbnak mondható nvidia kártyám volt 128M-val, meg egy 2,6-os celeron. A procin kívül minden megvan mai napig. A videókártya pedig megsült, de a gép többi része még mai napig jól fut, bár már korántsem abban a szerepben amit megvételkor kapott. A táp is csak a második benne. Kompletten új házba került 2007 környékén, mikor még a moddolt gépekre voltam rákattanva. Kapott világítást, világító aluventit, emiatt meg egy nagy, 450W-os tápot. Azóta a világítás kikerült, és bekerült egy 3Ghz-s P4 CPU, még 2G ram és egy 80G-s hdd, és ő lett az egyik home szerver...
--
openSUSE 12.2 x86_64
Ezt le lehetne fordítani érthetőre?
malmozott az operával?
A másik, hogy 10 éve mondjuk 320x240-es videókat néztünk (ami kipörgette 100%-ra a cpu-t), most meg 1920x1080-ast, közben a háttérben megy a torrent, chat,
stb.
Na na nem pörgette ki a cpu-t az.
volt egy időszak mikor a 480-as videó lazán ment még linux alatt is nekem, és egy idő után már nem.
Akkor jött az, hogy 360-ra visszaléptem.
Lényegében sok minden volt ami belassult. PLD ubuntu 10.04 rendesen kínszenvedés volt már,
9.04 meg hasított.
"Remélem, előbb-utóbb téged is utolér valami kellemes betegség..."
Oké, értelmesebb lenne, ha időszakot mondanánk, amihez képest. Linux alatt többször éreztem (amikor még linuxoztam), hogy egy update után kicsit lassabbb
lett a rendszer, mint előtte, de ez valamilyen hibás/rosszul megírt komponensre vezethető vissza...
Azt hiszem, erről beszélsz:
http://motherfuckingwebsite.com/
:)
Egyszer egy ismerősöm megkért, hogy fabrikáljak neki egy webshopot Paypal-os fizetéssel kell árulni egyetlen egy dolgot. Mondtam neki, hogy nekem nem ez a profilom, nem is szívesen csinálom meg. De a Paypalos fizetés miatt kicsit mégis érdekelt, úgyhogy azt mondtam neki, hogy megcsinálom ingyen, de a grafikai design-nal nem törődök, azt csináltassa meg mással. Úgyhogy összeütöttem a weboldalt plain HTML-ben CSS nélkül. Az lett a vége, hogy az ürge teljesen oda volt, hogy micsoda jóság ez a minimal design, és hogy hogy kell ilyet csinálni, mert ő is szeretné tudni :-).
(y)
~~~~~~~~
Linux 3.2.0-4-486
Debian 7.1
A gyártók érdeke, h rendszeresen dobd ki a gépet, és végy újat. Biznic.
Azt megoldják úgy, hogy a windows rongálja a HDD-t. A többi hw-t meg szándékosan szarra csinálják..
--
openSUSE 12.2 x86_64
+1
"Remélem, előbb-utóbb téged is utolér valami kellemes betegség..."
"Azt megoldják úgy, hogy a windows rongálja a HDD-t."
Dafuq?
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Gondolom még nem használtál két full egyforma gépet egymás mellett Win és Linux rendszerrel.
A Win-esben hamarabb elhullik a diszk. Fingom sincs mi a konkrét oka, mégis. 2 diszket nyírt ki az XP míg ugyanaz a típus (egymás utáni sorszámmal, mert egybe rendeltem egy 10-es pakkot) Linux alatt vígan szolgált. szinte ugyanaz volt a két gép dolga, ugyanannyi időt is mentek (egy-két perc különbség volt a lekapcsolás hossza miatt)
--
openSUSE 12.2 x86_64
Uhum, mert ha két disk elhal ugyanabban a gépben, akkor biztos az OS a hibás!
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Nem de file rendszer már lehet hibás.
Nekem is a laptopban rendesen darálta az ntfs a hdd-t.
mc futtatására képes eszközt munkagépnek nevezzük
...és?
(Egyébként meg mi az, hogy "az ntfs darálta a hdd-t?")
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
gondolom kollega az xp azon remekul marketingelt memoriakezelesi trukkjere celoz, hogy "takarekosan hasznalja" a ramot, azaz a szerinte sose kello lapokat az elott kiszorja a swapfilebe, mielott elfogyna a rendelkezesre allo memoria, aztan gyorsan visszacacheli, mert hatha megis kell. ettol viszont tenyleg elfogy a memoria, es nekiall swappelni.
de az is tokjo feature, hogy egy relative szuz xp ( na jo, office 2k7 azert telepitve ) folyamatosan piszkalja a registryt.
Sosem értettem, minek az a registry-baromság. Még anno Windows-3.11 idején, ha killódott a win, egyszerűen törölni kellett a reg.dat-ot, utána kutya baja se volt egy jó darabig. Persze, akkoriban még nem volt ilyen fejlett ez a feature, csak telepítéskor és programindításkor piszkolgatott bele.
-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba
Windows Internalsban leírják.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
"Sosem értettem, minek az a registry-baromság."
Kb. arra, mint a ./randatorpe/minden/kutya/farka/mindengombraegystatusz.xml fájlok írogatása: aki arra igényt tart, annak kinyalja a hátsóját, aki nem tart, azt bosszantja.
Mint említettem kettő, az utolsó csavarig azonos gépről van szó. Ok. Az első diszk hiba után tápra gyanakodtam, cseréltem is, egy szintén ugyanabból a pakkból származóra, mégis meghót, ergo a win a hibás...
--
openSUSE 12.2 x86_64
Korrektebb lenne inkább azt mondani, hogy akár a windows is lehet az oka.
Egyébként hogy is mértél, 10 000 windows és 10 000 linuxos gép volt a minta? :)
+1, nem értem, hogy kapcsolódik az NTFS a vinyó halálához... simán lehetett rossz szériás
vinyó.
Egymás utáni darabokról beszélek. Ahogy a gyárból kijött dobozolva az 50 hdd, az első 10 hozzám került. Ott vették ki előttem a dobozból. sorszámaik egymást követték, úgy került a (pl.) x1-es a winesbe, x2-es a linuxosba, majd a winnél cserélve lett x3-asra és így tovább... Amúgy mindegyik a wines gép alatt azonos, cache és fejhibával halt ki, linux alól badseccel halt ki. mondjuk durván, mert 500-ból hirtelen (értsd ~1nap leforgása alatt) 300G használhatatlan lett.
--
openSUSE 12.2 x86_64
Mert a gepben nincs alaplap, tap, ami esetleg meg okozhatott volna. CSAK A WINDOWS!!!11111
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Ha az OS agresszív módon nekiáll parkoló zónáztatni a fejet, az idő előtti elhasználódással jár...
root@ubuntu:~# hdparm -B 255 /dev/sda1/dev/sda1:setting Advanced Power Management level to disabledAPM_level = offroot@ubuntu:~#ezt melyik dos konyvben olvastad?
---
Egy jól megállapított probléma félig megoldott probléma.
- Charles Kettering
A Windos gönyfpen.
isbn?
---
Egy jól megállapított probléma félig megoldott probléma.
- Charles Kettering
WD Green Linux gondra gondolsz?
--
http://www.micros~1
Arra is.
De mi a bizonyítéka annak, hogy ugyan ez nincs benne bármelyik GYŐZELEMdows-ban is?
Hiszen zárt a forráskódja, nem tudhatod pontosan mit is csinál.
Amennyi közöd lehet a szoftverfejlesztéshez a kommented alapján, rajtad az sem segítene egy fikarcnyit sem, ha nyílt lenne a forrás.
De, tudthatod. Ráeresztesz egy disassemblert és visszafordítod. Vagy megvizsgálod, mit csinál, vannak bőven debug toolok publikusan.
Egyébként meg, ha nagyon akarod, neten találsz kileakelt kódrészleteket a Windowsból.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Oke, hogy atestel az agymosason, miszerint a master race Linuxot hasznal, mindenki mas pedig segghulye es a Microsoft szolgaja, es ettol felsobbrendunek erzed magad, de ez meg nem jelenti azt, hogy innentol te tudod, mit csinal a geped. Ahogy az mar oly sokszor kiderult, kurva gyakran a (nyilt es zart egyarant) fejleszto sem tudja, hogy mit csinal a kodja, nemhogy egy ilyen mitugrasz, akinek fingja sincs a szoftverfejlesztesrol, es azt hiszi, a forraskod a valasz mindenre, anelkul meg semmi nincs, csak 20 ev sotetseg.
Azt szétszedted? Mert lehet hogy abban is a fej karcolt vidám rajzokat a lemez felületére.
Azonos szériájú lemezeknek jellemzően a legyártó műszak az ellensége, ritkább esetben az egyik alkatrész beszállítója, még ritkább esetben annak a vezérlőnek/alaplapnak a gyártója, amire az diszkeket aggatják.
A gyártó műszak frusztrált dolgozója odaverhet egy egész sorozatot a polchoz, de gyakoribb, hogy (a JIT korunk hőse, de a kamion nem vár) a kiszállítandó mennyiség csak úgy kerekedik ki adott időre, hogy elmaradnak tesztlépések. A ló túloldala, amikor követési hiányosságok miatt éppen túltesztelik a lemezeket, ami átlagos üzemórák ezreit veszi el az életükből.
Nem mérés volt, csak tapasztalat. 2 gép ment egymás mellett. Egyik win, másik linux. Egyszerre voltak bekapcsolva, és leállítva, a munka is közel ugyanaz volt mind2-n, heti 5 nap, 10-12 órában. az eredmény 1 év 3 v. 4 hónap alatt 2 diszk halál az xp-s gépben, utána még 1 évet mentek a gépek ugyanígy, még két diszket megevett az xp-s és a linuxos is elfogyasztott egyet. Samsung hdd-k voltak, amikből amúgy itthon is megy 12 darab, 0-24-ben 1200+ üzemórával egy linuxos gépben (igaz ezek nincsenek mostanság hajtva, csak pörögnek szépen).
--
openSUSE 12.2 x86_64
Nálunk vannak céges gépek, amik egész nap mennek (estére sem szoktuk kikapcsolni őket), XP-vel, 5-6 évig, mindenféle vinyó probléma nélkül. Simán lehet vinyó (vagy esetleg táp, alaplap, akármi) probléma.
Persze hogy lehet. Cseréltem is tápot, mint említettem. De akkor is fura. Igaz az is, hogy a win esetén sokkal többet kerreg a cucc, nyilván azért a fej halál (egyet szétkaptam, konkréten eltört a fej a házon belül, és a lemezbe egy szép vájatot kreált a törött darab, és mindegyik így halt ki. Ezt minek szabad betudni, ha nem az állandó felesleges terhelésnek?
--
openSUSE 12.2 x86_64
Szar gyártástechnika.
A 2 gépet is ki kellett volna cserélned (hiszen ugyan olyanok), hogy ténylegesen bizonyítani(?) tudj valamit. Ha a csere után is a Windows gépben hal meg elöbb a HDD, akkor(!) talán van valamid, amit bizonyítéknak még mindig nem neveznék...
--------
HOWTO: Zentyal+Zarafa+Setup+Outlook+Thunderbird+mobilephone sync
Azt mit kellene bizonyítani? Pont leszarom az egészet, csak megemlítettem egy általam tapasztalt dolgot, csak már jöttek habzó szájjal a MS fanok. Szal leszarom a témát. Lényeg, hogy perpill megint többet ment egy ugyanolyan diszkem, ami win alatt rég kihalt.
--
openSUSE 12.2 x86_64
A HDD tema meghalas szvsz OS fuggetlen
fixme
---
Egy jól megállapított probléma félig megoldott probléma.
- Charles Kettering
jó de ő egymás mellé rakott egy wines gépet és egy linuxos gépet és hát a gonosz win megette a vinyót viszont a linux meg minden oprendszerek istencsászára :DD
ez csak a linuxal van igy, vagy mas opensource rendszerrel is? mert akkor kiprobalnek valami mast, hogy tovabb birjak a lemezeim
erre esetleg nincs valami fuggetlen meres vagy tanulmany? esetleg lehet rendelni valamelyik vendortol linux certified merevlemezt?
---
Egy jól megállapított probléma félig megoldott probléma.
- Charles Kettering
Nekem vannak lemezeim, amelyeken kizárólag linux ült, nagy magabiztossággal. Nem lesz olcsó, de nem hiszem, hogy a biztonságnak ezért a fokáért sajnálnád a piaci ár dupláját.
Némi felárért kigurulok az állatparkba, és kérek kiegészítőnek pár lapát pingvinszart is.
huh, ezt nem gondoltam volna, hogy ilyen hamar tud valaki szerezni. tenyleg jo ez a kozosseg. most igy az unnepek elott akar a 2.5 szereset is hajlando vagyok megfizetni, azonban van egy kis bokkeno: csak egy fel lapattal van itt a sarokban. esetleg lehetne hitelrol szo? igerem, szilvalekvarral fogom a pingvinjeimet etetni, hogy minel hamarabb fizethessem a maradek reszletet
---
Egy jól megállapított probléma félig megoldott probléma.
- Charles Kettering
Félreértettél - nagy üzleteknél előfordul -, a pingvinguanót is én adom. Legalábbis biztos vagyok benne, hogy a nyíregyházi állatparkban felismerik az open source és a closed penguin szimbiózisában rejlő marketinglehetőségeket.
Ez így van :D
mc futtatására képes eszközt munkagépnek nevezzük
Akkor talan a win gepbe a harmadik csere elott a Linuxos gepbol kivett wincsit kellett volna megprobalni.
--
http://www.micros~1
What the actual fuck did I read???
szerk: tényleg a Windows strapálja jobban a HDD-ket?
Először azon mosolyogtam, hogy ez jó poén akart lenni...aztán azon, hogy komolyan gondolja :)
(Mondjuk ezen a google izén is, a load cylcle countnak mi köze van ahhoz, hogy winről vagy linuxról van szó?)
Laptopokat érinti a probléma, Linux alatt. Egy csomó laptop modellen a vinyó kapott egy optimális, energiatakarékos viselkedést. Előfordulhat, hogy a Linux ezt nem veszi figyelembe, vagy nem úgy, ahogy kéne, ezért simán előfordulhat, hogy 1-2 másodpercenként leparkoltatja tök feleslegesen a vinyót. Ez elkezdi pörgetni ugye a load cycle countot is a SMART-ban, ami hosszú távon nem egészséges. Mármint nyilván nem maga a SMART-os érték, hanem amit mutat. :)
szerk: Ami lényeges dolog, de kimaradt. Ez szerintem ott gyakori, ahol a gyártó eleve windowsra optimalizál, bár ez már csak megfigyelés, nem mérés.
Linux nem parkolja a fejet önmagától, általában a default a winyón van úgy beállítva, hogy fél percenként eltegye a fejet. Én is mire észrevettem az új Seagateken, már 10000 fölött járt a Load Cycle Count. De hdparm-mal szerencsére beállítható (legalábbis ezeken, aztán volt a WD, amihez volt gyári szoftver). Szerinted Windowson nem ugyanez történt volna?
Ez a "gyártó Windowsra optimializál" wichester esetén most hogy? Fogalma sincs arról, hogy mit futtatsz a gépen...
El kell, hogy szomorítsalak, Windows alatt nem ez történik. Ha rákattintasz a lmgtfy-s linkemre, találsz pár fórum threadet erről a témáról.
Há' én csak ezt láttam (mellesleg ugyanezt tettem én is a sajátjaimmal):
It's not exaclty a bug, therefore there's no fixing it, rather there is hacking it. Windows machines also suffer from it. Solution for me, at least is running every time when my machine boots, or putting in /etc/rc.local this:
hdparm -B 254 /dev/sda
Valahol bizonyíték arra, hogy a Win kikapcsolja ezt az energiatakarékossági szart? Vagy tudod is, miért nem érinti a Wint, azon kívül, hogy "Windózra optimalizálták a HDD-t"?
Bizonyítékot nem tudok adni, mert nem szeretnék belemenni a reprezentatív / nem reprezentatív című vitába, ami itt elég gyakori.
Viszont két különböző típusú (bár mindkettő Lenovo márkájú) laptopon kipróbálva Ubuntuval, Fedorával és Windows-zal ez utóbbi _lényegesen_ kevesebb load cycle-t produkált. De, mint pár poszttal feljebb írtam, ez megfigyelés, nem mérés.
De nem is akarok erről vitatkozni. Ha neked nincs ilyen gondod, örülj neki, a szál viszont onnan indult, hogy a Windows _direkt_ tönkreteszi a merevlemezeket.
Na ez az, hogy amiről az ember nem tud biztosat, arról inkább ne írja, hogy biztosan így van. Esetleg a Win laptop kevesebbszer ébresztette fel a HDD-t, ezért kevesebbszer is parkolt le újból a fej, de attól még nem viselkedik eltérően a winyó a két rendszeren. Ezt a magyarázatot még el is hinném.
De nem is akarok erről vitatkozni. Ha neked nincs ilyen gondod, örülj neki, a szál viszont onnan indult, hogy a Windows _direkt_ tönkreteszi a merevlemezeket.
Erre írtam, hogy először poénnak gondoltam, aztán kiderült, hogy nem annak lett szánva :) Úgyhogy ehhez meg inkább nem szólok hozzá :)
Szerintem sokkal egyszerubb dologrol van szo: defaultban a Windows 20 perc idle utan lekapcsolja a diszket, ami rendkivul egeszsegtelen. Ez az elsok kozott van, amit le szoktam tiltani.
Nálam windows alatt is, 2 laptopon is. WD meg Hitachi diszk. Mondjuk egyiken már valami 250k körül jár a load cycle count, a másikon van hdparm, az 20k körül jár.
A gép, amit használok, pont linux alatt nem kattog, windows alatt igen. Előző gépemen meg fordítva volt, még régen. Már a legfiatalabb hdd-m is 4 év körüli, max lecserélem, ha megunja a kattogást/nem kattogást.
Azért én csak keresnék valami wines appot a hdparm helyettesítésére :)
Van windowsra is.
Jómagam nem vagyok járatos adattár-üzemeltetésben.
Adataim biztonságát rendszeres (többszintű) backup policyval igyekszem biztosítani.
A diszkekre néha nyomok ugyan egy smartctl-t, de többnyire csak a Reallocated_Sector_Ct, Reallocated_Event_Count és UDMA_CRC_Error_Count értékekre vetek egy pillantást (szeretem őket nullán tudni).
A thread-et olvasva lekérdeztem a Load_Cycle_Count értékét, ami bizony az egyik diszkemen már 1M fölötti (1,209,091).
Kíváncsi vagyok, hogy a témában jártasabb kollégák mit olvasnak ki a smartctl kimenetből.
197 Current_Pending_Sector 0x0012 200 200 000 Old_age Always - 1
Error 2 occurred at disk power-on lifetime: 10598 hours
40 51 08 67 0a 00 e0 Error: UNC 8 sectors at LBA = 0x00000a67 = 2663
40 51 00 4f 0a 00 e0 Error: UNC at LBA = 0x00000a4f = 2639
Kb: 4500 óra üzemidővel ezelőtt valahol a 2639+25(max) szektor környékén nem sikerült olvasni (legalább) egy szektort. Ezt a diszk hibára jegyezte elő, amely a következő írási művelet esetén kihelyettesítődik. Ugyanakkor a hibás szektor bekerül a defect listába -> Reallocated Sector Count +1. Jó esetben.
Ez a hibás szektor - amiről kiderülhet, hogy több - egy ritkán olvasott és nem írt területen található, mivel 4500 óra alatt nem keletkezett újabb hibanapló bejegyzés.
A 193 Load/Unload counter megítélése vegyes. Egyik szemszögből ez a diszk már réget túljutott a garantált élettartamán, amit a Load Cycle Count függvényében specifikálnak. Másrészt ez nem biztosan ungyanaz. Mindenesetre os és diszk részről egyszerre, egymást keresztező pm teljesen felesleges. Erre itt talász magyarázatot.
Ez egy desktop gép, kb 2 naponta bekapcsolod. A diszk 2,5-3,5 éves.
Sherlock :)
Desktop gépben scorpio diszk? :)
Szervert naponta indítasz és az APM 40secenkén lekapcsolja a diszket?
Valaki fillentett!
Nekem már a turbo XT-ben is volt scsi diszk. 350MB, a cégeknél meg 20-40MB. És?
A többi rendben?
Köszönöm a választ.
Valóban, ez egy desktop gép. Az itthoni munkaállomásom.
2008-ban került bele az ominózus diszk, ezen van az oprendszer (Gentoo) és a home könyvtáram.
(Van benne még egy 2TB-os Samsung diszk is az adatoknak.)
Kapcsolgatva viszont nincsen, always-on megy. Csak akkor van megbootolva, ha áramszünet van (kéne már új akksi az UPS-be). Fut rajta pár service (pl. privát FTP), hogy távolról is elérjem az adataimat.
PM igazából ezen a gépen nem érdekel, hadd menjen csak, a lényeg, hogy mindig rendelkezésre álljon és minél tovább éljen.
Van pár ilyen öreg diszkem, amik 7/24 mennek (pl. seed szerverben), némelyiken már a Reallocated_Sector_Count sem nulla.
Szerencsére eddig - látszólag - hiba nélkül teljesítenek.
Az üzemidő 15146 óra, 631 nap, azaz kevesebb mint 1 év 9 hónap, ha folyamatos üzemet feltételezünk.
Az 5 év = 1826 nap. Ehhez képest csak 658x indult el a diszk, és 421x volt ki-be kapcsolva.
Valaki téved. Vagy a diszk..
Ehhez a típushoz product review-t csak 2009 évben találtam.
Vajon az üzemidő számításánál az alvást is figyelembe veszi?
Megmondom őszintén, hogy keresem, de nem találok egyértelmű információt.
Arról van szó, hogy ezek így néznek ki:
Standby Actuator is unloaded and spindle motor is stopped. Commands can be received
immediately
Sleep Actuator is unloaded and spindle motor is stopped. Only soft reset or COMRESET can
change the mode to standby
Nomármost, ha a "spindle motor is stopped", akkor utána induláskor a start/stop count növekszik eggyel. Ez így tisztességes, mert a felpörgetés gyilkolja a csapágyakat, tehát az élettartem miatt illik megszámolni.
Az üzemidő nem is üzemidő, hanem "power on hours count". A fenti két üzemmódban power van, csak eléggé csökkentett az áramfelvétel. Jó kérdés, hogy ez az állapot bekapcsolt-e vagy nem, de egyértelműen van rajta villany. Ha nem így lenne, akkor a power cycle count növekedne.
A számokból úgy néz ki, hogy a felpörgések száma 658, míg a ki-be kapcsolások száma 421. Ha folyamatosan ment a gép 5 évet, és a sleep üzemmód nem számít bele az üzemidőbe, az csak úgy lehetséges, ha a sleep átlagosan minden esetben akár több napig is tartott. Természetesen ez idő alatt működhetett a gép, de semmit nem írt a diszkre és nem olvasott. Ez nem életszerű.
Pótlehetőség: A számláló 2 byte hosszú (inkább 31 bit abszolút érték) és körbefordult. Ekkor a diszk 5 éves és 2 hónapos. Akkor ez egy vendor specific fícsör, mert nekem vannak 40-45000 órás diszkjeim. Ebben az esetben igen gyakran van felétek áramszünet - 5 év alatt kb. 400 esetben.
A magas számú load cycle count egy olyan laptop pm, amikor kihúzza a fejet, hogy mozdításnál ne szántson bele az adatterületbe, de a motor megy tovább. (actuator unloaded) Ezzel csak kopik a rendszer, de spórolni nem lehet.
A SMART Power On Hours sora - legalábbis a Hitachi lemezeken akkor is növekszik, ha amúgy a motor áll. Ezt onnan tudom, hogy idén január vége felé vettem két lemezt, amik azóta 24/7-ben mennek. Ezek közül az egyik 7911, a másik 7920 órát ír. (Amíg az egyikre költöztettem át a rendszert a régiről, a másik nem volt benne a gépben.) Az előbbi lemez rendszeresen alszik, az utóbbi viszont folyamatosan üzemel.
A Load Cycle értékek: a 7911 óráson 245, a 7920-ason 40.
A második lemez 40-es load cycle értékére az a magyarázat, hogy itt is többször van olyan áramszünet, amit a gép előtt levő UPS nem tud áthidalni. Főleg a nyáron volt ez gyakori, amikor a főtér és az elkerülő út átépítése miatt fél napokra áram nélkül volt a város nagyobb része.
Szerintem meg az az egyik fő oka, hogy ma a programozók nagyrészt sokkal magasabb-szintű, deklaratív elemeket bevezető nyelvekkel/librarykkel dolgoznak. Ma már a legtöbb procedurális nyelvhez is csináltak pl funkcionális (lambda) eszközkészletet, és kifejezetten "divat" használni őket.
Ennek előnye, hogy sokkal gyorsabban lehet fejleszteni, elég bonyolult dolgokat is könnyen le lehet írni. Sokkal jobban lehet általánosítani és újrafelhasználni is a már megírt funkciókat. Ezenkívül a kód karbantarthatóságán is sokat javítanak. És a cégek számára ez mind szempont. (Persze nem értő kezekben a deklaratív paradigmákkal is lehet orbitálisakat gányolni - tehát nem csodaszer. Konkrét - teljesítménygyilkos - példáért érdemes elolvasni innen bevezető pár mondatot.)
A hátrányát meg nem kell részleteznem. Elég csak annyi, hogy a programozó a legtöbb esetben egyáltalán nem is érzi, hogy az egyes - látszólag ártatlan - műveletek költsége mennyire nagy lehet. Az utólagos optimalizálást pedig nagyon alaposan meggondolják, mert nemcsak befektetett munkát jelent, hanem a kód "szépségét" is károsan befolyásolja, ami a karbantartásnál hatványozottan visszaüt.
Szóval ez egy csúnya tradeoff a fejlesztés és a futás hatékonysága között, ami azért lehetséges egyáltalán, mert a gépek teljesítménye (egy darabig még) növekszik és képes elnyelni a futási hatékonyság romlását.
---
Régóta vágyok én, az androidok mezonkincsére már!
Tegyük hozzá: igények is változtak. Régen örültek annak is, hogy van betű meg szám, aztán jött a kisbetű, nagybetű, mert 7 biten elfért, aztán jött az, hogy de jó lenne, ha minden nyelv használhatná a saját karakterkészletét és a többi és a többi és a többi. Grafika ugyanígy nőtt szépen 24/32 bitig. Régen elég volt az, hogy ott van egy fájl, ma már kell az is, hogy jogosultságokat kezeljünk, naplózzunk hozzáférést, a fájlrendszer legyen védett az összeomlások ellen, deduplikáljon, kezeljen árnyékmásolatokat, lehessen fájlrendszer szinten transzparensen tömöríteni, stb. stb. stb.
Szóval nem csak a kódolás szintjének áttevődésében van itt a különbség, hanem az igényekben is. És persze, minden tegnapra kell.
Amit te írsz, hogy nagyon sok esetben olcsóbb az erősebb hardver, mint az optimalizálásra költött idő, az természetesen igaz.
Harmadrészt, én egyáltalán nem látom annyira vészesnek a helyzetet: mindenki mondja, hogy egy P1-esen is lehetett szöveget szerkeszteni. Igen, emlékszem, kb. több, mint fél percig tartott, mire a Word elindult. Most rányomok a Wordre, hideg indításból 2 mp és fut. Másodikra a fele sem.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Persze, a magasabb-szintű nyelvi konstrukciók bevezetését nyilván a programmal szembeni felhasználói igények növekedése hajtja. Ma már például alap, hogy korlátlan undo van egy editorban, ami sokszor egészen kézenfekvő optimalizálásokat tesz lehetetlenné.
Tehát ami igaz a programnyelvekre, az igaz felhasználói feature-ökre is, néha látszólag apró dolgok járnak óriási költséggel.
---
Régóta vágyok én, az androidok mezonkincsére már!
Szerintem teljesen hibás az összehasonlítás. Érezhetően lassabb a sw a korlátlan undo miatt? Nem hiszem. Régebben gyorsabbnak tűnt a progi? Vagy ugyanolyan sebességű egy gyorsabb gépen? Ja, hogy akkor 640x480-as képeket nyitottunk meg egy rajzoló programban, most meg 5000x3000-eseket...
A korlátlan undo csak egy lehetséges példa volt arra, hogy nem tudsz helyben adatot módosítani, hanem visszamenőleges állapotok tömkelegét kell memóriában tárolni.
Vagy minden command-ot reverzibilisre csinálsz meg (szívás implementálni, sok esetben nem is lehet) akkor elég az aktuális állapot.
Vagy, ha nem megy, akkor sajnos minden műveletnél copy van, amivel durván nő a memóriahasználat.
Vagy megcsinálhatod úgy is, hogy valójában nem tárolod az aktuális állapotot, hanem mindig egy kezdőállapotból kiindulva előrefele lejátszod az összes commandot. Ez meg lassú lesz, cserébe akár a user számára hasznos feature-t lehet belőle fejleszteni (rajzolóprogramnál példa: adjustment layer).
Persze lehet ezeknek mindenféle trükkös kombinációjával optimalizálgatni, akkor meg a fejlesztési munkabefektetés lesz magas.
Lássuk a te példádat:
Egy 640 x 480 x 8bit képet a DeluxePaint kezelt DOS alatt < 640 kB memóriában. A kép mérete 300 kB, vagyis kb a memóriaméret fele.
Egy 5k x 3k x 32bit kép mérete ~59MB. Próbáld meg Gimppel, Photoshoppal, akármivel megnyitni egy 128MB-os gépen. Vagy akár 256MB-ossal, hogy a bonyolultabb oprendszernek is legyen helye alatta.
---
Régóta vágyok én, az androidok mezonkincsére már!
No igen, csak a feature-ök, azzal van a gond.... a deluxepaint-ben talán még undo sem volt,
tudtál pixeleket rajzolni, azt annyi.
Ráadásul deluxepaint dos alatt futott, ahol mondjuk pár 10k volt az egész alaprendszer, most meg egy fullos ablakozós, tcp/ip stackes oprendszer alatt fut, aminek kapásból kell vagy 512 mb ram. A deluxepaint kb. annyit tudott, mint most egy mspaint.
Volt undo, de csak egy lépésre visszamenőleg.
És dpaint saját ablakozó GUI-val rendelkezett, saját widget libraryt használt (kb win 3.1 szintjét tudta), valamint benne volt a driver kb 20-30 korabeli grafkártyához.
Továbbá az MS paint ma szeretne csak töredék annyit tudni, mint a dpaint tudott 1992-ben. Az EA eredetileg a játékfejlesztőinek belső használatra csinálta, ezt adták ki később termékként - szóval elég komoly professzionális felhasználóbázisa lehetett. Az egyetlen baj vele, hogy a későbbi verziók már csak Amigára jöttek ki.
Szóval nem mondanám feature-szegénynek, de valóban, nem tipikusan fotók feldolgozására volt kihegyezve. Viszont a benne levő feature-ök ügyesen voltak megválogatva, hogy a felhasználó számára hasznos is legyen, de a meglevő erőforrásokba éppen bele is férjen. Mára szerintem alapvetően ez a szemlélet szűnt meg, most ha valami feature kell, akkor kerül amibe kerül, a vas majd valahogy úgyis elbírja.
---
Régóta vágyok én, az androidok mezonkincsére már!
"Mára szerintem alapvetően ez a szemlélet szűnt meg, most ha valami feature kell, akkor kerül amibe kerül, a vas majd valahogy úgyis elbírja."
Még jó, hogy megszünt. Persze jó lenne olyan szoftverrel dolgozni, ami ugyan nem tudja, amit akarok, de azt legalább gyorsan.
Ok, de a kiinduló kérdés az volt, miért nőtt meg a gépigény. Hát például ezért.
---
Régóta vágyok én, az androidok mezonkincsére már!
A nagy gond az, hoyg nem tudja, mit akarsz, de megprobalja kitalalni. Rosszabb esteben nem is probalkozik, hanem ugy dont, hoyg Te ezt akarod.
Igy kerul egy CD iro programba anyamtyukja is.
--
http://www.micros~1
"Igen, emlékszem, kb. több, mint fél percig tartott, mire a Word elindult. Most rányomok a Wordre, hideg indításból 2 mp és fut"
Ez az office-futás nem rossz skála. Pár évvel ezelőttig azt hittem, a hw-sw versenye eldőlt, és irodai alkalmazás soha többé nem lesz képes érdemben várakoztatni a felhasználót. Aztán jött a Lotus Symphony, és mintha két generáció kimaradt volna a hw evolúciójából.
+1
Sajnos egy bizonyos szintű optimalizáció felett fel kell áldozni a kód szépségét. Ez a későbbi fejlesztéseket eléggé megnehezíti és ilyenkor jön a jól ismert kérdés, hogy legyen egy komolyabb refactor a szép megoldás érdekében vagy gányoljunk, hogy ez a feature még működjön valahogy... Idő hiányában többnyire az utóbbi nyer.
Azért szerintem ekkora szakadék nincs a hatékony meg a szép kód között (jó, ez most baromi nagy általánosítás volt), az esetek túlnyomó részében 1-1 rejtett hiba fogja le a sebességet.
--
http://developersideas.blogspot.hu/
http://neurogadget.com/
Kérdés hogy komolyabb méret fölött van-e egyáltalán "szép" megoldás (lehet-e) illetve meddig? A következő nem várt feature request-ig?
Ha egy adott rész lassú, azt ki kell mérni (profiling) és meg kell optimalizálni. Az esetek 99%-ban algoritmus optimalizálással, vagy algoritmus váltással meg lehet oldani, vagy valamilyen módon el lehet rejteni a felhasználó elől.
Az általad említett példa is ezt mutatja, leírják, hogy mielőtt agyatlanul deklaratív akarsz leírni valamit, nézd meg, hogy imperatív módon lehet-e szépen, ha igen, akkor ott állj meg (először néztem is hogy a sz@rt akar, aztán megláttam az imperatív kódot, és röhögőgörcsöt kaptam. Kiváló példája annak, amiről azt gondoljuk, hogy hű, ez jó lesz, aztán idővel kiderül, hogy mégsem). Alapvetően nem rajongok a deklaratív jellegű programozásért, különösen nem java-ban, annyival nem lesz szebb a kód, mint amennyi problémát behozhat.
+1
... a sok hülye feature, csak azért, hogy idióták is tudják "használni" a számítógépet, hadd lehessen őket is HD flash reklámokkal bombázni, hogy minél több potenciális vásárló-robot legyen. ... meg a korlátos neten minél hamarább lepörögjön a kiszabott korlát, hogy aztán netezhessek 10x, 20x annyiért, aminek a 80%-a meginn csak flash reklám.
Érdemes megnézni pl. egy facebook html forrást, aztán csodálkozni, hogy miért van több 100kbyte html/css/js rizsa <-- --> között.
A pörgő processzor ugyebár jobban pörgeti a villanyórát is, úgyhogy akár a kőolajmaffiára is visszavezethető a dolog.
Erre magyarázat csak a kapitalista üzletközpontúság lehet, mert ha egy programot/rendszert ténylegesen fejlesztenek, nem pedig üzleti irányvonalakhoz terveznek, akkor a régi funkcióknak ugyanazon a vason ugyanazzal a sebességgel kéne futniuk, vagy esetleg gyorsulniuk.
-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba
Kedves nézőink, hétfő reggeli konteónkat olvashatták... kérem ne feledjék, figyeljük önöket :)
Szóval a programozók azért írnak rossz kódot hogy az olajmaffia meg az ELMŰ gazdag legyen. :D
--
http://developersideas.blogspot.hu/
http://neurogadget.com/
És csapataink harcban állnak a rezsidémon ellen :)
Ezért.
Igen, ez is egy létező jelenség. De ezen kívül van még bőven ok, hogy miért.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Persze, nyilván az igények egyre nagyobbak lesznek, a programozó fizetése pedig több, mint a gépek bővítésének költsége. Nem tartom ezt nagy problémának egyébként -- változik a világ.
Nálam az, hogy hétfő van és dolgozni kell. Tegnap sokkal kisebb volt a gépigényem.
--
Direp
Szerintem a dolog kétoldalú.
Egyrészt az Intel meg az AMD sorban f0sta ki az egyre inkább felskálázott (órajel) single core procijaikat, ezzel szinkronban mindig egyre több RAM állt rendelkezésre (ez tartott kb. a 386 -tól majdnem mostanáig). Ez a dolog levette a programozó válláról a hatékony és skálázható kód írásának terhét: nem baj ha közepesen szarul teljesít a kód, mert a holnapután kapható procin kitűnően fog üzemelni.
Másrészt ezzel összhangban a mai programozó nemzedék nem igazán törődik a hatékony kóddal, megírja, leunitteszteli, működik aztán jónapot.
Szerencsére ennek kezd vége lenni, mert 2-3 ghz környékén elkezdenek a fizika törvényei beleugatni a dologba, és nincs más megoldás mint a 2,4,.. magos SMP procik kiadása. Ennek a megfelelő kiaknázáshoz viszont meg kell tanulni programozni, ismét. Aki pedig nem teszi, az előbb-utóbb végzetesen lemarad.
--
http://developersideas.blogspot.hu/
http://neurogadget.com/
Vagy majd lesz egy rohadt vastag szoftver réteg, ahol egy queue-be etetik a parancsokat leosztani a magok közt - és ott majd az lesz lassú. Majd akkor jöhet a 128 mag. Aztán majd a shared memória lesz a szűk keresztmetszet (addigra már az SSD-k régen azok). ...és mégsem kell majd annyira éretni hozzá.
Biztos vagyok benne :)
Egyébként http://en.wikipedia.org/wiki/Java_version_history#Java_SE_9
"There are plans to add automatic parallelization using OpenCL.[1][147]"
Ez persze csak az egymás után következő utasítások közül azokat hajtja végre párhuzamosan, amiknek nincs semmi közük egymáshoz (gondolom), tehát sokat nem segít.
--
http://developersideas.blogspot.hu/
http://neurogadget.com/
Legszebb az, hogy ilyet a CPU-k mar reg csinalnak: egy P-es ha tud, két utasítást hajt végre egyszerre.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Szerinted a java language level -en ; -vel elválasztott utasításoknak van valami közük a CPU-hoz? :D
--
http://developersideas.blogspot.hu/
http://neurogadget.com/
... viszont nem minden programnál/rendszernél nőttek a gépigények. Nemrég fordítottam le egy új kernelt, meg alap linux programokat, (glibc, coreutils, util-linux, bash, sed, grep, findutils, gcc, m4, make, autogen) és meglepődve tapasztaltam, hogy ugyanazon a vason, ugyanazon optimizációkkal jobban teljesítenek. (linux-2.6.35 -> linux-3.10.9, glibc-2.11.2 -> glibc-2.18.0)
Meglepődtem pl, hogy a sed 1:32 alatt lefordult, ami korábban kb. 3 perc körül mozgott.
Úghogy, a programozók nem minden esetben "trehányak" ...
-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba
Van olyan, ahol nem látszik ez a tendencia.
Pl. AIX alatt gyakran feleakkorák a programok. Egyszerű unix alatt futó dolgokhoz gyakorlatilag mindent belepakoltak a libc-be. Több mint 20 éve precíz dependenciák (ha el nem cseszik). Pontosan szabályozhatod mit akarsz felrakni.
A mese: Mindenkinek az a baja, hogy feleslegesen túl gyors programokat írok. Az az alapelvem, hogy diszkről olvasva 1uS késlekedés egy egész fordulat lekésését jelenti. Átadtam egy rendszer, amely úgy 1000x kisebb terhelés mellett oldotta meg ugyanazt a feladatot, amit a kiváltott rendszernek kellett volna. A megrendelő mint a hülye, nem is értette mit mondok. (Mutogatok grafikonon.)
Ez az ember nem volt ennyire buta, csak
- nem tudta mennyi a feladat
- mennyi erőforrás kell hozzá
- a fentiek szerint mennyi idő kell
- és mindez nem is érdekelte
Vajon 386-oson miért volt probléma az 1x sebességű CD írása, amikor minden sallangot figyelembevéve akár 100x nagyobb buszsebesség is rendelkezésre állt?
A hd video sem bonyolultabb logikai kérdés ennél.
A hd video sem bonyolultabb logikai kérdés ennél.
Azaz?
mc futtatására képes eszközt munkagépnek nevezzük
Nem, nem aludtam el.
Azaz: Ha a programozó
- nem tudja mennyi a feladat,
- mennyi erőforrás kell hozzá,
- a fentiek szerint mennyi idő kell,
- és mindez nem is érdekli,
igen lassú programokat tud írni.
Tapasztalatom szerint az elvileg rosszul működő program alá hiába raksz alá nagyobb vasat, nem lehetséges gyorsítani.
Kedvencem a jdownloader. A hozzá képest 10x lassabb router ki tudja rakni a grafikont a letöltési sebességgel.
"A Winamp jó, alig terheli a cpu-t mp3 lejátszáskor." Az mp3 tömörített formátum. Kitömörítés nem terheli a cpu-t, csak a rosszul megírt program.
Hdvideo -> ha le tud jönni a diszkről, a renderelést a gpu végzi, vajon mitől lassú az egész, ha a kritikus helyeken elegendő a sávszélesség?
Ezek a költői kérdéseim.
Ilyen dolgokon nem segít az absztrakció. Az ilyen megoldások csak a teljesítményt zabálják, a feladat ismerete nélkül. A programozók sok esetben nem értik a feladatot, ezért hibás megoldásokat választanak. Megkaptam már én is: Miért nem nézel körül? Használjál modernebb eszközöket! Amit választottam egy igen nagy guru elé került elbírálásra: Megmondta, ez az eszköz zseniális a feladatra. (Nem én!) Csak aki kifogásolta a döntésemet nem tudja a mai napig miért volt jó a választásom. (Nem zsákbamacska: Oracle vs. BerkeleyDB)
"Hdvideo -> ha le tud jönni a diszkről, a renderelést a gpu végzi, vajon mitől lassú az egész, ha a kritikus helyeken elegendő a sávszélesség?
Ezek a költői kérdéseim."
az igen és ez tényleg igaz :D
Egyébként az mp3 rendszerkövetelménye tudtad mennyi?
Pentium90mhz...
De ennél mehetünk lejjebb is, 8bites PIC-en is láttam már mp3 lejátszó alkalmazást, szóval.
Sajnos csak "pci" kártya fogadására alkalmas slot van a régi pentium3-asomban, akkor itt lehetne-e valamilyen gpu-t belerakni, hogy fusson az a hdvideo?
Tudom elvetemült, én már meg nem csinálom, de érdekel.
mc futtatására képes eszközt munkagépnek nevezzük
Nem, mert nem találsz olyan GPU-t, ami programozható shadermagokkal rendelkezik, es felhasználható GPGPU-ra, ami alapvető szükséglete ahhoz, hogy a GPU-n dekodold a filmet. Ld. CoreAVC codec, ami jobbra volt megírva az akkor használt Open source ffmpeg helyett, de GPU-t csak akkor használt, ha nVidia kártyád volt, CUDA támogatással.
P3-min HD felejtős.
Egyebkent az ARM bizbaszok is csak celharsverrel képesek lejátszani a HD-t.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
:) Látom, kötözködni nem csak én szeretek. :)
A PCI kártyákban is van GPU, de valószínűleg nem elég gyors. Sőt a régi kártyákba a kép sem fér bele, meg felbontása sincsen.
MP3 -> rendszerkövetelmény (azmiaz?) -> Pentium 90MHz <- Az meg egy CPU, és nem rendszer.
Mivel az MP3 sem szoftver, hanem formátum. A Winamp az szoftver. A formátumot meg dekódoljuk.
A dekódoláshoz meg CPU sem kell. Tudtad?
A PIC annak ellenére, hogy 8 bites, elég nagyágyú. Az MP3 44,1kHz sztereo és 16b esetén olyan 0,23MB/s adatsebességet jelent. Egy nekem tetsző szerver memóriasebessége >100GB/s. Ez félmilliószoros különbség. Ha létezik olyan MP3 játszó szoftver, ami a középmezőnybe tartozó gépek bármilyen terhelést okoz, az biztosan nem a gép hibája. Márpedig van ilyen, és egy MP3 játszó elég aprócska egy videojátszóhoz képest.
Talán arra céloztál, hogy nem is ez volt a kérdés? Pedig pontosan erről az arányról van szó. Ha a hardver a Moore-törvény szerint gyorsul, akkor a szoftverfejlesztés silánysága is, csak kicsit nagyobb kitevővel. Ugye, a kamatos kamat...
Minden fiatal programozóval előfordul, hogy megírja élete nagy rendszerét. Szintén tapasztalat, hogy az első továbbfejlesztésnél kb. 70% kihullik a kódból, miközben újabb funkciókkal gazdagodik. Ez a "jó" eset. A valóságban általában nincs idő a takarításra, így a felesleg bennmarad. És csak látszólag nem zavar senkit.
A dekódoláshoz meg CPU sem kell? Ezt így hogyan?
Kosz, ez mar feljebb is megutotte a szememet. En sem ertem
" ""A Winamp jó, alig terheli a cpu-t mp3 lejátszáskor." Az mp3 tömörített formátum. Kitömörítés nem terheli a cpu-t, csak a rosszul megírt program. "
???? Eloszor azt hittem, felre van irva, de aztan rajottem, hogy megis igy gondolja.
--
http://www.micros~1
:)
Nézz utána, hogy az Apollo 11 holdraszálló moduljában milyen CPU volt. Tanulságos. Két speciális nyelven programozható 8 feladatos realtime gép! Összesen 4800db NOR kaput tartalmazott.
NOR -> Y=!(a|b)
Programozott feladatot el lehet végezni céláramkörrel, kis- és nagynomású pneumatikával, hidraulikával. Áramkörileg sequencer-rel. Olyan is van, amit analóg
Ha MP3 dekódolás érdekel: A hardware implementation of an MP3 decoder
Még annó volt egy pneumatika vizsgamodulom, ott tanultunk pneumatikus vezérléseket, semmi elektronika nem volt benne a kompresszor motoron kívül.
Ugyanaz az "analógiája" mint a ttl/cmos digitális elektronikának.
Hidralika meg ugyanaz logikailag mint a pneumatika, csak ott az olajat vissza kell csatolni, nem úgy mint a levegőnél ahol gyakorlatilag kimegy az atmoszférába.
Analóg logika is létezik igen :)
PLC egyébként részben ezeknek a borzadályos szuszogós cuccoknak a virtualizálására lett kitalálva. Most tekintsünk el attól, hogy akár szegmenses kijelzőt is lehet plc-vel vezérelni.
Egyik tanárom csinálta ezt, elég jó fejtörő feladat.
Apollo 11 CPU-jára kíváncsi vagyok nagyon.
NOR -> Y=!(a|b) no comment :D programozóknak részletezted ennyire? :D
mc futtatására képes eszközt munkagépnek nevezzük
Naná, hogy a programozóknak! :))
A szoftver kb. hol kezdődik:
Néhány hétszegmenses kijelzőt hajtottam sorosan 74ls259 kimeneteken keresztül. Kötőgép vezérlés, fonalak, elektrosztatikus zavarok. A kijelzőn néha megjelent a 888888. ?? A hiba oka, hogy a Texas gyármányú bufferelt, a Fairchild meg nem, vagy forditva, és a hosszú kábelen bejövő zavaroktól a kimenő D flip-flop elbillen. De ez mindegy, mert be volt forrasztva, drótozva. A megoldás firmware csere, ahol az 1ms realtime vezérlés még azt is megkapta, hogy dinamikusan frissítse a kijelzőt - így eltűntek a nyolcasok.
A csókák megépítették: Apollo Guidance Computer
Tudom még ajánlani a Signetics 8X300 CPU-t, ami 8 utasításos risc like. Rakétairányításra készítették. "...could fetch, decode and execute an instruction in only 250 ns. Data could be input from one device, modified, and output to another device during one instruction cycle..."
Ez egy 1978-as technológia. Ha jól megnézzük, a mai processzorok utasításkészlete elbújhat mellette. Akkor még nem volt cél a "magasszintű nyelvek támogatása" == jobbára az volt a kódban amit meg kellett valósítani, sallangok nélkül.
Ezekből is látszik, hogy mindazt az elméleti tudást, amit a mai fejlett módszerek képviselnek meg lehetne valósítani sokkal gyengébb eszközökkel is.
Ahogy a mosógép, a kávéfőző, a csirke, a paradicsom meg a kenyér, a szoftver is értékelemzett és futószalagos lett. Ahol bioszoftver kell, ott megfizetik a bioprogramozó biomódszereit, ahol meg nem, ott bíznak abban, hogy a 4-5-6...GL több hasznos anyagot tesz bele, mint engedélyezett adalékot.
Ha megnézzük, hogy hol tart ma a Windows/Total Commander, és hol a Dos Navigator, jól számít aki a sokGL-be fektet inkább, ha nincsenek speciális igényű kapcsolatai.
Kapcsolódó Joel on Software: http://hungarian.joelonsoftware.com/Articles/BigMacsvs.TheNakedChef.html
---------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
+1
Bár a szoftvert kevesen írják, sokan használják.
Az ebédet meg ki tudja?
+1
Fantasztikusan jó az írásban felhozott analógia, örülök, ha elolvashattam!
A gépigény növekedésének valóban az az egyik fő oka, hogy mára közepes vagy rosszabb a programozók java része. Na nem az eddigi jó programozók romlottak le, vagy születne kevesebb potenciális jó programozónak való ember, hanem ugyan úgy felhígult, mint az informatika úgy általában. Mert ugye ez egy olyan szakma, mint a foci - ehhez mindenki ért...
A sok átlagos ember pedig a saját átlagos módján megoldja az adott feladatot átlagosan, vagy gyengébben - ahogy a linkelt írás is ecseteli. Az a pár nagyon jó képességű, aki valóban programozó, pedig leginkább javítja a hibákat, mert az átlagos nem biztos, hogy rájön, mint rontott el. Vagy elmegy mást csinálni, mert elkeseríti, hogy milyen tudásért kap más mennyi pénzt.
Jó példa a víruskeresők területe (mert az igen gyakran változik és elég látványosan nőnek az új belépők). Megjelenik egy új gyártó egy nagyon jó termékkel ami gyors és hatékony. Sokan megveszik, elégedettek vele. Aztán eltelik egy év, max. kettő, és vagy saját maguk nőnek vélt vagy valós plusz igények kielégítése miatt (hogy a kezdeti robbanásszerűhöz mérhető legyen a további növekedés), vagy felvásárolja őket egy nagyobb szereplő, azért "nőnek meg". Akárhogy is alakul, a következő 2-3 verzió során annyira leromlik a minőség (itt leginkább az azonos funkció mellett megugró gépigény tűnik fel), hogy az első licencek lejártakor váltani kell az akkor épp induló újra gyártóra, mert a "frissített" verzióhoz új gép is kellene, annyira rosszul megírt a kódja - a megfelelő képességet nélkülöző sok új fejlesztő bevonása miatt.
A mesterségesen felpörgetett üzlet miatt a tesztelés is a fizető felhasználókra hárul a fejlesztő helyett, de ez már annyira általánossá vált, hogy senkinek nem jut eszébe pereskedni egy kifizetett, de rossz/nem működő szoftver miatt, mert hát ez mind ilyen. Társadalmilag elfogadottá vált, hogy minden szoftverben rengeteg a hiba, ezzel csak együtt lehet élni, nincs mit tenni ellene...
A programozás igazából nem egy megtanulható szakma. Valakinek vagy rááll az agya (van hozzá érzéke), vagy nem. Hiába tanul meg akármennyi nyelvet és programozás-elméleti ismeretet. Ha az agya nem úgy működik, mint egy programozónak, akkor sohasem fog jó programokat írni, akármilyen kitartó.
Aki azt mondja, hogy a jó programozóvá váláshoz csak kitartás kell, az szerintem téved.
Viszont annyi jó programozó valójában nincs (ilyen gyorsan), amennyire a szoftvercégek növekedni szeretnének a profit-maximalizálás érdekében.
Mi lenne, ha a mai átlag programozó visszakapná az operátortól a nyomtatott programlistát, hogy "542-es hibával zárult a végrehajtás, keresd meg, mi okozhatta"... :-)
+1
A programozásról alkotott véleményed jó, csak egy kicsit kiegészíteném.
Mindig magyarázom a laikusoknak, hogy a programozás csak egy szerszám, olyan mint a lapát. Persze absztrakció is, de hát az írás is a szimbólumok szimbóluma.
Úgy lehetne tanítani, hogy gondold végig mit kellene tenni! Nagyon nehéz idegen nyelven kifejezni magad, ha magyarul sem tudod megfogalmazni a gondolataidat. De ha valaki képes megoldani egy problémát, és van egy kis érzéke a rendszerkörnyezethez, akkor még a gyengébb program is jól működik.
"Mi lenne, ha a mai átlag programozó visszakapná az operátortól a nyomtatott programlistát"
:)
Odra 1024, Algol60. De valójában egy Ti57 zsebszámológépen kezdtem programozni. Tegnap.
Valóban szerszám, de azért nem olyan, mint a lapát. Mivel a lapát egy dologra jó, és nem túl bonyolult megtanulni a használatát arra az egy dologra.
Viszont a programozás nagyon összetett szerszám, használni sem egyszerű emiatt. Pláne szerszámként használni feladatok sikeres megoldására. Pláne a sikeres megoldás alatt jó minőségű kódot is értve.
Ha már szerszám a hasonlat, akkor inkább mesterlövész puska. A puska kezelését, a belevaló lőszerek fajtáit, szét- és összeszerelését, szabályos tárolását, terepen való álcázását, stb. meg lehet tanulni. Sőt, a környezeti változók figyelembe vételét is meg lehet tanulni idővel. Viszont egy találathoz ennél sokkal több kell.
Ha már szerszámos analógia, akkor inkább a szerszámos ládát mondanám, egy eszköznek tekintve az egészet a tartalmával együtt. Ott van, bárki bemehet bármelyik boltba és vehet egyet, de ha nem tudja, hogy mit húzzon ki belőle, akkor bizony kalapáccsal fogja a csavar rögzíteni.
BlackY
Értékelemzett helyett funkcióelmzettet lehetne mondani.
Amikor tanultam, a modell egy villanykapcsoló volt. A magyar gyártók is átvették a módszert: ideálisan minimális alkatrésszám, de a falra szerelve nem működik. Az anyagválasztás és a mechanikai kivitelezés -1. Ellenpélda: Legrand kapcsolók 1200, 1500, 1900Ft funkció szerint. Ugyanaz Kopp esetében 780Ft, és az összes funkciót tudja, és még szebb és stabilabb is. (Elnézést kérek, az árak nem naprakészek.)
Minden villanyszerlelési boltban NEM KOPP kapcsolót lehet kapni!!
Gondolom, nem erőltetnéd meg magad, ha szoftverekkel és szoftvergyártókkal kellene a fenti példát behelyettesíteni.
Mert egy terméknél nem elég az hogy jó legyen, olcsón kell tudni gyártani, nagy mennyiségbe, és a legfontosabb: el kell tudni adni. Anélkül lehetnek a legokosabb
fejlesztők, a legjobb termékkel, ha a konkurens butább emberekkel egy fele olyan jó terméket fejleszt, de azt el tudja adni, akkor nekik lesz pénze, az okos
fejlesztőknek meg nem.
Na ez jó példa.
A Kopp katalógus kb 20 oldal. Választhatsz szinekből és ennyi. KB megfelel egy fullos alaplapra integrált számítógépnek.
A Legrand alapban 4-6 fajta kapcsolócsaládot tud amiből a hétköznapitól a spec igényekig is el lehet menni. Pl a Galea család már 2000 körül tudott szerelvénydobozba építhető világítás vezérlésre alkalmas mozgásérzékelőt, kulcsos kapcsolót, redőnyvezérlést, többféle analóg és digitális (akár kvarc kijelzős ( ebben az időszakban kb 40000 volt darabja)) termosztátot, komplett fényerőszabályzó rendszert, ma már tud riasztót, hangrendszert, folyadékérzékelést, nővérhívót...
Azt csinálsz belőle amit akarsz. Ez kb megfelel egy célfeladat ismeretében hw optimalizált gépnek...
Szerk.: plusz jelzőlámpák, irányfények, csengő,
kombinált gyengeáramú aljzatok.
És a Kopp-al ellentétben nem szakad meg benne a csavar. Van hozzá telefonos/helyszíni support.
- - - - - - -
"Nagy kár, hogy az informatika abba a korba ért, hogy lehet nyugodtan pazarolni az erőforrásokat." Saxus
Bár kissé félreértetted a funkcióelemzés és a divat/összefonódás jellemzését.
Nem arról szólt, hogy a villanykapcsolón android vagy windows fut-e.
De sajnos rossz Kopp katalógust néztél meg! Valószínűleg egy kapcsolócsalád prospektusát.
Ez a tudásszint kb. olyan, mint text mode linux boot esetén kijelenteni, hogy fujj ezzel nem is lehet internetezni.
Mindkét gyártó termékét szereltem. (No jó szerelgettem.) A Kopp-ban kevesebb csavar van, ugyanakkor csavarmentes kötéssel villanytűzhelyet is visz 20 éve.
Ha a választék érdekel - teljesség igénye nélkül - a Kopp-nak is van távirányítós "lakásvezérlő rendszere". A többtápos szerveremhez is Kopp túlfeszvédő elosztót használok, de ez véletlen.
Ettől a villanykapcsolók áraránya és elérhetősége a legközelbbi boltokban igaz maradt.
És ez a fontos, mert speciel sokkal több egyszerű kapcsolót használok, mint nővérhívót. Elég nekem egy is. :)
Köszi:
The target hardware of the project is a Virtex-II 1000 FPGA... Laza 45 ezer forint. Hol van ez a PIC-hez?
Mondtam én, hogy olcsóbb?
FPGA != CPU => Ez igaz.
Az FPGA ebben az esetben egy fejlesztőeszköz, az általa megvalósított logikai áramkör egyszerűsíthető, nagy sorozatban legyártható. A végtermék olcsóbb és kisebb fogyasztású, ára PIC árával összemérhető.
A PIC egy általános felhasználású egycsipes mikrogép. Nem erre való.
Szóval a pendrive méretű MP3 játszóban nincsen sem Core i7, sem PIC.
(Fejlesztőeszköz: Ha írsz egy szoftvert, ugye nem adod minden példányához a Visual Studio-t?)
És az ilyet adják el úgy, mint mp3 lejátszó chip. Te meg PIC-ről beszéltél. Idézet tőled:
"8bites PIC-en is láttam már mp3 lejátszó alkalmazást" tehát továbbra is várom, hogy hol láttál 8 bites pic-en mp3 lejátszó alkalmazást, mert az,
hogy egy külső mp3 lejátszó chip-nek átdobom az adatokat, az nem az.
Ez mellément! Én csak idéztem. Aki látta: tordai_hasadek
De miért ne lehetne egy gyorsabb piccel dekódolni?
Oh, ezt benéztem, bocsi. Miért ne lehetne? Gondolom a memória is kicsi, a sebesség
is gyenge, valószínűleg ez az oka. Ha meg csinálunk egy felgyorsított pic-et nagy
memóriával, az már nem pic.
No igen, csak nem mindegy, hogy mennyi idő alatt, mekkora lesz a végtermék, milyen egyszerű gyártani, stb. Úgy látom, hogy te nagyon a villamosmérnök oldaláról fogod meg a szoftverfejlesztést, ami nem baj, csak az esetek nagyon nagy részében nem ez nyerő stratégia. Nekünk nem végtelen időnk van hogy a kódot reszeljük, hanem fix határidőre kell egy adott terméket leszállítani, ami stabilan, elfogadható sebességgel fut adott gépen, ki van tesztelve, esetenként skálázódik is, valamint több másik cég termékéhez
kapcsolódik, majd a kiszállítás után a customer még egy marék feladatot talál ki, hogy ezek nélkül nem akar élni, és tegnapra kéne.
Na, ebben a környezetben kell értelmezni a hatékonyságot. Az Apollo 11 lényegtelen ilyen szempontból, rá lehetett állítani több száz mérnököt, és lényegében végtelen erőforrást az adott feladatra. Ez rohadtul drága. Ugyanúgy, ahogy valószínűleg az analóg számítógép (vajon használ-e még valaki ilyet, történelemkönyvben olvastam róla), de az is iszonyat drága: drága fejleszteni, drága hibajavítani, drága sorozatgyártani)
Úgy gondolom, az Apollo 11 eléggé feszített program volt bármilyen mai projekthez képest. Most kiszámoltam: 2,5 év alatt készült el. És nem csak egy szoftvert kellett írni, hanem eléggé kaotikus viszonyok között dolgozni kismillió jó/rossz visszacstolással. Biztosan jól megfizette a gyerekeket a NASA. A szoftverfejlesztő gárda pedig: "I and my good friend Don Eyles were two of the 'young experts' at the MIT Instrumentation Lab - Draper Lab - who worked on the software for the LEM guidance computer." (Apollo 11 Program Alarms)
Ez két fő.
1988-ban harmadmagammal 3 hónap alatt készítettünk olyan szerkezetet, amiért a cég 450MFt-ot kaszált. 1995-ben 1500MFt-os rendszerrel "voltam kapcsolatban". Megsúgom, nem én voltam a vezérigazgató. :((
Szóval úgy gondolom, nem látod az egyes korszakok közti különbséget.
Manapság a káoszt a tervezés hiánya, küzdelem a módszerekkel és toolokkal okozza, meg az, hogy nics specifikáció. Da van szívás!
Ja, és a villamosmérnök, amikor megtervezi az ármkört, a firmware-t, mindig önszervező. Ennak az az oka, hogy át kell latnia a feladatát, más meg úgy sem látja át. Ezzel szemben a szoftverhez mindenki ért, vagy legalábbis úgy hiszi. A végeredményt meg tapasztalod.
Na, nem ezt írták. Ők a teljes kódolás egy részét csinálták:
"Because the more experienced people at the lab were concentrating on getting the Command Module Computer software right, the two kids were given the responsibility for programming the LM powered-flight routines."
Ez azért nem mindegy.
A tervezés hiánya: ezzel egyetértek. Csakhogy, most sokkal olcsóbban kell előállítani termékeket, sokkal kevesebb fejlesztővel, folyamatosan változó igényekkel, olyan ügyfelekkel, akikkel 30 évvel ezelőtt nem kellett foglalkozni, mert hogy egyszerűen nem léteztek. Az, hogy 20-30-40 évvel ezelőtt hogyan fejlesztettek szoftvert, az nagyon szép és jó, csak sajnos a megváltozott körülmények között a régi módszerek (teljesen specifikált rendszerek kódolása sok fejlesztővel, sok idő alatt) már egyáltalán nem működnek. Én is láttam telefonközpont specifikációt, és láttam, hogy a terméket is milyen brutál jól megcsinálták (futó alkalmazást menet közben lehetett patchelni újraindítás nélkül), és láttam azt is, hogy a termék utódja hogy készült, és milyen lett, de ez lényegtelen, a lényeg az, hogy az adott termékből mennyit lehet eladni, és az mennyi pénzt termel.
Villamosnmérnök önszervezősége: amíg a feladat olyan méretű, hogy 1-2 ember meg tudja csinálni, lehet önszervező módon csinálni. Csak amikor 5-8-10 ember munkája függ egymástól, ott már hiába az önszervezőség, nem fog működni a dolog.
Nem mindent csináltak. Mellékesen több nagygépen is szimuláltak, azokat a gépeket is programozta valaki. Meg két számítógépről beszélük, mert a parancsnolki modulban és a holdkompan is volt egy.
Itt arra a srácra gondoltam, aki pár másodperccel a holdkomp lezuhanása előtt eldöntötte, hogy folytathatják. Eltörött/szakadt az egyik radar, és a hibaüzenet mindig előjött, nem látták mikor kell tankolni. ;) Ő biztosan egyedül, legfeljebb másodmagával írta a leszállóprogramot. Ami biztosan kisebb volt a legkisebb mai programnál, mert nem volt több memória. :))
Mondok konkrét példát: VIDEOTON lézernyomtató fejlesztés. Kb. 15 fejlesztő és 3 beszállító cég. Projektmenedzsment nuku. Ugyanakkor a HPLJ fejlesztésnél (Ha fiatal vagy ezt nem ismered, egy leporellóra nyomtató 45 lap/perc teljesítményű gép) 12 fejlesztő csoport volt.
Gondolom ott volt projektmenedzsment.
Azért - ha már Moore-törvényt emlegetünk - mielőtt szívlapáttal egyengetjük ki a szoftverminőségért felelősöket, tegyük hozzá, hogy a vasak nem csak gyorsabbak, de komplexebbek is lettek, nem utolsósorban azért, mert minden, saját házi szabványt összekalapáló cég eszköze tudni akarja a többi gyártó háziszabványait is. Az implementáció vagy tökéletes, máskor teljesen hibás, megint máskor csak peches esetekben aktivizáló bugot rejt, és van, amikor működik csak sokkal lassabban, mint kéne - a kernelek és moduljaik pedig (mi egyebet tehetnének?) úgy patkolják ezeket, ahogy egyáltalán lehet, ami nem mindig jelenti azt, hogy szépen és jól.
(Évek óta nem fordítottam háznál kernelt, de emlékeim szerint sacc/kb. a fordítási egységek 5%-a volt, ami hw lyukakat tapasztott be.)
Én is hallottam mennyire fantasztikus a Windows, ugye hány féle hardveren fut!
És hány féle szívási lehetőség van pontosan ezért!
De azért csak nem gondolod komolyan, hogy a copy is ezért fut 3x lassabban???
Miért, 3x lassabban fut? Márhogy kimérted a másolást ugyanazon a vason különböző verziók között, és ilyen tendenciát láttál?
De kérem!
Műszaki adatokkal soha nem poénkodok!
Nem csak én mértem, hanem olyan kolléga, aki céges környezetben is 10000 nagyságrendű installációt végzett, és teszteli a különböző a verziókat. (Garantálom nem tökhülye a windowshoz.)
Sőt. A linux (ez itt most nem pontos) 2-3x gyorsabban olvassa az NTFS-t. A find cygwin alól legalább 10x, ha nem lényegesen gyorsabban keres a directory struktúrán. Ezt élesben, 80 rendszeren mérem nap mint nap. A rendszerem méricskéli a válaszidőket, és visszafogja magát, ha túlterhelné a rendszert.
Pedig lassanként az összes 64 bites szerver lesz...
Szóval nem jó szöveg, hogy a hardver egyre bonyolultabb.
Egyébként az mp3 rendszerkövetelménye tudtad mennyi?
Pentium90mhz...
486DX/2 80 MHz-es gépen már 1998-ban hallgattam...
Úgy, hogy mellette semmit nem lehetett csinálni, mert szétfogta az egész gépet.
Core i3-as laptop USB3-as portján külső USB3-as merevlemez is "szétfogja az egész gépet" pl. másolás alatt. De modern a vas,
--
robyboy
"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor
Pic-en úgy láttál mp3 lejátszót, hogy hozzákapcsoltak egy mp3 dekóder chipet (pl. ezt http://www.vlsi.fi/datasheets/vs1011.pdf)
En negyed eve uzemeltetek Oracle-t, de az eddigiek alapjan nem nagyon tudok olyat mondani, ami ennel szarabb. Egyszeruen gyalazat, hogy ezzel az otvar gane hulladekkal kepesek penzt keresni. 36 karakternel nem lehet hosszabb az install path? Elerheto szabad hely random atvalt negativ szazalekba, es leall az enterprise manager? Uninstaller kerdes nelkul letorol minden adatbazist? ... WTF?!
Talán szakember kellene hozzá és nem egy dilettáns csimpánz :D
(Na meg azt sem árt szem előtt tartani, hogy nem windózerre lett kitalálva)
Megjegyzem, pont ezért dolgoznak az oracle szakértők csillió pénzért. Nincs ebben semmi gond,
az oracle külön állatfajta.
:)
Szoptam vele közel tíz éven át, tudom, hogy komoly hülyeségei, rigolyái vannak, de így leszarozni... ehhez mérhetetlen nagyképűség és dilettantizmus szükségeltetik.
Negyed év? Nem lehet, hogy kissé elkapkodtad az ítéletalkotást? Mondjuk 3-4 évvel? Annyi idő alatt leszűrődhetett volna, hogy az adatbáziskezelők frontján - ha lehet - még nagyobb a küzdelem, mint az irodai alkalmazásokén. Az újabbnál újabb fícsöröket a versenytársat megelőző hájp érdekében nem ritkán ismert hibákkal adják ki abban a reményben, hogy a tényleges piaci terjedés idejére meglesz a fix. Nem csak az Oracle, mindegyik. Én a nagy riválisának az oldaláról tudnék említeni olyan bugokat, amelyek vagy azt igazolnák, hogy alapvető teszt maradt ki, vagy azt, hogy megvolt a teszt az eredménnyel, de a marketinges felmutatta a T alakot formázó kezeit.
Emellett pár év alatt az is belátható lett volna, hogy a több platformon is létező rendszerek jellemzően minden platformon olyan kompromisszumokkal léteznek, amelyekkel a többi platform lehetőség szerinti egységes kezelése érdekében tanulnak megy együttélni az alaklmazók.
Aszondom, szánd rá azt a pár évet az ismerkedésre ezen szempontok mentén figyelve az eseményeket.
Szerintem pedig az az ok, hogy "hígul" a szoftverfejlesztői szakma, és egyre kisebb és bizonytalanabb tudású emberek készítik a szoftvereket, amik meg egyre nagyobbak. Néha olyan megoldásokkal találkozom, hogy elgondolkodom rajta, hogy miért is nem mentem inkább halásznak. Igaz, hogy a halászok korán kelnek, büdösek, de nincsenek ilyen problémáik, hogy pl. javíts bugot egy olyan szoftverben, amiben a változókat és az osztályokat nem aszerint nevezték el, amire használják őket, a terminológia nyomokban sem emlékeztet az üzleti terminológiára, és ha bővíteni kellett valamit, akkor nem plusz egy oszlop a megfelelő táblába, hanem plusz 3 tábla összejoinolva orrba szájba ID1, ID2, ID3 oszlop nevekkel, rendszerterv persze sosem volt, a felhasználó meg folyton panaszkodik, hogy lassú a szoftver (tényleg lassú), mert 20 millió soros táblákból joinol össze 5-öt (!), hogy megszerezzen olyan adatokat, amikből 10x annyi van táblánként, mint amennyi a tényleges adat lenne 1 táblában.
Na ezért lassú. Mert a profit az első, programozóból meg jó lesz az egyetemista is, tesztelni meg ugye minek, majd a júzer, QA hallomásból sem, elbírja ez, elbírja.
Mert például nálunk a felsőoktatásban is (Óbudai egyetem) az a fontos, hogy szoftver szigorlatra ismerj 15 féle rendező algoritmust, meg fejből tudd a b-tree kezelő algoritmusokat, de csak olyan megoldást fogadnak el, amit a tanár leadott órán, ha más (pszeudo)kódot írsz a vizsgán, lepontoznak, hiába jó a tied, a tanáré meg szar. B*meg, mi a búbánatnak kell 15 féle rendező algoritmust tudni??? Sokkal fontosabb lenne megtanítani a palántákat GONDOLKODNI, nem bemagoltatni velük a sok használhatatlan nyavaját, illetve egy szoftverfejlesztőnek tudnia kellene rendszerben gondolkodnia, képes legyen a problémát (feladatot) emésztető méretűre felbontani és tisztességesen megoldani. Amíg a modul fan in/fan out minimalizálás csak a szoftvertechnológia vizsga egyik kérdésében merül fel (lexikális tudásként), de soha többet sehol sem említik (a gyakorlati tárgyakon sem), addig nagy baj van.
Nagyon kevés jó fejlesztővel találkozom. Manapság a szoftvergyártás futószalagos tömegtermelés lett, olcsóbb, de persze sokkal szarabb minőségű is.
Assembly-ben is lehet lassú szoftvert írni, csak aki neki mer állni assemblyben megoldani egy komolyabb problémát, az valószínűleg már nem a szakma alján van. Volt szerencsém olyanhoz is, hogy "perl mágusok" kitalálták, hogy majd ők hiperszuper Java fejlesztők lesznek. Nem lettek. Nem azért, mert perl-ben nem tudtak megírni akármilyen text file manipuláló cuccot, vagy ne lettek volna képesek akármilyen algoritmust megírni Java-ban. Még a polimorfizmust is majdnem megtanulták. Hanem azért, mert aki perl scripteken szocializálódik, és el van telve önnön tudásával, a bödös életben nem lesz képes egy nagyságrendekkel bonyolultabb, 3 rétegű alkalmazást hatékonyra, könnyen tesztelhetőre és könnyen módosíthatóra megírni, semennyi pénzért sem.
Bocs a kirohanásért, csak mostanában gyakran futok bele olyanba, hogy mikor már az összeomlás szélén áll a projekt, kell valaki, aki kirángatja őket a szarból, persze akik okozták az egészet, nem ismerik be; ha már leléptek felmarkorva a zsíros pénzt, akkor az ügyfél lesz már rohadt ideges, hogy mivanmár és miért fog még ennyibe kerülni, hiszen egyszer már kifizette; ha meg még ott van még a szarkavaró brigád, akkor a gatyábarázás után meg hirtelen már nem kellünk, és nem hogy "köszönöm szépen, hogy segítettél megmenteni a munkám" hanem "büdösek vagyok, és különben is miattatok van minden" módon kiutál, mert a StyleCop full fasiszta beállítását nem vagyok hajlandó tolerálni, de hát valamibe bele kell kötni, mert a kódomat nem érti a drága.
Na ezért lassú.
A sok gyökér miatt.
Epic post is epic.
+1, különösen az OE-s, miért kell 15 féle rendezőalgoritmust tudni. Mert a 15 féle rendezőalgoritmus 15 féle módon 15 különböző jellemzőkkel működik. Az meg külön vicces, mikor a bemagolást emlegeti: nem bemagolni kell, hanem megérteni, ha bemagolást várnának el, nem részleteznék előadáson az egyes algoritmusokat, nem iratnának láncolt listákat, fákat, hanem csak leadnák, hogy ezt magold be. Az még viccesebb, hogy arról magyaráz, hogy hülyülnek a fejlesztők, de nem érti, miért vannak ezek a tárgyak. Gondolom az adatstruktúrákból sem kellett volna semmit sem leadáni, hanem csak használni a .NET/Java/STL/stb. beépített dolgait, nem megérteni előadáson.
A pszeudokódos rész meg... Nos, igazából szerintem ezeket az algoritmusokat, amelyeknek kódja többnyire 8-10 soros, nem nagyon lehet másképp megírni. De sebaj, várok konkrét példákat.
Ettől függetlenül nem állítom, hogy az OE-s képzésen nem lenne mit javítani, mert bőven van. De ez bármelyik egyetem képzésére igaz.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Felreertettel, en nagyjabol egyet ertek azzal, amit mondott. Tudom, hogy az algoritmusok azert vannak, hogy megertsuk oket, de ettol meg ez a legtobb esetben nem sikerul, a szamonkeres pedig szinten nem errol szol, hanem hogy ird le papirra ZH-n, o meg "egy hiba -> egyes" algoritmussal kijavitja :)
En az egyetemen max egy hozzaallast kaptam, de gyakorlati tudast zerot. Ha szuksegem lenne valami algoritmusra, akkor ugyanugy utana kene neznem, az ilyet az ember ugyse jegyzi meg hosszutavon, csak ha kurva sokat hasznalja elesben.
Nos. Nagyon is értem, miért vannak ezek a tárgyak. A leadott anyag minőségével, eloszlásával és számonkérésével nem vagyok megelégedve. Amire gondolok: a bűnbaknak kikiáltott 15 féle rendezőalgoritmussal az a probléma, hogy aki az iskola elvégzése után nem szoftverfejlesztőként akar elhelyezkedni, annak ez teljesen felesleges tudás, akinek pedig programozó/fejlesztő lesz, annak pedig ez a tudás nem hasznos. Nem sok emberrel találkoztam az esti tagozaton, aki az iskolában tanult volna meg programozni / jól programozni.
Amire nem tértél ki, hogy szerintem hiányos a szoftvertárgyakban a rendszerben gondolkodás kihangsúlyozása. A munkám során ennek a hiányát látom mindenhol, és sajnos sok fejlesztő nem képes ilyen szintű gondolkodásra. Az oktatásban szerintem nem kap kellő hangsúlyt, pedig hiába működnek jól önmagukban az egyes függvények/osztályok/modulok, ha a kohézió hiányzik.
A "pszeudokódos" részhez majd küldök példát, csak elő kell bányásznom az archív jegyzeteket.
Ez jut eszembe sokszor: http://www.softdevtube.com/2013/05/17/how-about-learning-fing-programmi…
Az előadó szintén kitér az egyetemen oktatott rendezőalgoritmusok problémájára, megy más egyebekre is.
+1. En is jobban orultem volna, ha nem eroltetik a szoftszigot, hanem pl. archi vagy halozat szigo van....
Mindegy, mar egy par eve megvan, hogy az utolso alkalommal sem sikerult a szoftszig, igy feladtam a sulit.
--
http://www.micros~1
"A leadott anyag minőségével, eloszlásával és számonkérésével nem vagyok megelégedve. "
Ezzel nem tudok vitatkozni.
"a bűnbaknak kikiáltott 15 féle rendezőalgoritmussal"
Lépjünk egy picit túl a rendezőalgoritmusokon és jussunk el az adatstruktúrákig (ugyanúgy PPT-n volt mindkettő). Sajnos hallottam már olyat is a folyosón valakitől, hogy "minek ezeket a szarokat tudni". Azért szerintem, amikor már valaki a láncolt listákra, hash mapekre, fákra, stb. is ezt mondja, ott már súlyos problémák vannak.
"Nem sok emberrel találkoztam az esti tagozaton, aki az iskolában tanult volna meg programozni / jól programozni."
Tény, de ezt el is mondják, hogy órán nem lehet megtanulni programozni, ott csak el tudják indítani az embert egy adott irányba. És ezzel vissza is térünk oda, hogy a szak neve mérnök informatikus.
"szerintem hiányos a szoftvertárgyakban a rendszerben gondolkodás kihangsúlyozása."
Nem, konkrétan egy szak hiányzik a felsőoktatásból: szoftvermérnök. De ez már sokszor téma volt itt.
Egyébként megkérdeztem egyszer Molnár Andrást, hogy miért a villamosmérnök szakból kiemelt/továbbképzett mérnök informatikus szak van (szoftvereseknek -szerintem- irreálisan sok elektro/villtan anyaggal) illetve a matematikus szakokból továbbképzett programtervező informatikus (ahol meg mindent tudnak elméletben, de ...) és miért nincs kifejezetten szoftvermérnök szak MO-n. Nekem a válasz alapján úgy jött le, hogy pontosan képben vannak azzal, hogy mi a baj most az oktatással, mit kellene hozzá tenni és miért nem lehet megtenni.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Tévedés ne essék, nem arra próbáltam utalni (elnézést, ha ezt sugallja a bejegyzésem), hogy felesleges alapvető algoritmusokkal, struktúrákkal foglalkozni. Ezeknek a megtanulása, megértése alapvetően segít a későbbiekben a megfelelő gondolkodásmód kialakításában, a problémamegoldó készség fejlesztésében. A problémám a a tananyagon belüli súlyozással, illetve a számonkérés módjával van (meg néha a tananyaggal). Nem azért "rinyálok", mert nehezen vettem a szoftveres tárgyakat, hanem mert már jó ideje szoftverfejlesztőként dolgoztam, mikor elkezdtem az iskolát, és az "iparban" eltöltött idő tapasztalata alapján alakult ki a fentebb is említett véleményem.
Molnár András pedig nagyrabecsülendő ember, mind a hozzáállása és a tudása alapján. Bárcsak több hasonló emberrel hozna össze a sors.
Amúgy egyetértek veled, csak úgy tűnik, másképp fogalmaztuk meg a gondolatainkat.
Digitális rendszerek + Digit I + Digit II + Irtech I + Irtech II stb... jobb lett volna ezekből kevesebb, cserébe pl PPT és AAO lehetett volna több/mélyebb - főleg a gyakorlatok.
... lassan hosszabb commentjeim lesznek, mint polinak ... no offence
"Nem, konkrétan egy szak hiányzik a felsőoktatásból: szoftvermérnök. De ez már sokszor téma volt itt."
Ezt eddig ilyen jól még nem hallottam megfogalmazva senkitől, köszi.
Szerintem sok igazság van abban, amit mondott, hasonlókat tapasztaltam én is. (no nem a 27. kereső algoritmust, de a trehány kódolást)
"csak aki neki mer állni assemblyben megoldani egy komolyabb problémát, az valószínűleg már nem a szakma alján van"
Ez jól esett!
Csúcson vagyok!
De miért is?
Mer' az ASSEMBLY!!!!!
Egyebkent a fap-fap faktoran kivul nem veletlen, hogy nem irnak ASM-ben sűrűn kódot: annyi architekturalis es subarchitekturalis nuansz van mar es akkorák a kodok, hogy egy butabb C fordító is átlagosan jobb kódot fordít, mint amit egy atlag kóser a legjobb pillanatában kepes lenne összerakni. Bar, ez manapsag nem feltétlen baj, de az mar igen, hogy egyeseknek viszont fogalmuk sincs róla es ohy meg csak halvany lila dunsztjuk sincs, hogy hogy mukodik a processzor (persze, ehhez kell meg egy kis digittech ismeret is).
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Plusz előfordul komplett architektura váltás (intel->arm)
Régen az ember gondosan kiválasztotta a platformot. (Ami a fiókban volt:)
Olyan szempontok játszottak, hogy a 12 centtel olcsóbb maszkprogramozott processzorban pontosan 3872B programterület és 96B RAM van. Sűrűn számolni kell egy bazinagy képletet, amire egyrészt nincs idő, másrészt van két 8 bites regisztered az A meg az X. (akkumulátor és index) Egy 16 bites összeadás néhány szubrutin hívásból meg is van ...
A kolléga tervezte a bipoláris videoprocesszort. 16 bit 8MHz órajel. Egy karakter alatt 8 videociklust tudok futtatni ...... 22 bites utasításkészlet kell. 300 db IC, 500 szó program, és két hétig rajzolgatott. A műszerésznő összerakta 2 nap alatt, a 2 elkötés kimérése komótosan 1 nap. Aztán működött. Utána csinálod?
Régen a C kódot asm lista alapján optimalizálták. A pipeline megjelenése után súlyosabb lett a helyzet. A Motorola meg G5(?) platformon, tán 128-ból 96 rename regiszter, olyan fordítót készitett, hogy megháromszorozta a futási sebességet. (Ez olyan nem Intel, hanem Motorola-IBM platform:)
Egy biztos: Ilyen módon megszerzett tudással jobban meg lehet érteni, hogy a 2x akkora kód miért fut 2x annyi ideig! Ezt a szoftveresek túlnyomó többsége nem látja.
Ime egy gyönyörű hardvertámogatott interrupt rutin fénykoromból, elég gyorsan futott:
org 18h
lda ncdcd ;reset decoder
ret
Ez mind szép és jó. De a szoftverfejlesztők tetemes részének nem ilyen szoftvert kell fejleszteni.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Jó reggelt! Ez itt az asm subnode, amelybe hardverfejlesztői sztorikkal nosztalgiáztam.
Azótai is torz hardveres szemüveggel nézem a viágot, és sajnálkozom az SAP-n, mert nem asm-ben írták. Bár, ha belegondolsz, akár írhatták volna és akkor 10-100x akkora költség mellett (ez már kész) még hatékonyabb és gyorsabb lenne (erre még várni kell). A szupergyors java kódokat meg nem videoprocesszoron GPU-n futtatnák.
Bevallom, igazi szoftvert még nem is írtam, csak adatfeldolgozásokat két nagyságrenddel gyorsabban, mint a "szegény unalmas életű szofveresek". Meg automatikus rendszereket, olyanokat amik egyszerre sok gépen futnak sokkal gyorsabban, mint az elődeim rendszerei. Azoké, akik informatikusok meg szoftveresek.
Hogy ezt mi okozza? Talán az, hogy hadrverfejlesztő voltam, vagy gépészmérnök vagyok, esetleg pontosabban dolgozom? Ki tudja.
De ami biztos: pillants fel a topic címére, aztán töprengjél még egy kicsit.
Jó nagy ökörség lett volna a SAP-ot assemblyben írni. Először is iszonyatosan drága lett volna. Gondolj bele, hogy ha csak 1 millió dollár volt a kifejlesztése (aminek valószínűleg a sokszorosa lehet), akkor ebből csináltunk volna 100 millió dollár költséget. Ha 5 millió dollár, akkor 500 milliót? Hol hozta volna be ezt? Sehol. Gyorsabb lenne? Talán, nem biztos. Drágább lenne? Sokkal-sokkal. Lenne esélye egy 20x drágább SAP-nak a mostanival szembe? Semmi az égadta világon, ki az a hülye, aki elfogadható sebességű szoftver és egy gyors szoftver közül azt választja, aki 20x annyiba kerül? Senki.
Mennyi ideje fejlesztik a SAP-ot? 30 éve!!! A világ negyedik legnagyobb szoftverfejlesztő cége, csak magyarországon 350-en dolgoznak nekik...
Azt gondolom tudod, hogy a SAP az csak egy keretrendszer, és az egyes cégekre testre kell szabni. Milyen iszonyatos költségeket jelentene, amikor assembly programozók garmadáját kellene felvenni egy ilyen fejlesztéshez/testreszabáshoz.
És ha még meg is van a szipi szupi x86 assemblyben megírt kódod, aztán jön, hogy bocsi, de nekünk Solaris van, fut rajta? Ja, nem? Akkor nem vesszük meg. Vagy mostanában történik egy nagy váltás intelről arm architektúrára. Jó esetben csak újra kell fordítani a kódot (ha egy része java-ban van, akkor azt sem). A te megoldásoddal újra kellene kódolni az egészet.
A szupergyors java kód kommentet sem értem, meg a GPU-n futást sem, ez teljesen érthetetlen.
Aztán még egy dolog. Lehet hogy van néhány szuper ügyes assembly programozó. Nagyon szép. Csak amikor nem néz balra, aztán elcsapja a villamos, akkor ott áll a projektvezető/cégtulajdonos, hogy honnan a szarból fogunk egy hasonlóan zseniális és assemblyhez értő embert találni.
Szóval az, hogy valami gyors, az csak egyetlen picike paraméter egy szoftvernek.
A nagy projektekhez. Nekünk van egy régebbi, nem túl nagy projektünk. 3-5 ember dolgozott rajta, most egy gyors metrika (java nyelven írva):
közel 5000 fájl
közel 1.2 millió sor
SLOC-P: 760 ezer
SLOC-L: 500 ezer
Deployment Solarisra: F5, enter. Deployment Linuxra: F5, enter. Deployment Windowsra: F5, enter. Ha arm platform lesz, valószínűleg ott is így fog történni.
Csak összehasonlításként egy linux kernel: 15 millió sor, 37000 fájl.
Nézzünk egy költségszámítást:
http://www.linuxfoundation.org/sites/main/files/publications/estimating…
1.3 milliárd dollárba kerülne a linux kernel 15 millió sora (6.7 millió SLOC) ha piaci alapon fejlesztetnénk. A SAP simán lehet akkora, mint a linux kernel.
Ez nagyjából meg is mutatja, miért nem fog soha senki assemblyben nagy - vagy akár csak közepes méretű kódot írni, piaci alapon.
Olyan egyformára sikeredett a három hozzászólás, hogy elég egyet válaszolnom. :)
"A szupergyors java kód kommentet sem értem, meg a GPU-n futást sem, ez teljesen érthetetlen."
http://www.hwsw.hu/hirek/51391/ibm-nvidia-gpu-power-tesla-szerver-bi-uz…
http://www.hwsw.hu/hirek/50993/ibm-java-gpu-gyorsitas-nvidia-hsa-projek…
Az utóbbiban megtaláltok a kommentelők között is. ;)
Az ASM <-> SAP egy irónikus poénkodás. Kb. olyan, mint amikor az ember ilyet mond: "Akorára dagadt a fejem mint egy ház". A ház 8m magas, a fejem meg ennél lényegesen kisebb és 1cm növekedést sem mutat, mégsem fogsz odarohanni egy mérőszalaggal bizonygatva, hogy műszakilag hülyeséget állítok.
A topic pont nem erről szól, de azért meg kell említenem egy tipikus és súlyos szemléletmódbeli tévedést: Nem a piacilag legsikeresebb termék a legjobb!
(Megvan a mondás a sok léggyel, szarral, meg hülyeséggel???)
Hány magos cpu kell egy tabletbe? Hát rózsaszín, mert a nők a szín alapján választanak!
Az első modern gyártósort feltaláló Ford is ebbe bukott bele, mert a nők piros meg zöld autókat szerettek volna.
Az asm-ről. Pontosan azért írtam le a korábbi példákat, hogy a fiatalabbak is megérthessék amit soha nem tapasztaltak: régen milyen szempontok miatt volt szükséges használni. Messzemenően nem arról beszéltem, hogy hülye aki ma nem asm-ben írja a rendszereket. Hanem arról, hogy aki kénytelen volt kihegyezni a programot ÉS meg is tudta tenni, az más környezetben is képes hatékonyabb kódot előállítani.
A programok magas sorszáma sem hatott meg teljesen. Láttam, dolgoztam ilyenben. A saját kódolásom többnyire nyolcada a hasonló kódoknak. Nem nő vagyok, nem kell rózsaszín tablet. Éppen ezért előfordult olyan, amikor 400.000 sor kódot helyettesítettem úgy 20 sorral.
- hamarabb elkészült
- kompatibilisebb volt
- kb. 20.000x gyorsabban futott
- nem kellet hozzá még egy-két gép és szoftver
- abszolút hordozható volt
- pontosan a feladatot oldotta meg, side effect nélkül
Ne általánosítsunk ilyenből, de itt azért két mezőt kellett kitöltenem és továbbítani a hálózaton.
Erre ma a tipikus megoldás Sun alkalmazásszerver és java. Mert az hordozható. Már ha elég izmos valaki. :)))))))))))))))))
A hordozhatóságról. Itt is volt olyan topic, ahol nemtudni miből kikeverték, hogy ellene vagyok a hordozhatóságnak, valamint nem is értem mi az. A rövidség kedvéért: nem és nem.
"A sebesség pici paraméter." Egy projektben szóvá tettem, hogy az adatbázissal nem jól dolgoznak (azért írom így, hogy kerüljem a részleteket). A srác bemutatott egy (windózos) tesztfuttatást, miközben a másik igen nagy (országos hírű, egyetemi tanár - adatbázisok) szakértő elmagyarázta, hogy az a sztoridzs olyan gyorsan működik, amit el sem tudok képzelni. Extrapoláltunk a valódi gépre és rekordszámra, így kijött 14 perc futásidő. A valós futásidő 11 óra lett, az előírás <1 óra volt. Én csak azért pofáztam bele, mert a kiváltandó rendszert 8 évig üzemeltettem, és a 12 tervező között is ott voltam. Kérdés?
Az adatbáziskezelő Oracle volt. A legjobb. :))) (Ezen most ne nyissunk topicot.)
A leglassabb rendszereket éppen ilyenben láttam. Tehát
- Ebből nem következik az adatbáziskezelő jósága vagy rosszsága.
- Nem következik, hogy milyen adatbáziskezelőt kellene alkalmazni.
- De következik, hogy a végeredmény enyhén szólva dilettancián nyugszik.
Ez csak a duma. Én magam gyakorlatlan vagyok az sql terén, de azt látom a jól megkomponált adatbázishoz éppolyan mély szakértelem kell, mint az alacsonyszintű programozáshoz. Nem véletlen, hogy a 20-30 programozó mellé 1-1 napra egy még nálam is öregebb fószert hívtak optimalizálni, mert kezdett megállni a rendszer. Az öreg spiller drága, de 1-1 napra kifizetve a projekt "költséghatékony". Üzletileg rendben van, az eredmény siralmas.
De legalább az sql szabványos, hordozható. Az MSSQL villámgyorsan fut egy AIX szerveren. Ki tudja, tán az F5 enter segít.
"a mérnöknek az a célja hogy gazdaságosan oldja meg a problémát" - Igen, ez a mai szemlélet hibája! Régen a mérnöknek a fő feladata a probléma megoldása volt, méghozzá gazdaságosan. Ha olvasod a híreket, néha-néha a megoldás elmarad. Viszont az gyorsan elkészül. :))))
Megtudhatjuk, ki volt az a tanar es melyik egyetemen? Opcionálisan privátban?
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Nem lenne korrekt.
Csak mert ismerek én is egy nagy Oracle hívőt, bár nem tudom mennyire "országosan ismert". Érdekelne, hogy nem-e véletlen ugyanaz.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Ha az adatbázisok tartalmához jogosulatlanul férnek hozzá, a háttérben általában nem műszaki okokat kell keresni.
Jó napom van.
A linux nem kerülne. Ki is fizeti több cég, többször is. Csak az első találat:
http://www.zdnet.com/ibm-and-linux-the-next-billion-dollars-7000020757/
Szóval az ilyeneket először le kéne vonni az okoskodásból.
Le a kalappal a munkásságod előtt, de az, hogy egy komolyabb üzleti szoftvert megírjunk / átírjunk asm -ben, C -ben, teljesen lehetetlen küldetés ebben az évezredben.
Mérnökileg sem indokolt, mert a mérnöknek az a célja hogy gazdaságosan oldja meg a problémát, ha nem gazdaságos akkor nem veszik meg tőle és nézhet más munka felé.
Ha most egy .NET / Java -ban is évekbe telhet egy-egy komplexebb projekt befejezése egy profi csapatnak, szerinted asm -ben / C-ben hány emberévezred kellhet hozzá?
--
http://developersideas.blogspot.hu/
http://neurogadget.com/
http://hup.hu/node/129089#comment-1677607
Ez nagyszerű, de ha mar SAP, es társai... Ha villanyvadasz szemlélettel próbálnál meg egy ügyviteli R ndszert fejlszteni, elvesznel. Itt nem az az elsődleges igény, hogy milyen gyorsan fut, hanem az, hogy ha kell valami, Mikorra van meg.
Kell pl egy lekérdezés, összerakni mondjuk 2 perctől 2 óra, de aznapra kell a kimutatás. Ott nem fog érdekelni senkit, hogy az 2 mp-ig vagy 2 percig futott.
Sokszor olcsóbb a vas, ez van.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
A lekérdezés hagyján, de ilyen rendszerekkel ma már a szó legszorosabb értelmében olyan jogszabályokat kell üzletvitelileg betarta(t)ni , amelyek tegnaptól hatályosak. Holnap meg még egyet csavarni a folyamaton, vagy cakkpakk vissza az egész.
http://hup.hu/node/129089#comment-1677607
latom, az ido elment melletted, te pedig elfelejtettel fejlodni vele.
Ha látod, nyilvánvalóan rokonságban lehetsz Uri Gellerrel.
Ezek technikatörténeti sztorik több mint 25 évvel ezelőttről.
És igazad van!
Én akkor is, most is en_US kiosztású billentyűzeten tudtam kis- és nagybetűket írni.
No, meg ékezetest is. DOS alatt, Windows alatt, linux alatt, terminálon.
Semmit nem fejlődtem!
Tudom, tudom, mobilról írok....csak nem tudod használni. EZ A FEJ-LŐ-DÉS!!! :))) :(((
latom, terelsz, mert elfogytak az erveid ;-)
sztorizgatas, persze, fent buszken verted a melled hogy mennyire nagy majer vagy a 20 eves technikaddal, amivel lenyomod a php pistikek ganyolt szarjait...
ekezetek meg nagybetut meg tudnek, csak nem nem erdekel, HTH
Persze, terelek. Ez a mai fiatalok másik problémája a szövegértés.
Elmagyarázom: Ott fönn azt írtam, hogy bizonyára látnok vagy, ha pár ősrégi sztoriból kitaláltad ma mit csinálok.
Elárulom, nem a php pistikéket, hanem a java bandikákat döngölöm a földbe.
Amit 25-30 éve megtanultam, azzal a tudással írok 10-20x gyorsabb programokat, amelyek a sebesség mellett 1000x kisebb terhelést okoznak. Ezt azért tudom megtenni, mert más a rendszer- és adatszemléletem, mint egy dzsaván nevelkedett titánnak.
A technika amit használok nem 20, hanem 45 éves. A logika meg az ókorból származik.
Mellékszál, de kíváncsi lennék, hogy a költői túlzásokat kigyomlálva a szövegedből
- valójában mennyit ér a régi, talán kissé elavult tudás
- mennyire vagy te magad hatékony
- lesz-e élő ember, aki szükség esetén bele tud nyúlni helyetted a kódodba
"lesz-e élő ember, aki szükség esetén bele tud nyúlni helyetted a kódodba
Es nem csak helyette, mellette. Mai skalazodo vilagban azt felejti el mindenki, hogy nemcsak a szoftvernek kell tudnia a vasra felskalazodnia, hanem a fejlesztocsapatra/cegre is, valamint költségekre.
Az a fejlesztő, aki meg a fejlesztés költségein es a karbantarthatosagot ignorálja, es csak a futási idot nézi, az nem feltétlen jo csapatjatekos es alkalmazott. Es egyebkent is, nem csak sebességre, de memoriahasznalatra is lehet optimalizálni. Van, hogy az a cel. (Es sokszor a ketto egymast uti). De a lényeg: azert nem fogok órákat, esetenként napokat elpocsolni mondjuk egy servicevel, hogy 10 helyett 5 mp alatt induljon, ha nem éri meg es az adja meg az erteket a szoftvernek, hogy X featuret tudja vagy sem. De erre jo pelda a webshop, amit fejlesztünk, uzemeltetnk. Kiszamoltuk, egyszeruen nem éri meg azon gorcsolnunk, hogy most mennyire hajtja meg a gepet, mert abból penz nem lesz, abbol viszont igen, hogy jobbak vagyunk-e, mint a konkurencia. Persze, neha ra kell szanni az időt es itt-ott visszanyesni es szándékosan szar kódot se írunk, de az idő eddig minket igazolt: elobb lett csereerett a gep, mintsem, hogy csúnyán belementunk volna a tartalékokba.
Az emberi részéhez meg egy -bar nem fejlesztokkel, de attol meg jo- pelda házon belülről: cegcsoportocskank bővült egy taggal, ugyanaz a rendszer, metodika lett bevezetve ott is, mint a masik ketto között. Maga a rendszer alapvetoen mukodik, sokat tud, persze vannak hibák, megoldandó új problemakorok es folyamatosan fejlesztünk. Jelenleg viszont az egyik legnagyobb akadályozó tényezőnek az tunik, hogy túl sokat tud a rendszer es nagyon nehezen tanulnak bele az új kollégák. Pedig ez nem egy sokezres multi.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™"
Persze, hogy igazad van. Szerencsémre olyan rendszereken dolgoztam, ahol nagy adattömeget kellett gyorsan feldolgozni. A gép adott volt, és éppen az egyik marha aláírt egy olyan szerződést, amihez 1 órán belül kellett volna futtatnunk. Éppen az előző nap készültem el azzal, hogy 26 óráról 6 órára vittem le a futásidőt. A cél csak annyi, hogy 24 órás perióduson belül üzemeltetni lehessen a rendszert. (Az elsőt NEM én készitettem:) A szerződés ott volt, vehetett volna a cég 60..90 ezer dollárba kerülő bővítést, amihez kellet volna írnom még egy működésképtelen másik programot. Erre nekiálltam és megoldottam ugyanazt kevesebb munkával 10 perc futásidővel.
Abban a szituációban ez volt a nyerő.
Ugyanezt a megoldást a török IBM is sikerrel tesztelte 2,5x akkora adatbázison. Csak ezek a törökök alkudni szeretnek, de vásárolni nem. :(
Jó, ilyen nálunk is van, csak nálunk általában úgy néz ki, hogy "oké, ez volt a terv, de ez kellene". Volt ilyen nálunk is, hogy volt egy éjjel futó PHP-s, SQL-es job, amire végül egy picit több adatot bíztak, mint amennyi az eredetileg tervezett volt, így az éjjel 4-kor induló job nem futott le reggel 8-ig. (Vége az lett, hogy átírtam C++-ra, így utána lefutott kb. 10 perc alatt. Mostanra ez kb. fél-háromnegyed óra.
De akkor az első esetben az egyszerűbb megoldás volt a nyertes. A C++-os megoldás már support időszakban született, 3 hét fejlesztési idő mellett. A másik volt kb. 4 nap. Lefordítva: kb. 2-2,5 héttel hamarább lehetett termelésbe állítani a rendszert.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
saxus: Feltettél egy kérdést. Megadtam két filtert. Megtaláltad a választ?
Igen, bocs, este félálomban már nem válaszoltam. Nem ugyanaz és köszönöm a választ.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Ha kíváncs vagy, szívesen megválaszolom.
Csak a költői túlzást nem értem.
Tréfás vagyok, bár a hülye humoromat sokan nem értik. De.
Ebben a topicban már írtam, műszaki adatokkal soha nem tréfálok. Hajlott korom miatt talán pontatlanul idézek dolgokat, de a jellege azért megmarad. :)
Tehát, ha azt írtam, hogy 1000x kevesebb a terhelés, akkor az nem olybá tűnt, hanem megmértem.
Pont.
Elavult tudás.
Nemrég kaptam meg: Ma az ilyen tudás eladhatatlan, ami eladható az a felületes tudás!
Az elavultat kiegészíteném az alapossal.
A fenti vélemény, - és nem tagadom, látom az igazát - pont olyantól hangzott el, aki mindenhez ért, de semmit nem tud.
Régi tudás.
Nemrég készítettem egy olyan rendszert, amelyik 80 windowsos komplex ügyviteli rendszer naplóit és adatbázis metéseit/tr logjait menti egy központi gépre. A fejlesztők 5-10 percen belül innen nézegethetik tetszőleges rendszer naplóit (tetszőleges szakaszt), tölthetik le a mentéseket.
A rendszer végesállapotú gép elven működik, teljesen automatikusan. Takarítja a beállított paraméterek alapján saját magát és a klienseit is. (Azaz a windows szervereket.)
Jelenleg 17.300.000 mentést kezel, tömörítve >2TB. Az adatlekérés azonnali. Egy vékony keresztmetszete van: az sql szerver, amibe egy-egy mentésről egy sort írok be.(Az ugye azért van, hogy php-ben jobban le tudd kérdezni, én a saját indexeimet használom.) Felügyelet nélkül működik, ha elmegy a villany utána crash opcióval kell újraindítani. Adatvesztés nincs.
Hasonló rendszereket írtam az elmúlt 20 évben, összesen kb. 17 példányt, a leghosszabb élettartamú 19 évig működöt. Persze, néha továbbfejlesztve. :)
A fenti rendszer hasonló technológiával készült, mint az a CDROM vezérlő, amit 1988-ban készítettem.
Hatékonyság.
Lassan, pontosan dolgozom. A fenti rendszer 7 hónap alatt készült el. Bár ebben közrejátszott, hogy a megrendelő nem teljesítette a saját részét, így a specifikálatlan formátumokat és folyamatokat is nekem kellett kitalálni. Egyik részlet: Kaptam egy 600kB méretű xml-t - ügyes gyerek vagy, kitalálod! Ebből készült egy 13 rövid sort tartalmazó tábla. :)
Másfél év alatt másfél bugot fogtam, azt is azért, mert valami marha beleírt az apache logjába.
Rendelkezésreállás.
De nem is ez volt a kérdés. "lesz-e élő ember..." No, ez jó kérdés! Valaki egyszer azt modta, tanult mindenféle szervezési, tervezési stb. módszert, de ha nem találod meg azt az embert, aki meg is tudja csináni akkor b.od.
Itt több részre szakadhat a téma.
- Sok esetben kellett szerződésekből, kormányrendeletekből dolgozni. Szinte dokumentáció sem kellett, hiszen a rendszer pontosan úgy működött, ahogy elvárták. Ha valaki programot sem tud írni, meg azt sem tudja mit kell csinálni - akkor ne nyúljon bele a kódba. Ellenkező esetben meg képes lesz rá. Többször nyúltak bele a rendszerembe - aztán rosszul működött. A folyamatot nem ismervén rosszkor rossz adatot vettek ki.
- Az emlegetett rendszereknek nincs "felhasználói" csak üzemeltetői dokumentációja. Abban szerepel a paraméterezhetőség, meg az is: "A rendszer működése a továbbiakban automatikus."
Négy nagy rendszeremre az utolsó két évben nem volt support hívásom.
- Megesett, hogy egyedül dolgoztam három cég csapatával közösen. A csapatok egy-egy töredékrendszert készítettek, én hármat. Gondolom üzletileg ésszerűbb lett volna, ha helyettem még három céget alkalmaznak. Persze ilyen esetben még én is kellettem volna, hogy konztultáljak ezekkel a csapatokkal. Szóval a megrendelőnek esze ágában sem volt mást alkalmazni.
- Egyszer így dícsértek: Ami nem elég egyszerű, az már neked nem is jó.
Szóval buta vagyok és félénk. A szoftver és a rendszer úgy készül nálam, mint a hardver. Apró részáramköröket készítek, kipróbálom, belövöm. Aztán hirtelen összerakom, esetleg olyan bonyolultsággal, amit a mai jó szakemberek nem mindig tudnak követni. Pedig ők azonnal láttak az egész rendszer és a megoldást is. :) Ne kritizáld, mert ezekben az esetekben a szükséges folyamatok megvalósításához így kellett megoldani a feladatot. Aki másképp tette, annak nem sikerült.
Ami igaz, sajnos ez a tudás manapság nem adható el. :(
"mert 20 millió soros táblákból joinol össze 5-öt (!), hogy megszerezzen olyan adatokat, amikből 10x annyi van táblánként, mint amennyi a tényleges adat lenne 1 táblában."
Az igen ritka eset, hogy a tárolt adatokról hosszú távon az derül ki, hogy túl sok; az se gyakori (de megtörténik), hogy az derül ki, hogy a táblák "túl" vannak normalizálva; az viszont kifejezetten jellemző, hogy a fejlesztő (és a tanára) a tanuláskor apróbetűs résznek (a.m.: ugord át, bammeg, mert a lényegesre is szűk az idő) vette az indexeket, Pascalban/C-ben/mittoménmiben még írnia is kellett ilyesmit, de az adatbáziskezelés tantárgy 500 rekordos vizsgapéldáján végleg bebizonyosodott, hogy felesleges sznobéria az egész - a db admin (vagy az a szerencsétlen, akit arra a posztra kisorsoltak) meg vagy képes analizálni, hogy hol hiányzik index, vagy nem.
Ahol az említett aggályos részek nem állnak fenn, ott mindegy, hogy 20 vagy 20 milliós táblákból kapcsolják össze azt az 5-öt.
Éppen nemrég derítettünk fel egy "lassúak a lekérdezések" bugot. Igen, egy darab index nem volt.
--
http://developersideas.blogspot.hu/
http://neurogadget.com/
Nem tudok egyetérteni. Kifejezetten szerettem annak idején a prog. 1-2 tárgyakat, meg az algelt is. Ugyan nem ma volt, de - kis túlzással - ha hajnali háromkor kitrombitálsz az ágyból, akkor is lekódolom neked C-ben bármelyik ott tanult lista- vagy fakezelő eljárást, rendezést. Igaz engem mindig is érdekeltek az "alacsony szintű" dolgok, ezért aztán a ZH meg a vizsga túlélése helyett a megértésre hajtottam.
A munkámhoz most épp nincs szükségem semmi ilyesmire, de a hobbi szintű Atmegás meg FPGA-s matatás közben nagyon hasznos tud lenni, hogy a tanult algoritmusokhoz hasonló problémák megoldása során van honnan ötleteket merítenem. A fene se tudja, lehet egyszer még olyan melóm lesz, ahol szintén tudok majd velük mit kezdeni.
Talán a szoftverfejlesztőknek sem teljesen felesleges. Nekem is van olyan gányolós ismerősöm, aki úgy használja pl. a Java adatsrutktúrákat, hogy halvány fogalma sincs róla, hogy néz ki a megvalósításuk. Így aztán nem is túl gyakran sikerül kiválasztania az optimálisat.
Nálunk a TVben nemrég lett lecserélve a feliratozó szoftver egy újabbra a digitális+HD átállás miatt. És hát voltak érdekes dolgok.
A régi feliratozó gép egy Core2Duo gép volt benne egy Decklink SDI kártyával ami tudja a HD-t.
A programot megkaptuk próbára aztán jött a döbbenet: Az egér úgy akadozott mintha egy 10+ éves gépen futtatnék egy mai játékot és még egy szerencsétlen szöveget sem tettünk ki 'adásba'. Üresjáratban gyakorlatilag felfalta a fél gépet. A Decklink kártya meg nem akarta kulcsolni a feliratot. Felhívtuk a fejlesztő céget. Mondták, hogy 'oda már i7-es gép kell meg egy Decklink 4k Extreme kártya'.
Megvettük a cuccot, elküldék az új Decklink kártyát is, és jött a pofáraesés: Kék halál!
Megint telefon. válasz: '...de mi kék halált nem tudunk csinálni.' Rá egy héttel már ők hívtak, hogy valóban gondok vannak, mert az Asus lapok nem kompatibilisek azzal, vegyünk MSI-t. Itt már biztosra mentem, megkérdeztem, hogy pontosan milyen alaplapjuk van nekik a referencia gépben és akkor olyat veszek.
Megvettem, kékhalál, telefon: 'válasz: ...hááát, lehet, hogy a kártya lesz a szar mert ezzel a típussal most már nálunk is kékhalál van, de egy eggyel régebbi kártyával jó lesz.' Érdekes, eddig jó volt náluk azzal most meg hirtelen nem? A régebbi SDI kártya pedig már kifutó széria - de nagy nehezen beszerezték.
Betettük. Öröm és boldogság, sikerült kitenni a feliratot! De azért 15-20 percenként még mindig befigyelt a kékhalál. Üresjáratban pedig még mindig ott volt a 10-15% CPU terhelés az új gépen.
Egyébként a régi Decklink SDI kártya vígan megy HD-ban a feliratozónál jóval gyengébb képújságos gépben.
A Régi Darim FS1000 adáslebonyolító is érdekes. .NET keretrendszer kell neki, és a vártnak megfelelően lomha. De legalább az tette a dolgát és nem fagyott. Új Darim FS4000, erősebb gép -> már nem annyira lomha.
Tehát nem tudom, hogy a mostani fejlesztők miket varázsolnak össze, de ez így nagyon nincs rendjén.
-------------------
http://www.rtvstat.hu/ - A legtöbb magyar rádió és TV egy helyen!
A .NET-ről jut eszembe, viszonylag friss tapasztalat. Egy villamosmérnök barátom a szakdolgozatához egy "valós idejű" adatmegjelenítő programot (értsd: statikus késleltetés nem érdekes, de amennyi adat egységnyi idő alatt beesik, az egységnyi idő alatt jelenjen is meg) írt, abban segítettem neki. A .net-re esett a választás, guinak windows forms, mert abban tényleg csak összedobálod a guit a builderrel, aláteszed a logikát és kész vagy (még egyszer mondom, villamosmérnök). Az én segítségem a logikai részben merült ki, vagyis hogy hogyan hozzuk össze a bejövő adatot a guival.
Bevallom őszintén, az első megoldásom bár működött, de nem hozta a követelményt. Ugyanis mivel az adatokat fogadó szálból nem lehet közvetlenül metódust hívni a gui szálon, bevezettünk egy delegate-et, hogy lehessen indirekt módon. Ez persze ahogy kell jó lassú lett.
Aztán végiggondoltam, hogy az adatokat be lehetne pakolni egy szálbiztos collectionbe is, amit a gui szál tud olvasni. Ez a megoldás már hozta a követelményeket, ráadásul a kód rövidebb és érthetőbb is lett.
Nyilván a jó megoldás eszembe juthatott volna elsőre is, csak amikor arra koncentrálsz, hogy tökmindegy hogyan, csak jelenjen meg valami, akkor a ronda megoldás is elfogadhatónak tűnik. Ha pedig nem sikerül elég rosszul, nagy az esély arra, hogy haladsz tovább a feladataiddal, és a kód csak évek múlva kezd el problémákat okozni.
Manapság 1kg búza megtermeléséhez sokkal több energiát használnak mint 200 éve.
Bezzeg a régi parasztok, azok tudtak! Igaz, hogy egy hétig izadtak azzal amit ma egy kombájnosnak pár perc, de akkor még volt tisztelete az emberi munkának, nem ám ez a pazarló automatizmus!
Hozzáértés volt, nem csak a gázpedált nyomták agyatlanul!
És mi fejlődött kérdem én: ugyanolyan búzát eszünk ma is! Az energiát meg öntjük ki a kukába?
A kompetens jobbágyok hiánya miatt, azér!
"ugyanolyan búzát eszünk ma is!" off, de tudtommal a búzát időközben nemesítették, ezért nagyon nem ugyanolyan, mint 200 éve. Lehet ezekről olvasni a neten "modern wheat gluten" keresőszavakkal.
subscribe
----------
Linux Akadémia oktatóvideók: https://facebook.antavo.com/DUc/C/?oid=FC
Sok érdekes felvetés született, nagy részük a legtöbb esetben valóban megállja a helyét, úgy mint nagyobb igények, több feladat, kevesebb fejlesztési idő, több, de kevésbé tehetséges fejlesztők, stb.
Viszont amit nem nagyon láttam megemlítve, de szerintem fontos dolog, az az absztrakciós rétegek számának drasztikus növekedése. Mivel mind a feladatok, mind a programok környezete, amiben futnak egyre komplexebbek, ezért ahhoz, hogy a fejlesztési időt és ráfordítást adott szinten lehessen tartani, szükség van rájuk. De minden réteg plusz overheadet jelent, vagyis elvesző teljesítményt. Pl. egy ilyen manapság istenített absztrakció a web. Mindenki mindent a webre akar kipakolni, és nem is ok nélkül, mert webre fejleszteni olcsó, nagyjából multiplatform, deployment egyszerű, jól skálázható, stb. De ennek megvan az ára, amit a kliensekkel fizettetnek meg, mert a böngésző fogyaszt egyre több erőforrást.
"az absztrakciós rétegek számának drasztikus növekedése. Mivel mind a feladatok, mind a programok környezete, amiben futnak egyre komplexebbek, ezért ahhoz, hogy a fejlesztési időt és ráfordítást adott szinten lehessen tartani, szükség van rájuk."
Szerintem az újabb és újabb absztrakciós rétegekre valójában csak azért van szükségünk, mert az meglévők rosszul vannak megtervezve. Vagy nem elég platformfüggetlen, vagy nincs automatikus szemétgyűjtés, vagy nincsen rendesen befejezve. Erre valaki fogja magát, hogy majd ő megoldja, és rátesz plusz egy réteget. Mivel az oprendszerek nem oldják meg a programok szeparálását tisztességesen, ezért kellenek a virtuális gépek. Másik oldalról, a programok előszeretettel függenek oprendszerszintű beállításoktól, ezért is kellenek a virtuális gépek. C/C++-ban nem lehet (nem egyszerű) platformfüggetlenül fejleszteni, pláne sandboxban telepítés nélkül futtatni, ezért kell a web. A web megvalósítása viszont diverz, ezért kellenek rá a Javascript keretrendszerek.
Amúgy az absztrakciós réteggel nem csak az a baj, hogy önmagában lassít (egy keveset számít, de ez még simán beleférne), hanem az, hogy a programozók nem értik a végén már, hogy valójában mi fut, és ezért nem tudnak optimalizálni. Például a Javát szokták emlegetni, hogy milyen lassú. Meglepően gyors programokat lehet benne írni, ha valaki odafigyel, és érti is, hogy mit csinál. De ettől még a Java fejlesztők jelentős része gány dolgokat csinál, és ez visszaüt magára a nyelvre.