November 5-e Clang-nap a FreeBSD-nél

FreeBSD

Brooks Davis (brooks@) ma bejelentette a freebsd-current levelezési listán, hogy november 5-e Clang-nap lesz a FreeBSD-nél. Ez azt jelenti, hogy hétfőn commitolni fogja azt a patchet, amely alapértelmezett fordítóvá teszi i386 és amd64 architektúrákon egyaránt a Clang-ot. A legtöbb felhasználó számára a változtatásnak teljes mértékben észlelhetetlen kell(ene) lennie. Másoknak lehetnek kisebb problémákba még belefuthatnak, de a fejlesztők úgy gondolják a komolyabb hibák nagy részét sikerült már orvosolniuk. Ettől függetlenül vannak azért még ismert hibák:

  • Nem minden port fordul le Clang-gel. Ez a probléma megkerülhető azzal, hogy az egyes portoknál a felhasználó beállítja a "USE_GCC=any"-t. Ezzel a gcc kerül felhasználásra. Attól függően, hogy a dolgok hogyan alakulnak, a fejlesztők lehetséges, hogy a "USE_GCC=any"-t alapértelmezetté teszik egy időre.
  • Nem fut le hibátlanul az összes libm teszt.
  • Kicsi, de észlelhető lassulás bizonyos benchmarkokban. Például sysbench/MySQL tesztben 1%-nyi lassulás tapasztalható Clang-gel fordított kernel+world esetén.

A bejelentés elolvasható itt.

( jevgenyij | 2012. 11. 02., p – 12:45 )

Kicsit sárgább, kicsit lassúbb, néha le se fordul, de a mienk! :-)

Nyilvánvalóan nem tehetnek sem a FreeBSD sem a Gentoo fejlesztői, karbantartói arról hogy tőlük független programozók milyen kódot írnak. Az viszont az ő felelősségük, mi került a ports-ba illetve portage-ba és azt is, hogy használható-e az adott szoftverkörnyezetben. Ennek nyilván kiemelt eleme a default fordító.
Ha valamilyen kód nem fordul le egy adott fordítóval akkor dobják ki és ha nélkülözhetetlen írjanak helyette másikat. Ha nem ezt választják akkor kezelje a ports a helyzetet, ahogy a Gentoo-nal kezeli a portage. Ha szerinted teljesen normális, hogy holnaptól default beállításokkal nem fordulnak le ports-ban csomagok akkor nincs miről vitatkoznunk.

Vajon mi a francert siklasz at sokadszor azon az apro infon, hogy mindez a fejlesztoi agban tortenik? Aki azt hasznalja, annak altalaban nem okoz problemat, hogy egy nem fordulo port-nal hogy a szarban is kellene visszaallni gcc-4.2.1-re - ami valtozatlanul elerheto FreeBSD alatt - csak mar nem az az alapertelmezes.
Azaz hogy egyertelmu legyen: annak aki a tamogatott 8-as vagy 9-es agakat hasznalja, annak annyi a valtozas, hogy folyamatosan esnek be portokhoz olyan peccsek, amiknek hatasara - ha akarna- fordithatna clang-gal is. (Vagy olyanok, amelyek ezt explicit modon letiltjak.) Tehat holnaptol is fognak fordulni a portbeli dolgok a default forditoval.

No latod, pontosan ez a folyamat zajlik most a FreeBSD-n. Mivel ok at akarnak allni GCC-4.2.1-rol LLVM+Clang-ra, ezert tettek par lepest. Aminek az egyik resze, hogy meg kell talalni azokat a programokat, amelyek valamiert ezzel az uj forditoval nem lehet forditani. Jelenleg (clang elotti) FreeBSD-n is van olyan port, aminek nem jo a fent emlitett rendszer-gcc, igy sajat igenye van. Most ezek az igenyek egy kicsit tobben lettek, mert vannak olyan programok, amelyeknek a fejlesztoi akarva-akaratlanul ugy irtak meg a kodot, hogy clanggal az nem (vagy nem jol) fordul. Folyik az atallas. Mit ad isten, a fejlesztoi agban. Hol itt a gond?

Tudod te, mi az a FreeBSD ports? Az a nem FreeBSD altal fejlesztett, de a FreeBSD-sek szamara is elerheto szoftverek gyujtemenye. Amit a FreeBSD-sek fejlesztenek, az a FreeBSD maga. Mert ok nem csak kernelt hackelnek, hanem egy komplett OS-t.
A portsban erheto el minden mas. Ha a portsban valami szar, az nem a FreeBSD-sek hibaja. Ok nem felelnek erte.

"Ha a portsban valami szar, az nem a FreeBSD-sek hibaja. Ok nem felelnek erte."

Ezzel a résszel nem teljesen értek egyet. Ha valami szar a ports-ban, akkor ki kell venni belőle. Ha benne van, akkor működjön. Természetesen azért nem felelnek, amit egy x programozó készít. Azért igen, hogy azt a ports részévé teszik-e vagy sem.

--
trey @ gépház

Erdekes dolgokat lehet errol olvasni. Pl. a VirtualBox hasznal olyan GCC-extesion-t, amivel - ha jol olvastam - nem csak a Clang nem tud mit kezdeni, de a Gcc-4.7-tel is bajaik vannak a FreeBSD portereknek. Szoval ez azert nem annyira az o hibajuk. Amugy meg nyilvan ha a development agban (mert ugye FreeBSD-0-rol beszelunk, ami nem igazan eles rendszerre szant verzio) valamikor meglepik ezt a gcc->clang lepest, akkor egy fokkal konnyebb lesz tesztelni, mintha meg ezzel is kulon bohockodnia kellene annak, aki segiteni akar. Aki Debian unstale-t hasznal, az tudja miert teszi. Itt ugyanez a helyzet.

Nem a 'miértet' illettem kritikával hanem az elsietett kivitelezést. Azt sem tartom érvnek, hogy a ports nem része szorosan a FreeBSD rendszernek. OSX-nél ez igaz lenne, az OSX rendszerek kevesebb mint 1%-nál lehet fent a macports és onnan telepített programok. FreeBSD-nél ez 99% felett van.

Ne zavarjon, hogy (AFAIK) az egesz valtas azert indult meg, mert a GCC atallt GPLv3-ra, es ennek folyomanyakent nem szallithatjak alapbol az ujabb verziokat.

Az se zavarjon, hogy az Apple is eleg kemenyen tolja az llvm+clang-ot.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

A GPLv3 külön pontban megtiltja az így licencelt kódok FreeBSD-ben való használatát??
Remek dolog, hogy az Apple támogatja (és 'keményen tolja' bármit is jelentsen ez) az llvm és clang fejlesztéseket. De mi köze ehhez a FreeBSD-nek? Csak nem vette meg őket az Apple? :-)

Az is ideologia lenne, ha azt mondana a FreeBSD, hogy csak GCC-vel fordit.
Itt nem ideologiai problema van, hanem programozoi. Aki ugy ir kodot, hogy az csak es kizarolag egy forditoval fordul le, az magara vessen.
Pont mi, programozok vagyunk felelosok a sajat szakmankert. Alkotunk nemzetkozi szabvanyokat, es pont sajat magunk nem tartjuk be. Elegge hiteltelenek vagyunk mernokkent mondjuk egy gepeszmernok, vagy epiteszmernok szemeben.

A fehérember kultúrájának fontos eleme az önostorozás, amit soha nem találtam szimpatikusnak. Olyan is van ám, hogy határidő, és a nyílt forrású munkáknál is egyre kevésbé fogadható el a "kiadjuk majd ha valamikor elkészülünk vele" hozzáállás. Ezzel együtt is még mindig jobb minőségűnek tekinthetőek a nyílt forrású kódok.

"Aki ugy ir kodot, hogy az csak es kizarolag egy forditoval fordul le, az magara vessen."
A gondolatmenetet folytatva: az is vessen magára aki olyan rendszert használ, aminek a fejlesztői és karbantartói tesznek arra lefordulnak-e a csomagjai. :-)

1. Tudom, en is programozokent dolgozom. De ha mar az epiteszmernokos analogiaval elunk, ez olyan, mint ha azt mondanad mondjuk Kohalmi Zoltannak, hogy te figyi, tervezzel legyszives jovo csutortokre egy komplett csaladi hazat. Ez a hatarido.
O ezt nem teheti meg, amig bizonyos szabvanyokat be nem tart, addig a terve nem minosul epiteszmernoki tervnek, nem irhatjak ala es nem lehet az alapjan epiteni. Ez jogszabalyban van lefektetve.
Persze rank ilyen torvenyek nem vonatkoznak, pedig elegge komoly hibakat tudunk mi is csinalni. En javitottam ki olyan kodot, ami a javitas 4 evig pontatlanul szamolta bizonyos penzugyi termekek ertekeit.
Vagy eleg csak belegondolni, hogy augusztusban a Knight Capitalnak $400 millioba kerult egy szoftverhiba.

"Ezzel együtt is még mindig jobb minőségűnek tekinthetőek a nyílt forrású kódok."
Erre van barmifele merced? Mind a nyilt, mind a zart forrasu szoftverek altalaban pocsekak.

2. En nem is hasznalok ilyen rendszert.

"Aki ugy ir kodot, hogy az csak es kizarolag egy forditoval fordul le, az magara vessen." -- ezt én sem értem: miért ne írhatnék olyan kódot (ráadásul ingyen, szabadidőmben), amiről megmondom, hogy csakis egy bizonyos fordítóval fordul le (ezzel fordítottam, ezzel teszteltem).

Fuszenecker_Róbert

Mert egy programozasi nyelv szemantikaja jobb esetben nem forditofuggo.
Persze a C nem ilyen, ezert nem is igazan jo nyelv.
Ha megnezel komoly C coding standardeket, mindenhol le van irva, hogy forditofuggo dolgot ne hasznaljunk a kodban, a nyelv hibaja, hogy egyaltalan letezik forditofuggo kod.
Azert nem csinalunk ilyet, mert nem mernoki megoldas. Mintha azt mondana egy epiteszmernok, hogy tessek, megtervezem a hazadat, de olyan a tervrajz, hogy csak az XYZ Kft. tudja megepiteni, mas nem erti meg a tervrajzot.

De ez nem jó érv. Ha csinálok magamnak valamit, miért nem csinálhatnám úgy, ahogy akarom (ha ez jogszabályba nem ütközik).
Ha a munkám gyümölcsét megosztom, ingyen, akkor miért kéri rajtam számon valaki, hogy szabványos-e vagy nem.
Ha otthonra készítek egy csavart, miért kellene annak 4-esnek vagy 6-osnak lennie? Miért nem lehet 3,1415 mm-es? Ha azt odaadom másnak, megmondom neki, hogy tudja. Ennek megfelelően ő vagy elfogadja, vagy visszaadja, de morogni ne morogjon érte.

Fuszenecker_Róbert

Például azért mert ha már csinálsz valamit akkor csináld jól. Főleg ha szakmai referenciának is szeretnéd használni. Persze, garanciát nem kell rá vállalni, de azért minimum illene igyekezni, hogy jó legyen.

"Ha azt odaadom másnak, megmondom neki, hogy tudja."
Na ez általában hiányzik.

Ha nem szeretném, hogy felrobbanjon a csavar, elmegyek a csavarboltba, veszek egy megfelelő csavart egy megfelelő gyártótól. Ha túl gyorsan tekerem, és felrobban, akkor elmegyek a céghez, és morgok velük erősen.

Egy ideig engem is idegesítettek a nem jól megírt szoftverek. De belenyugodtam: ennyi pénzért ez jár.
Ha professzionális célra kell egy szoftver, megveszem. Így megszerzem a jogot arra, hogy morogjak a gyártóval.
A módszer bevált, általában rendkívül segítőkészek, ők is pénzből élnek.

Lehet morogni a gcc vagy a clang szabvány-nem-követésén, de ezek ingyenes (és open source) szoftverek. Ennyi pénzért ez jár. Lehet venni bolti fordítót. Lehet, hogy az sem jobb, de van jogalapja a morgolódásnak.

És bizony nagyon igaz: fekáliából nem lehet erődítményt emelni.

Fuszenecker_Róbert

A csavarbolt viszont tönkremegy amíg a robbanó csavarokat ingyen osztogatják az utcán. :)

Persze, nem érdemes sokat szenvedni azon ha egy ingyenes szoftver nem úgy működik mint kéne, de ha minimális munkával eleve lehetett volna erre figyelni, akkor hülyeség hibás szoftvert kiadni. Ha open source cuccot csinálok, azt is szeretném ha használnák.

"Egy ideig engem is idegesítettek a nem jól megírt szoftverek. De belenyugodtam: ennyi pénzért ez jár."

Csodálkozol, hogy egy trágyadomb az IT?

(Btw. hagyjuk már az ingyenes/nem ingyenes morgást, legtöbb sw fejlesztőjét keményen megfizetik azért, hogy azt az "ingyenes" szoftvert összetalicskázza.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Na persze, mert üzemeltetés terén mindig minden tökéletes, mindenhol van backup rendesen, mindenhol mindent tesztelnek, mindig van vészterv, mindig a nagykönyvben előírt szabványos utat használják, sosem tákolnak semmiféle workaroundot.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"Csodálkozol, hogy egy trágyadomb az IT?" -- Nem. Én választottam. Eredetileg villamosmérnök vagyok. De az IT ilyen, és elfogadom. Van az a pénz, amiért értek hozzá.

"hagyjuk már az ingyenes/nem ingyenes morgást" -- Pedig ez egy kardinális dolog. Lehet, hogy a fejlesztőt megfizetik, de ez mit sem változtat azon, hogy a felhasználó ingyen kapta meg. Így a felhasználó eldöntheti, hogy kell-e neki, vagy keres egy másik megoldást.

Fuszenecker_Róbert

"Csodálkozol, hogy egy trágyadomb az IT?" -- Nem. Én választottam. Eredetileg villamosmérnök vagyok. De az IT ilyen, és elfogadom.

...es ez egy nagyon nagy hiba. Nem lenne kotelezo tragyadombnak lennie, mi tesszuk azza, pont az ilyen hozzaallassal. Az sem szempont, h ingyenes vagy sem. A szar az szar, barhogy polirozzuk, vagy tesszuk ra az "ingyenvankussolja'csinaljjobbat" matricat.

---
pontscho / fresh!mindworkz

Rendben. Akkor mondjátok meg, mit kell csinálnunk. Mert eddig nemigen mondott senki konstruktív dolgot.

Vezessük be azt, hogy minden szabvány legyen kötelező. De akkor minden legyen specifikálva, mindenből legyen referencia-implementáció. Minden dokumentáció legyen pontos, minden API legyen nyílt. Minden bugot kötelezően javítsunk ki, minden problémára legyen egy és csakis egy megoldás. Sőt, legyen mindenki egyforma.
És mindent fizessen ki a főnökünk és rajta keresztül a megrendelő. Ha pedig ők nem fizetik ki, akkor ne menjünk haza a feleségünkhöz, hanem ingyen dolgozva javítsunk meg mindent éjszaka.

Morogni én is tudok.
Várom a világmegváltó javaslatokat.

Fuszenecker_Róbert

Az esetek tobbsegeben a problema alapja az, h egy tetu az az egyed amely az adott szoftver modult elkesziti. Mindegy, h nyilt vagy zart, nincs kulonbseg.

Lehet par dolgot tenni:
- szabvanykoveto munka,
- normalis, effektiv QA,
- megfelelo hozzaallas.

A legnagyobb problema a legutolso lepessel van, mert az elso ketto adna magat, ha ez utobbival nem lennenek ordas nagy gondok ebben a szakmaban. Jellemzo az, h a T. munkavallalao a beleszaras allapota miatt olyan munkat ad ki a kezebol, h en kerek elnezest miatta. Ezen siman lehetne javitani a kotelezo code review-val, a kollegak oktatasaval es a normalis munkamenet megszervezesevel, de a T. munkaadok ebbe nem olnek egy garast sem, mert draga. Kiveve ahol mar rajottek, h rovid tavon valoban dragabb, de hosszutavon mar boven kifizetodik. Pl. nem eg szenne egy bemutaton. Nalunk a velem dolgozo kollegaktol bizony megkovetelem (hala isten nem kell erolkodni, ertelmileg erett allapotu egyedek jarnak errefele) bizonyos szabalyok betartasat.

Ha valaki (mindegy, h nyilt v. zart) fos munkat vegez, vissza kell dobni, oldja meg szebben jobban, vagy huzzon vissza a balettba ugralni.

---
pontscho / fresh!mindworkz

Ez működik egy profitorientált cégnél, ott megköveteli a piac (előbb-utóbb), de ez hogyan segít a gcc szabványkövetési problémáján? Hogyan kényszeríted a {gcc fejlesztő}csapatra az akaratodat? Vagy nem használod a terméküket, vagy jobbat csinálsz, mint a clang-esek.

Fuszenecker_Róbert

Mert ilyet mérnökember nem csinál. Te szeretnéd, hogy mondjuk olyan eszközt vehetsz csak meg egy bizonyos gyártónál, ami 315 V-os, 40Hz-es váltakozó feszültséggel tud működni (azaz nem kompatibilis a mindenki más által használt hálózattal)?

Vagy vennél egy olyan eszközt, amit a tervezője szándékosan úgy alkotott meg, hogy nem jó az érintésvédelme?

Vagy mit szólnál ahhoz, hogy megtanulsz egy autón vezetni, aztán ha átülsz egy másikba, nem ér semmit a tudásod?

Az is borzalmas, hogy 2012-ben jutottunk el oda, hogy a mobiltelefonoknak szabványos töltőcsatlakozása van. Szép lenne, ha például minden mosógép másféle villásdugóval jönne és nem tudnál a hálózathoz csatlakoztatni. Pedig egy okostelefon általában drágább, mint egy mosógép.
Ha van közmegegyezés arról, hogy milyen módon oldunk meg egy adott műszaki problémát, akkor azt betartják a szakemberek.
Ha nem, akkor nem szakemberek. Jani bácsi is tud hátul a sufniban tákolni magának ezt-azt, de az olyan is.
A C programozási nyelv esetén is van ilyen közmegegyezés, szabványnak hívják. Ha eltérsz tőle, akkor olyan leszel, mint a sufniban tákolós Jani bácsi. Sajnos a szakmánkban sokkal több a Jani bácsi, mint kellene.

Szakadj már el a GCC-től.

"ha nekem pont egy nem-szabványos megoldás kell?"

Mire kell neked nem szabványos megoldás? Formátumok erre tökéletes példák: normális helyen megtaposnák az embert azért, amiért plusz munkát okoz. Ugyanígy plusz szívatást okoz nekem az, hogy egyesek szerint a CSV így, mások szerint úgy néz ki. Vagy említhetném még azt, amikor RSS-ből kellett olvasnom adatot és akik kódolták az RSS forrást, azok szartak ilyen apróságra, hogy 1-2 dolgot ki kellene escapelni RSS-ben. "Mert más RSS olvasó megeszi". Igen, csak egy XML parser nem ette...

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Az senkit nem érdekel, hogy otthon mit csinálsz. De amikor mások számára készítesz szoftvert (akár nyílt forrásút, akár nem) és publikálod, akkor már számít.

Az egész topikban arról van szó, amikor MÁSOK számára csinálsz valamit, akár a munkád része, akár nem.
De amikor otthon gányolsz magadnak egy Trabant motorral hajtott kistraktort, attól nem leszel autóipari gépészmérnök.
Ugyanígy, ha otthon sikerült egy tyúklétrával szeparált CSV-t beolvasó-kiíró-feldolgozó programot csinálnod, ami abban az egy helyzetben, ahol te használod, működik, még nem leszel szoftverfejlesztő.

Csak sok FLOSS és nem FLOSS fejlesztő azt hiszi, hogy nyugodtan készíthet élesben is olyan minőségű kódot, ami olyan, mint a háztáji kistraktor. Hiszen ha otthon működik, akkor az mindenkinek működni fog, különösen az ügyfélnek.
Na nem. Amikor munkáról és szakemberségről van szó, ott kendácsolásnak nem igazán lenne helye.

Egyszeru. Ha tomegesen valtanak gcc-rol a nepek mas compilerre, mert a termekuk egy hulladek, akkor elobb utobb el fognak gondolkodni azon, h a modelljuk nem megfelelo. Ez jelen esetben is megtortent, pl. a gcc48-ba rengeteg modosita kerult be a clang hatasara.

---
pontscho / fresh!mindworkz

Egy bizonyos, tényleg mérnöki szakmában, ahol emberélet múlik a dolgokon, NEM tervezhet házat az, akinek nincs erre képesítése. Hiába végzett el 5 év egyetemet (vagy hatot), hiába tanult meg mindent, ha nincs meg róla a képesítése, nem tervezhet házat. Mert a tervezés felelősséggel jár. Nem nagyon látsz open-source alaprajzokat. És ez nem véletlenül van így. Az a szakma megtanulta, hogy emberéletek múlnak azon, ha valamit elrontanak. Összedől egy épület, egy híd - nem játék. Nem hiába bünteti (és értelmezi) a törvény az illegális építést.
Egy építészmérnök ugyanolyan alapossággal tervez meg egy lakóházat, mint egy pajtát. Mert így kell csinálni, ez a szakma. A kreativitásukat nem abban élik meg, hogy megpróbálják minél jobban kijátszani a szabályokat. Van, amit mindenkinek be kell tartania.

Viszont a szoftverfejlesztő szakma nem igazán fogta fel, hogy a mi munkánkon is emberéletek múlhatnak.
Ezen a szakmán belül ennek a dolognak a megközelítése egyáltalán nem egységes. Az igazi mission critical rendszerek írói nagyon is jól tudják, hogy itt komoly dologról van szó.
Amúgy jó példa, hogy a Space Shuttle szoftverének írói ( egy nagyon jó cikk a működésről: http://www.fastcompany.com/28121/they-write-right-stuff ) így fejezik ezt ki: "the group understands the stakes: If the software isn't perfect, some of the people we go to meetings with might die."
Persze a webpistikék ezt nem fogják fel, és ez a fajta hozzáállás az, ami ezt a szakmát szennyezi. Ha jó volt a Himiumi Bt. weboldalán egy kis bug, akkor az elfér máshol is.

Igen, el kell ismerni, szoftvert írni nehéz. Több okból is. Egyrészt mert itt tényleg nem igazán vannak korlátok, teljesen absztrakt a dolog, azt csinálsz, amit akarsz, nem igazán vannak fizikai korlátaid, mert a szoftver nem egy fizikailag létező valami.

Azért is nehéz szoftvert írni, mert nem igazán van benne gyakorlatunk. Ez egy 50 éves szakma. Nem alakult ki konszenzus azzal kapcsolatban, mi az amit lehet, mi az amit nem szabad csinálni.
Tudod, "Goto considered harmful", de aztán használják bőven, és közben megmondják: "jó az a goto, de okosan kell használni".
Na, az ilyen kijelentések művésziek inkább, mint mérnökiek.
Az építészmérnökök nem az ember okosságára meg a jó szerencsére bízzák az épület stabilitását. Pont ez a lényege a szabványoknak, szabályoknak: a lehető legteljesebb mértékben kezelni azt a kockázatot, amit úgy hívunk: emberi tényező. Még a matematikusoknál

Az is tény, hogy sokkal több emberből lehet jó építészmérnök, mint jó szoftverfejlesztő. Egyszerűen azért, mert ez a szakma annyira absztrakt, hogy kevesen tudják jól felfogni. Matematikus és elméleti fizikus is kevesebb van, mint építészmérnök, az ő szakmájuk is eléggé absztrakt. Bizonyos gondolkodásmód kell az elsajátításához.

Ebből persze következik, hogy a szoftverfejlesztés rendesen csinálva nagyon drága. De csak azért, hogy olcsóbb legyen, nem kéne saját magunknak leadni a szintet.

"Szar szoftvert csinálni nem kerül sokkal kevesebb időbe, mint jót."

Akkor most miről is beszélünk? NASA mission-critical elvárásokat is teljesítő szoftverről, vagy csak simán "jó" szoftverről? Mert előbbit megcsinálni bizony jóval tovább tart és drágább. Ha utóbbiról, akkor a fenti idézett kijelentés akár még igaz is lehet, a "jó" definicíójától függően, de akkor meg minek idekeverni az űrsiklók szoftverét, amikor az egy teljesen más ligában játszik?
Btw, pár hónapja belebotlottam egy NASA coding guidelines dokumentumba, benne olyanokkal, hogy memóriát foglalni csak a program inicializálása során szabad, és hasonlók. Mekkora móka lehetne ilyen megkötésekkel például adatbáziskezelőt vagy szövegszerkesztőt fejleszteni ;)

"A legtöbb szoftvernél a kiadás utáni hibajavítások, supportálás viszi el a költségvetés 80-85%-át.
Az első verzió megírása a költségek (és az idő) kisebb részét veszik el."

Viszont az első verzió kiadása után már termeli a bevételt, azt meg szeretni szokták a managgerek... Ráadásul így a vevőknek is lesz okuk frissíteni, ami további bevételt jelent.

Jó szoftver szerintem: Olyan szoftver ami az ígért funkcióját ellátja, dokumentációja pontos, és esetleg hibái nem a tervezésből hanem a megvalósításból adódnak.

Tehát, ha egy programról azt állítják, hogy ellát egy feladatot, akkor azt tegye is meg. Ha majd két verzió múlva működik rendesen, és még bugos, akkor írják oda azt, és semmiképpen sem azt, hogy működik.
Ha valami le van írva a dokumentációban akkor az legyen is úgy. Ha mégsem úgy van, akkor azt kezeljék hibaként és vagy a szoftverben vagy a dokumentációban javítsák. Ha a jelenlegi verzióhoz még nincs kész a teljes dokumentáció akkor a régi verzió dokumentációjában legyen egy figyelmeztetés és véletlenül se kezeljék a jelenlegi verzió dokumentációjaként.
Ha van hiba a szoftverben akkor az ne azért legyen, mert eleve nem foglalkoztak vele ("jah, igen megdöglik a cucc ha túl nagy a bemeneti fájl, mert így egyszerűbb a program"), hanem mert a megvalósításban hiba van ("igen megdöglik a cucc ha túl nagy a bemeneti fájl. Ezt egy rosszul lekezelt túlcsordulás okozza. Igyekszünk javítani.").

"első verzió kiadása után már termeli a bevételt"
Az elso verzio utani bevetel meg nem jelent profitot. Attol, hogy van beveteled, de meg dolgoznod kell a szoftvereddel 5x annyit, mint elotte dolgoztal, nem jelenti azt, hogy egyaltalan megerte.
"memóriát foglalni csak a program inicializálása során szabad, és hasonlók."
"Mekkora móka lehetne ilyen megkötésekkel például adatbáziskezelőt vagy szövegszerkesztőt fejleszteni"
Azt remelem tudod, hogy ezek a megkotesek azokra a szoftverekre vonatkoznak, amik az ureszkozon menni fognak, azaz emberi beavatkozas nelkul, 100%-os megbizhatosaggal kell mukodniuk.
Mondjuk egy Mars urjarmu eseten alap az, hogy 8-42 perc a delay a ket bolygo helyzetetol fuggoen. Ott nem lehet "kiprobalom, mukodik-e, legfeljebb ujrainditom" szoftvert csinalni. Nincs okos rendszergazda, aki bemegy a gepterembe hardresetelni a gepet.
Nem az a lenyeg, hogy olyan megszoritasokkal eljunk a szoftverekre vonatkozoan, mint a NASA, hanem arra, hogy ugyanolyan FIGYELEMMEL, ugyanolyan MODSZERESEN vegezzunk szoftverfejlesztest. A NASA modszere nem a szoftverekre vonatkozo megszoritasokrol szol, azt a hardver es a kornyezet diktalja. Hanem arrol, hogy milyen modon fejlesztik ki ezt a szoftvert.

Lehetne ganyolni, cowboy codingolni de a NASA pontosan jol tudja, hogy olyan szoftverekre, amik ennyire rosszul definialt modszerek szerint keszulnek, nem lehet semmit bizni: the product is as good as the plan for the product.

Lazan kapcsolodik: pont mult heten hallottam egy tanaromtol, hogy elofordult mar, hogy "szakmai gondatlansagbol elkovetett halal okozasa" miatt kopogtattak az egyetemen a rendorok egy volt hallgato adatai es kepzese utan...

Egyebkent hatalmas +1.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ez lesz az valószínűleg:
"Btk.171. § (1) Aki foglalkozása szabályainak megszegésével más vagy mások életét, testi épségét vagy egészségét gondatlanságból közvetlen veszélynek teszi ki, vagy testi sértést okoz, vétséget követ el és egy évig terjedő szabadságvesztéssel, közérdekű munkával vagy pénzbüntetéssel büntetendő."

Egy egészségügyi szoftver esetében is alkalmazandó ez a dolog. Viszont pont az a baj, hogy nem igazán van definiálva, hogy nálunk mi az, hogy "foglalkozása szabályai".

"Vezessük be azt, hogy minden szabvány legyen kötelező. "

Inkább úgy, hogy amire van, arra tessék szépen azt használni. Miért kell pl. egy CSV-t folyton meginnoválni? Pl. azért, mert valaki lusta _keresni_ egy normális parsert hozzá, ezért inkább "\n" (szövegként!) vagy "|||" vagy más egyéb random szöveggel helyettesíti az enter jelet.

"De akkor minden legyen specifikálva, mindenből legyen referencia-implementáció. Minden dokumentáció legyen pontos [...]"

És ennek pontosan így kellene működnie.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Pont ez volt reggel a téma: más szakmában ilyen nincs, hogy "kit érdekel". Csak az IT ilyen trágyadomb, hogy képtelenek vagyunk szabványok betartására, mert "kit érdekel". Ebből a szemszögből nézve roppant ironikus, amikor mi szidjuk a megrendelőt, hogy azt se tudja mit akar, hülyeséget akar, lehetetlent akar, stb. Holott sokszor jobban belegondolva nagyon is reális igénye van, csupán az IT fogyatékossága és "kit érdekel" hozzáállása miatt hiányoznak a szabványok és az együttműködés lehetősége: mert mindenki a saját szája-íze szerint csinál mindent minimális mérnöki szemlélet nélkül.

Ugyanakkor az is roppant ironikus volt, amikor egy random user habzó szájjal végigszidta az MSVC++-t, merthogy "nem igazodik a szabványhoz", aztán tesz egy ilyen kijelentést, hogy "szarok rá, úgy is GCC-t használok". (És ezt még mennyi mindenre le lehetne fordítani.*) Na, ezért tart ott az IT, mert ilyet meg lehet tenni és ezért egy nagy trágyadomb az egész.

Ui.: hagyjuk már ezt az ingyen, szabadidő szöveget. Az, hogy otthon ki mit csinál, az senkit nem érdekel. Csak az a helyzet, hogy a szoftverfejlesztés egy szakma és ez a "kit érdekel" mentalitás túl sokszor átkerül a "nem szabadidős" munkákra.

* Csak néhány példa:
- SQL gyakorlatilag hordozhatatlan az egyes RDBMS-ek között
- HTML5 (ugye milyen jó lesz, hogy ezentúl kell külön HTML5 parser, mert XML-ként nem lehet már beolvasni?)
- Line ending
- Byte order
- CSV és *SV formátumok tömkelege, ami bár szabványos formátum, mégis mindig le kell egyeztetni, hogy de biztos így vagy úgy jön-e az adat?
- Csomó üzleti feladatra ezer éve lehetett volna szabványos formátumokat alkotni (vagy már van), de ezeket alig használja valaki, mert "nekem nem tetszik", vagy "nem ismeri", emiatt egyes gyártók kváziszabványai vannak, amikhez alkalmazkodni kell.
- stb.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

A gyakorlati peldak kozul a HTML5 annyira "szabvány", hogy maximum ajánlás, másrészt a W3C szerint is csak 2014-ben lesz kész, és 2020-ra várhatók az első teljesen kompatibilis megvalósítások. Szép munka...

Amúgy nincs min csodálkozni, ez egy kb. 50 éves szakma, még nem jutottunk el arra a fejlettségi fokra, hogy ilyen komoly problémákat, mint line separator, megoldjunk.
Ez persze annak is köszönhető, hogy nagyrészt teljesen absztrakt, a valóságtól nem függő a szakmánk, igazából (rettenetesen sarkítva) semmi mást nem csinálunk, mint szemantikát adunk különféle elektromos jeleknek. Azaz ebben a szakmában MINDEN megegyezés kérdése, nincs olyan korlátozó tényezőnk, mint a gépészeknek, építészeknek a fizika.

A HTML5-ttel arra akartam utalni, hogy töri a visszafelé kompatibilitást és megnehezíti hozzá a parser készítését egy XHTML-hez képest. De ez mellékszál.

Mérnöki tudomány az IT-n kívül van még egy pár, ahol már vannak módszerek a szabványosításra. De ez mellékes, IT-nél inkább a leszarom hozzáállás jellemző.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Azt elfelejted, hogy az XHTML az nem a HTML 4 utodja volt, hanem az XML-kompatibilis HTML.
Keszul az XHTML5 is.

A HTML mint olyan, sosem volt XML kompatibilis, hanem SGML kompatibilis.
Igen, nem eleg hozza az XML parser. Viszont ami agyrem, hogy a HTML5 mar az SGML-kompatibilitast is tori, sajat parser kell neki. Ez az igazan zsenialis resze.
Tehat a HTML5 az eddigi HTML-hez kepest tori a kompatibilitast teljesen.

"IT-nél inkább a leszarom hozzáállás jellemző."
Inkabb az "en jobban tudom, hogyan kell csinalni".

Mindenestre tenyleg borzalom, ami ebben a szakmaban megy szabvanyositas neven.
Egy-egy ceg termekei jobb minoseguek, mint a szabvanyugyi szervezetek altal, kozmegegyezessel kialakitott szabvanyok.

Nem veletlen, hogy egy ceg platformja a legelterjedtebb programozasi nyelv, egy ceg formatuma a legelterjedtebb irodai formatum, pixelgrafikai formatum, archivdokumentum formatum es hasonlok. Egyiket se szabvanyugyi testulet alkotta.

Azert, mert a W3C jobban tudja.
Amugy a HTML5 egyfajta second system effect aldozatanak tekintheto, az eddig W3C ajanlasokat nem tartottak megfelelonek sem JS API, medialejatszas, CSS, stb teren, ezert most elhataroztak, hogy na, akkor megalkotjak az ultimate legeslegjobb rendszert webes tartalmakra.
Lesz itt minden: CSS3, rengeteg JS API minden problema megoldasara, ami csak letezik, uj SVG verzio, uj HTML verzio, minden ami kell. Csak az egesz sosem lesz kesz.

A second system effect mar a 60-as evek ota ismert dolog, de meg mindig belefutunk. Nem tanulunk a sajat szakmank multjabol sem.

W3C az XHTML-t akarta tolni tovább, böngészőgyártók meg úgy döntöttek, hogy szarnak a W3C-re, mert szerintük lassan dolgozik (tény) és megalapították a WHATWG-t. Legjobb az egészben, hogy azóta ez a két brancs összebalhézott, szóval most jelenleg van a W3C féle HTML5 és a WHATWG féle HTML5.

Igazából ilyen baromságokkal jönnek, hogy ez-meg az kényelmesebb, pl. a br-hez nem kell lezáró tag, holott meg annyira számít, hogy idejét nem tudom megmondani, mikor írtam le az utolsó br tagot kézzel. Persze, egy XML parser már elhal rajta, élmény lesz.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

A masik, amit szeretek, a hianyzo adatok kerese.
Peldaul volt olyan eset, amikor egy SOAP uzenetben a hianyzo masodik keresztnev adatot nem ugy kellett am jelolni, hogy
1. opcionalis mezo, ha nem kuldod, nincs
2. a mezo meglete kotelezo (egyszerubb a parser), de ures tartalommal.
Neeem, be kellett irni, hogy null.
Na, ott kicsit elborultam.

Nem erről volt szó. Amit a megrendelő szeretne, megcsináljuk.
Itt a(z ingyenes) fordítók szabványtalanságáról volt szó. Ha a fejlesztők szívének az kedves, hogy nem követik a szabványokat, konvenciókat, hát tegyék, legfeljebb senki nem fogja használni a szarjukat.

Nem a szabványok hasznosságát vonom kétségbe. Egyszerűen csak nem akarom korlátozni az ingyenes szoftver fejlesztőit. Konkrét elvárásunk (szabványok betartása) csak a fizetős szoftverekkel szemben lehet.

Fuszenecker_Róbert

Egy szakmanak is vannak elvarasai a szakemberek irant. Persze, senkinek nem kotelezo szakembernek lenni, csak akkor ne nevezze magat annak.

Es most itt nem a GCC-rol van szo, hanem a szabvanyokrol es az IT-n beluli (tul altalanos) "szarok bele" hozzaallasrol.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Én speciel eddig azt hittem arról van szó, hogy vannak olyan fejlesztók, akik akarva-akaratlanul (tudatosan - öntudatlanul) olyan kódot írtak, amelyik a C-(esetleg C++) nyelv XYZ szabványának nem felelnek meg. Mivel vannak/voltak olyan fordítók, amelyek (most itt lényegtelen okokból) ezeket a kódokat is lefordítják, ezért a fejlesztő magasról tesz arra, hogy az adott fordító(verzió)n kívül is van élet. És jobb esetben eszébe se jut, rosszabb esetben tudatosan elutasítja még a gondolatát is annak, hogy az egyébként rendelkezésére álló egyéb fordítókkal legalább megpróbálja lefordítani azt a trágyahalmot, netán elgondolkodni azon, hogy miért mondja azt a fordító, amit. Azaz én személy szerint nem a GCC/Clang-fejlesztóket cseszegetném, hanem A, B és C szoftverek (szoftverecskék) fejlesztőit. Főleg mert a kurva nagy szabadságban még azt a minimálisat se teszik meg sokszor, amit megtehetnének. Pl. a saját maguk által elfogadott fordítónak kihasználni a lehetőségeit.

Pl: a nem-megy-clanggal listában volt olyan szoftver, amelynél pl. az volt a hiba, hogy a configure menetben "clang -Wall -Werror"-ral próbálták a következő magasröptű kódot fordítani:

int main(int argc, char *argv) { return 0; }

Amiben az a vicc, hogy ezt a kódot ezekkel az opciókkal a gcc is elutasította - az a fordító, amivel elvben a fasza fejlesztő agyontesztelte. De mit ad isten, még enyire sincsenek a jó minőségű kódok tesztelve.

Nem azt mondom, hogy a LibreOffice, vagy a KDE4 (ez már az?) legyen -Wall -Werror -pedantic opciókkal lefordítva, lint által megmorogva, bár hosszú távon szerintem az lenne a helyes, ha minden fejlesztő eljutna idáig. Ellenben olyan kód, aminek a fordítása nem hetekbe telik, annál azért simán meg lehetne próbálni minimum ennyit. (Speciel Linux alá - amely alatt ezen hulladékok jelentős része képződik - ingyenesen elérhető az Intel-ICC-je. Az OpenWatcom. A Clang/LLVM. A PCC. A GCC 43 változata. A TinyCC. És nyilván lehetne még sorolni. Ebből a listából ha akár csak egyet az az anyámasszony katonája fejlesztő feltelepítene az alapértelmezetten fent levő mellé, és megnézné, hogy az mit is kajabál, netán megpróbálná értelmezni és kijavítani a hibát, már kevesebet kéne szívnia másoknak.)

Miért utópia ez?
Más szakmák meg tudják oldani a dolgot. Szép lenne, ha mondjuk Kovács János építésvezető nem tudná értelmezni Szabó Gábor építészmérnök tervrajzát, mert az valami más jelöléssel és szabályok szerint készült.
Érdekes módon, ők ezt meg tudták oldani. Mi miért nem vesszük észre, hogy igenis, szükség van arra, hogy ha már létezik szabvány, akkor azt tartsuk be? Ezt a fajta szemléletet nem igazán oktatják, tizenéves kóderek teljesen felelőtlenül, cowboy coding módra alkotnak weboldalakat, komolyabb szoftvereket, beléjük rögzül ez az "everything goes" hozzáállás, és az nem jó.

Amúgy az IT-n belül az egyetlen igazán jól működő szabvány a TCP/IP. Amelyik számítógép nem beszéli, nem tud csatlakozni az internetre.

Valamint ami még jó: hálózatépítők (már akinek képesítése is van róla, hogy ért hozzá, nem csak krimpelőpistike) nagyon jó munkát tudnak végezni.

Vagy hogy hozzád talán közelebb álló dolgot mondjak: ha az amatőr rádiózás nem lenne úgy szabályozva, ahogy van és mindenki, akinek van eszköze, kiabálna az éterbe és azt állítaná magáról, hogy ő bizony rádióamatőr (vizsga nélkül természetesen), annak mennyire örülnél? Aki mondjuk nem szabályosan forgalmaz, az rádióamatőr?

"lassabb lesz a lefordított bináris és ami még rosszabb le sem fordulnak csomagok"
Átmeneti problémák amiket részben a GCC eddigi egyeduralma okozott. Annyira szabad a szabadszoftver, hogy fordítani is csak egy jól megkötött cuccal lehet...

"(Ideologikus okfejtések és munkásszoftvermozgalmi jelszavak hidegen hagynak)"
Mondja az aki szerint (egy másik témában) a Microsoft-nak csinálnia kéne open source Windows-t és úgy gondolja, hogy a Google jobb mint a Microsoft mert az Android (részben) nyílt forrású.

Te valamit ott nagyon félreértettél. A harcostárs a Microsoftot egyoldalúan támadó bürokratákon háborgott, amit igazságtalannak érzett mert az eladások 75%-át megszerző Androidot nem piszkálják.
Erre válaszul említettem gondolatkísérlet részeként a kódnyitás ötletét. :-)

Érdekes, mert ha Theo de Raadt-ot megkérdezed, annak nem elég free a FreeBSD.

http://marc.info/?l=openbsd-misc&m=128634319422034&w=2

Emellett más BSD-knek nincs baja a gcc újabb verzióival.

http://www.shiningsilence.com/dbsdlog/2012/10/02/10481.html

E kettősség - nem elég free, de mégis free akar lenni - közt őrlődik a FreeBSD. Ez a külső szemlélőnek furcsa és érthetetlen lehet.

--
trey @ gépház

Nekem ettől függetlenül szimpatikus a kezdeményezés. Egyrészt, mert ad egy nagy löketet az llvm+clang fejlesztésnek, amely előremutatóbb, mint a GCC. Másrészt legalább a portsban lévő programok egy részéből is hullik a GCC-izmus. Harmadrészt, legalább kap egy erős konkurenciát a GCC, amivel versenyezhet.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

En attol felek, hogy ha majd minden FLOSS-korokben fontosabb szoftver (ami nem GNU, nyilvanvaloan) atall clang-ra, akkor meg clang-specifikusan fognak programozni. Akkor ugyanitt leszunk. Tanuljanak meg szabvanyosan programozni. Persze ehhez az is kell, hogy a runtime meg legyen POSIX-kompatibilis.

( saxus | 2012. 11. 07., sze – 20:57 )

Folytatás innen: http://hup.hu/cikkek/20121102/november_5-e_clang-nap_a_freebsd_nel#comm…

Tehát otthon a web service-em nem adhat vissza egy tyúklétrával szeparált listát, mert megtiltod? Na ne már!

Fuszenecker_Róbert

Maradjunk a CSV-nél továbbiakban, mert az egy igen jó példa erre. A CSV alapvetően egy igen jól megkonstruált szerkezet, alapvetően le van feddve benne az összes eset. Ennek beolvasására és készítésére majdhogynem minden nyelvre van már valamilyen kész lib, széleskörűen tesztelve. Tehát alapvetően egy viszonylag jól bevált eszköz.

Aztán jön (legyen mondjuk) Average Béla, aki a kornak megfelelően PHP-ban dolgozik. Ő úgy gondolta, hogy egyszerűbb és gyorsabb egy explode("\n") egy foreach és egy explode(";") párossal megoldani a problémát, mert az csak két függvényhívás meg egy foreach, nem kell libet behúzni, dokumentációt olvasni meg mindenféle egyéb ocsmánysággal foglalkozni. Aztán a következő kolléga (én) szop vele, hogy hoppá, valamelyik partner többsoros terméknevet használt a cikknévben. Persze, hogy korábban is össze-vissza hülyeségek kerültek bele az ügyviteli rendszerbe betöltött árlistákba, az más kérdés. (Pl. elcsúsztak a mezők, mert a "Cucc (alfa;béta;céda)" terméknevet nem tudta értelmezni)

De semmi gond, jön az innováció! Használjunk tyúklétr^Wtabulátorral szeparált listát, mert az tök jó, nem lesz gond a ;-knél, az ügyviteli rendszer meg amúgy sem enged enter jelet a cikklistában. Aztán hogy-hogy nem, nekem mégis sikerült kicsikarnom egy Exceptiont-t egy Convert.ToInt32() hívásnál, mert valaki mégis jó viccnek tartotta, hogy a terméknév végére rakott egy tabulátort (Gondolom így másolta valami Excelből vagy honlapról, az ügyviteli rendszer meg nem trimmelt).

Mindez miért? Mert vannak olyan kontár barmok a világban, akik lusták utánakeresni és/vagy utánanézni valami normális, szabványos, jól bejáratott megoldásnak* és egyáltalán eszébe jutott, hogy tyúklétrával is lehet szeparálni listát ahelyett, hogy használta volna a feladatra teljesen alkalmas, jól bejáratott szabványos megoldást.

* Ha tudnád mennyit fogtam a fejem Average Bélán, mikor láttam munka közben, mikor ezeket a csudás CSV és egyéb parsereit tákolta, mikor valami gond volt vele...

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

De nem is ugyanarról beszélünk: te arról panaszkodsz, milyen rossz, hogy az emberek nem a te igényeidnek megfelelően fejlesztenek.
Én meg arról, hogyha nekem kell valami, megírom, ahogy nekem tetszik, szabadidőmben este, és tök ingyen elérhetővé teszem, akkor senkinek semmi joga nincsen beleszólni, hogy mit hogyan valósítottam meg. Ha tetszik, használja, ha nem, menjen, és keressen másikat.

Nyilván ha másnap bemegyek a gyárba, ott úgy fogom megvalósítani, hogy pl. a Web service-em olyan formátumban adja vissza az eredményt, hogy az maximálisan megfeleljen a megrendelő elvárásainak. Azt is leteszteltem, hogy a generált WSDL nem-.NET környezetben (Jáva) is megfelelően feldolgozható-e, a megfelelő Jáva classok legenerálhatók-e. És ugyanezt PHP-ven is megnéztem, hogy vajon a holland fejlesztő is meg fogja-e tudni meghívni a Web service megfelelő metódusait. De ezt azért, mert a termékünk egy üzleti termék, és a megrendelő közölte, hogy mit szeretne.

Otthon megnézném, hogy az *én* igényeimnek megfelel-e, és részemről a dolog lezárult volna. Ez persze nem azt jelenti, hogy otthon rossz kódot gyártanék, hanem azt, hogy a saját igényeimhez fogom igazítani.

A CSV-s példánál maradva: ha a megrendelőnek #-val szeparált lista kell, megkapja. Ha nekem otthon #-val szeparált lista kell (mert esetleg egy mikrovezérlővel dolgozom fel az eredményt), megcsinálom *magamnak*, és nem érdekel senki véleménye.

És hogy kapcsolódik ez a topikhoz? Morognak egyesek, hogy milyen szabványtalan a gcc. Lehet, nem kétlem. De akkor használjon mást, pl. clanget. Amiatt sem jogos a morgás, hogy a GNOME nem fordul clanggel. Nyilván azért nem, mert Gnóm Géza, amikor hazamegy, és van ideje fejlesztgetni, akkor csak gcc-vel teszteli, mert az van neki otthon, és különben sem akarja az éjszakát arra fordítani (ingyen, önzetlenül), hogy más fordítóhoz reszelje a kódját, ráadásul úgy, hogy neki arra végképp semmi szüksége, csak szóltak neki, hogy egy valamilyen partizán-C-fordítóval nem fordul.

Nem jó érv az, hogy mindegy, szabad-e a kód vagy üzleti. Teljesen más: az üzleti szoftver egy termék.
A szabad szoftvert pedig valaki megírta a saját megelégedésére, és megosztotta másokkal, hátha másnak is jó valamire.
Egy termékkel kapcsolatban emelhetünk kifogást a minőséget illetően. Viszont az "ajándék lónak" ne nézzük már a fogát!

Fuszenecker_Róbert

De nem is ugyanarról beszélünk: te arról panaszkodsz, milyen rossz, hogy az emberek nem a te igényeidnek megfelelően fejlesztenek

Nem. Neki az a baja, h a pistikek a szabvanyokat leszarva barkacsolnak, mikozben ezeket pont azert talaltak ki, h legyen interoperatibilitas, mert ennek hianya osszefuggo rendszerek fejlesztesenel eleg komoly problemakat tud szulni.

Egy termékkel kapcsolatban emelhetünk kifogást a minőséget illetően. Viszont az "ajándék lónak" ne nézzük már a fogát!

Dehogynem. Attol h "ajandek lo", meg nem kotelezo taknyolni, lehet igenyesen is csinalni.

---
pontscho / fresh!mindworkz

Aki barkács szoftverekből építkezik, annak tudatában kell lennie azzal, hogy esetleg nem fogja azt kapni, amit remél. Persze az is lehet, hogy egy tök jó szoftvert fog kapni, habár egy kezemen meg tudnám számolni, hány nyílt/open_source programot mernék jó szívvel ajánlani másoknak.

Egy igényesen megcsinált szoftver is lehet olyan, ami nem követi a szabványokat[1], mert pl. a Pistikénél nem szempont az interoperabilitás. Sőt, egy mereven szabványkövető kód is lehet taknyolás.

A baj akkor van, ha a szoftver gyártója azt ígéri (nem "kitűzi célul", vagy "törekszik arra"), hogy betartja az XY szabványt, de mégsem teszi, és valaki ezt komolyan veszi, esetleg kára származik belőle. Gyakran ki is zárják a licencben a felelősségvállalást.

Fuszenecker_Róbert

_____________
[1] Konkrét példa: a német fejlesztőnek valamiért úgy tetszett, hogy az SNMP trap paramétereit egy nem-szabványos DHCP opcióban fogja átadni a kütyüknek. Ez nekem, mint fejlesztőnek, nem okozott semmifajta lelki törést. Ettől a kód még szépen van megcsinálva, annak ellenére, hogy németek csinálták.

Na itt van megint a szokásos open source probléma:
Mindenkit megpróbálnak rávenni, hogy használjon nyílt szoftvert, hiszen az is van olyan jó. Ha viszont kiderül, hogy mégsem olyan jó akkor jön, hogy de ingyen van.

El kéne már dönteni, hogy az open source szoftverek fejlesztésével mi a cél. Hobbi projekteket akarunk megosztani, vagy valós alternatívákat a fizetős eszközökre?
Ha hobbi projektek, akkor semmi gond, de ne is várjuk el bárkitől, hogy használja is.
Ha viszont rendes szoftver fejlesztése lenne a cél, akkor talán a minőséget is szem előtt kéne tartani.
Do or do not. There is no try.

Mert jelenleg mindig az "ingyen van" érv mögé bújnak ha kiderül, hogy nem tejesíti az ígéreteit a szoftver. Ha így áll valaki hozzá, az nem gond, de akkor ezt jó lenne tisztázni mielőtt valaki elkezdi használni a szoftverét. Pont az ilyenek miatt van rossz megítélése a nyílt szoftvernek.

A nyilt forraskodu szoftverek kozul azoknal, amelyeknel a fejlesztesi modell is nyilt, pont az a problema, hogy barmilyen kontar ember hozzanyulhat, lasd Debian OpenSSL bug. Mivel megtehette, az abszolut hozza nem erto fejleszto hozzanyult a kodhoz. Ezzel szepen el is rontotta azt.
Persze, otthoni hobbikent mukodik ez, de komoly helyre ilyen szoftvert tenni felelotlenseg. Hanyszor lett mondjuk auditalva a Debian Linux barmelyik verzioja biztonsag szerint?

Ebben a szakmaban az a baj, hogy a legtobb szoftver csak "good enough". Azonban azok az emberek, akik raszoknak arra, hogy good enough szoftvert fejlesszenek, esetleg olyan helyekre is el akarjak adni a munkajukat, ahol ez keves.

Persze az oktatasi rendszer is ilyen, nem igazan tapasztaltam, hogy szoftverfejlesztest oktatnanak barhol is. Programozasi nyelveket, programozasi elmeletet tanulnak, meg csoportmunkat csinalnak az emberek. De ez keves szerintem.
Persze tanulunk elosztott paraméterű villamos hálózatot paraméterezni, meg tanulunk Lebesgue-mértékről, meg sok minden másról, de arról nem, hogy mit jelent az, hogy jó szoftverfejlesztő vagy.
Már régóta mondom, hogy nincs szoftvermérnöki szak a magyar felsőoktatásban, pedig jó lenne.

Szandekosan nem emlitettem kodminoseget, az megint +1 dimmenzioja lenne a dolognak.

Csak es kizarolag arrol van szo, hogy _eszebe jut_ az, hogy de nem muszaj alkalmazkodni a szabvanyos uthoz, hanem azokat le lehet szarni. Es hiaba mondod, hogy "ha bemegy a gyarba". Ez ket helyen bukik meg:
1) nem fog bemenni a gyarba, mert sajat maga a gyar es onjta a szemetet az iparba (egyeni "vallalkozo")
2) ha "otthon" eszebe jut, akkor melohelyen is eszebe fog jutni. Hiaba mondod, hogy de nem, az a keresru tapasztalat, hogy de igen, mert szerinte ugy egyszerubb. Aztan utolag szinte mindig kiderul, hogy szivas van vele. Ezernyi peldat tudnek sorolni.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"egy kezemen meg tudnám számolni, hány nyílt/open_source programot mernék jó szívvel ajánlani másoknak."
Tehat elismered, hogy a bazar modon fejlesztett open-source szoftverek nagyreszt valojaban semmit nem ernek.
"Konkrét példa: a német fejlesztőnek valamiért úgy tetszett, hogy az SNMP trap paramétereit egy nem-szabványos DHCP opcióban fogja átadni a kütyüknek."
Akkor ez nem egy igenyes szoftver.
"Ez nekem, mint fejlesztőnek, nem okozott semmifajta lelki törést. "
Te egy fejleszto vagy, aki ezzel dolgozik. Azonban, ha veletlenul hozzaillesztik ezt az eszkozt valamilyen meglevo, sokmillios szoftverhez, ami nem tud vele mit kezdeni, akkor bizony kiderul, hogy ez a szoftver nem er semmit.
Mi van akkor, ha egy masik szoftver UGYANAZT a nem szabvanyos DHCP-opciot valami masra hasznalja? Akkor abba a szoftverkornyezetbe ez a szoftver nem csak nem integralhato, hanem ha hasznalnak, akkor hibat okozna.
"Sőt, egy mereven szabványkövető kód is lehet taknyolás."
Ez igy van, a kodminoseg, meg a szoftver funkcionalis minosege kozott nem sok osszefugges van. A kodminoseg megint mas kerdes. Azert irsz jo minosegu kodot, hogy mas fejleszto is konnyen tudja javitani, modositani, tovabbfejlesztni a kododat. Mert a kodot embereknek irod, emberek fogjak olvasni. A compiler szamara mindegy, hogy _i43 vagy countOfRows a valtozo neve.

"A baj akkor van, ha a szoftver gyártója azt ígéri (nem "kitűzi célul", vagy "törekszik arra"), hogy betartja az XY szabványt, de mégsem teszi, és valaki ezt komolyan veszi, esetleg kára származik belőle. Gyakran ki is zárják a licencben a felelősségvállalást."
Na, akkor most baj vagy nem baj a nem szabvanyos DHCP-opcio hasznalata?

Pont ez a lenyeg: mivel teljesen absztrakt a szakmank, mi mondjuk meg, hogy egy adott bitsorozatnak (tkp egy adott elektromagneses jelsorozatnak) mi a jelentese. Es ha a fejlesztok nem egyeznek meg abban, hogy na mostantol az XYZ bitmintanak a jelentese ez es ez, akkor hatalmas kaosz lesz.

Gondolj bele, mi lenne, ha meg mindig nem letezne IEEE-754-es szabvany a lebegopontos szamok bitmintainak szabvanyositasara, es mindenki szamara mast jelentene az, hogy duplapontossag?

Regen, az elso szamitogepek idejen igy volt, ott meg egy gepi szo merete sem volt egyseges. Volt is nagy kaosz. Ma mar termeszetes, hogy a 8bit = 1byte az alapja mindennek, regen ez egyaltalan nem volt termeszetes.

Vagy nem letezne a TCP/IP. Aki nem ugyanazt erti az IP header bitmintajan, mint a szabvany, az nem tud csatlakozni az Internetre.

Azzal semmi gond nincs. Nem kell kifizetni es kesz. Legfeljebb csodbe mennek a keszitoi. Nincs ezzel semmi gond.
Viszont ugye, amikor arrol van szo, hogy FLOSS szoftver es mennyire megbizhatatlan szar, akkor mindig jon a valasz: ingyen van, ne varj tole sokat, illetve: ha jobbat tudsz, csinalj jobbat, forkold.

"Azzal semmi gond nincs. Nem kell kifizetni es kesz. Legfeljebb csodbe mennek a keszitoi. Nincs ezzel semmi gond."

Ennek analógiájára az se kellene, hogy gond legyen, hogy a nyílt forrású szoftverek olyanok, amilyenek.

"Viszont ugye, amikor arrol van szo, hogy FLOSS szoftver es mennyire megbizhatatlan szar, akkor mindig jon a valasz: ingyen van, ne varj tole sokat, illetve: ha jobbat tudsz, csinalj jobbat, forkold."

Szerintem én még nem mondtam ilyet (hacsak nem megboldogult ifjúkoromban ;), bár azt mindenképpen előnynek tartom, hogy legalább az elvi lehetőség megvan a jobbá tételre. Zárt forrású szoftvernél még a lehetőség sincs meg, pedig azok nem kevésbé szarok és megbízhatatlanok.

Ezek szerint ab ovo jobbak a nyílt forrású szoftverek, mert nyugodtan, gond nélkül lehetnek rossz minőségűek és a fejlesztők leszarhatnak mindent, hiszen ingyen van és akár te is módosíthatod?
Na, ez a hozzáállás az, ami szennyezi ezt a szakmát. Nincs olyan, hogy leszarom, ha nyílt, ha nem nyílt szoftverről van szó.

És mivel a pénzes, zárt szofvercégnél van jobbító szándékú visszacsatolási lehetőség a fejlesztők felé (tönkremegy a cég), ilyen jobbító szándékú visszacsatolás nincs. Mert ha ki akarsz javítani upstream egy orbitális hibát, azt még megengedik. De ha már elvi problémáid vannak a megvalósítással, akkor berágnak a fejlesztők, mert hülyének nézed őket és megsértődnek: csinálj jobbat, ha tudsz, ingyen van, ne legyenek kritikáid!

Tipikusan ez a Csubakka-védekezés az, amit alkalmaznak, de a szoftverfejlesztés menetét, magát a szakmát nem szabadna befolyásolnia annak, hogy ingyenes, nyílt vagy pénzes, zárt szoftvert készítesz el.
És ez a fajta védekezés akkor meg pláne nem működik, amikor a szoftverfejlesztőt teljes állásban alkalmazzák azárt, hogy nyílt forráskódú, ingyenes szoftvert készítsen.
Otthon, hobbiból, saját használatra mindenki úgy szívatja meg magát, ahogy akarja (hiszen senkit nem érdekel az sem, hogy ha saját magad építesz olyan cuccot, ami rád omlik vagy megráz az áram), de amikor munkáról van szó, akkor nem.

Az építészmérnök is ugyanolyan gondossággal jár el, amikor egy felvonulási épületet tervez, meg akkor is, amikor egy családi házat. Pedig hát a felvonulási épület csak egy raktár, amit az építők használnak egy másik épületkor, és amit el kell bontani akkor, amikor a kérdéses épületet használatba veszik.
Egy villamosmérnök is ugyanolyan gondossággal tervezi meg egy kétszobás lakás hálózatának méretezését, mint egy kórházét. Attól, hogy a probléma komplexitása kisebb, a gondosságból nem szabad engedni.

Semmi bajom nincs azzal, ha valaki nyílt forráskódú szoftvereket csinál MÁSOK számára. Nyugodtan csinálja. Azzal van bajom, hogy nincs meg az a szemlélet, hogy gondossággal készítsük el a szoftvereket. Attól, hogy valami hobbiból készül mások számára, vagy fizetnek érte, attól még a szakma szabályait be kell tartani.

" nem kell libet behúzni, dokumentációt olvasni "
Engem az is elborzaszt, hogy olyan az informatikai oktatás, hogy nem tanítjuk meg az embereket dokumentációt írni, ezért
1. Nem szoknak hozzá, hogy dokumentációt kell írni
2. Amikor dokumentációt kell írniuk, nem tudnak jó dokumentációt írni

Csak egy összehasonlítás arról, hogy egy épületnél az egyik fontos dokumentációról mit oktatnak:
http://www.hsz.bme.hu/hsz/oktatas/feltoltesek/BMEEOHSSZ09/a_statikai_sz…
Az utolsó mondatra felhívom a figyelmet.

Persze az első félévben már tanítunk programozást, beszélünk arról, hogy mi a nyelvi eleme a kommentezésnek, de egyáltalán nincs szó arról, hogyan kell dokumentációt írni.
Pedig egy szoftverfejlesztőnek tudnia kell jó dokumentációt írnia.
Sokszor túlzásnak érezzük, működjön és kész, de ha azt szeretnénk, hogy a szakmánknak ugyanolyan megbecsülése legyen, mint egy valódi mérnöknek, bizony ezt a dolgot is el kell sajátítanunk: dokumentálni kell a saját munkánkat.
Jelenleg is tudok olyan helyről, ahol bankok számára fontos szoftvereket készítenek (nem weboldal, meg ilyenek, hanem komolyabb middleware), és nem elvárás a dokumentációkészítés. Persze így egy szoftver karbantartása is horror.