Nem lenne szabad a gyárilag selejtre tervezett cpu-k forgalmazását hagyni.

Autót se lehet eladni biztonsági öv nélkül, fura hogy procit meg szabad főleg hogy nem az öv hiányzik belőlük hanem a légzsák helyén 100 as szögek vannak......

[ Szerkesztve ]

ha meghúzom a kocsidat az oc-nek számít?

Ez a hajó már elment

Jó pilóta alagútban nem katapultál

...számítanak a hardver sebességének megszokott ütemű javulására, amivel gyakorlatilag pótolják a nem hatékony kódolási folyamatokat.

Ezt tetováltatnám az összes nagyképű programozó homlokára.

Dolgoztál már egy komolyabb szoftver fejlesztő cégnél?
Ha igen, akkor tudhatod, hogy a fejlesztők nagyrésze szeretne jó kódot írni, de a vezetőség számára fontosabb az új funkciók folyamatos erőltetése, mert úgy gondolkodnak, hogy ettől lesz eladható a termék.

Eladó régi hardverek: https://hardverapro.hu/apro/sok_regi_kutyu/friss.html

Én is ezen akadtam ki. Ha a vezetőségen múlik, ahogyan lentebb írták, akkor a kur*a anyjukat, amiért nem működnek rendszerszinten normálisan, mert dilettáns a vezetés.
Ha nem ez a baj, akkor tanuljanak meg normálisan programot írni, optimalizálni. Az utolsó bit-nek is legyen értelme.

Vagy csak
- meg kéne tanulni rendesen algoritmizálni
- nem lelépni 1,5 év után az egyetemről, mert felszippantott a piac
- nem fél éves gyorstalpalók után programozónak nevezni valakit. Ha szakács volt előtte, ha fizikus.

De persze, biztos mindenki más a hibás azért, mert dilettáns a szakma fele.

Azért látjátok Tapsi, hozzászólása végén a smiley-t remélem...

Mellesleg ez a probléma minden fejlesztőt érint... de amit Linus mond az szerintem az első vészcsengő... volt már rá példa a világtörténelemben és újra eljön az a korszak amikor igenis számítani fog milyen kódot írunk, és nem az lesz a fontos, hogy lapátoljunk....

Mondja, Mr. Babbage, ha rossz adatokat ad meg a gépnek, akkor is jó válasz fog kijönni belőle?" Képtelen vagyok felfogni azt az értelmi zavart, ami valakit egy ilyen kérdés feltevésére késztethet. - by Charles Babbage

Arról nem is beszélve, hogy sok programot még most sem írnak meg úgy (vagy nem akarnak vagy nem tudnak), hogy kihasználja a több magot. Akkor miről is beszélünk?

nem a programozók hibája, adott egy munka, x idő van rá, osztán' hajrá, ahogy fentebb mondák, a vezetőség dönt ezekről, más kérdés, ha valaki tudja h trét kell gyártani akkor nem vállalja el, de ugye pénzből él mindenk - is -

_tejesen'® joálapotpan'™_-_Hamarosan a hiányból is hiány lesz...by Samus

A fejlesztés nem így működik. A termékben mindig van hiba. A kérdés az, hogy megtalálja-e valaki, vagy zavar-e valakit. Nyilván az említett sebezhetőségek sok embert zavarnak és ez baj. Ez bárhol bárkivel megtörténhet.

tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!

Ugyanakkor kíváncsi lennék, hogy egy MI/programozó algoritmus idővel vajon hogyan, milyen gyorsan és mennyi hibával rakna össze egy programot.

Mert akkor lesz ám szép jövőnk, ha azokat is behívjuk segítségül. Egykettőre megoldanák a problémákat.

A vezetők feladata, hogy miharamabb legyen eladható termék. Ezt szerintem a legtöbb vezető teljesíti. Hogy ehhez mi kell? Kvalifikált programozók, akik tudják, hogyan lehet a lehető leghamarabb megcsinálni, minél kevesebb hibával.

tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!

Azért azt se felejtsük el hogy programok nagy része simán elfut akár több példányban is akkora erőforrást biztosít egy középkategóriás PC. A programok 95% ának bővel elég egy 4magos i5 meg 16GB ram... Ha meg elég akkor minek optimalizálgasson ha nyer max 20-30% ot dupla akkora időráfordítással. Tudom tudom ennél sokkal többet is lehet nyerni akár 80%ot is de kérdés érdemes-e rááldozni az időt... A programozónak programoznia kell a gazdaságosnak meg eldönteni mi gazdaságos és mi nem... Rengeteg olyan cég ment tönkre akik szinte hibátlan programokat írtak csak túl sok idő és pénz befektetéssel és nem éltek mega piacon...

"DOS addresses only 1 Megabyte of RAM because we cannot imagine any applications needing more." Microsoft in 1980 "We can" -said Google, than they made Chrome. What happend next is history.

Fejlesztés helyett gyorsabb hardvert venni -- optimalizáció. Mérnöki döntés.

while (!sleep) sheep++;

Sok programot egyszerűen nem lehet. Elméletileg sem.

while (!sleep) sheep++;

Jelenleg 32 bites rendszerre fejlesztünk. Kernel upgrade féléves meló. CPU váltás féléves meló. 32 bitről 64 bitre váltás megjósolhatalan. 1 magról több több magra optimalizálás szintén.

Hogy miért lehet ez? Több, mint 20 éve íródott a kód az akkori olcsó mikrokontrollerekre.

A processzek még nem vészesek, mert azok független memóriával rendelkeznek, szemben a threadekkel, amiknek közös a memória területe. Az utóbbit hibamentesen jól megírni nem egyszerű. Viszont a több magosság problémáját processzekkel is meg lehet oldani.

tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!

Szerintem inkább gazdasági. A cégnek így olcsóbb.

tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!

Szerintem nem. Gazdasági érdek mozgat mindent. Boldog boldogtalan programozik már és még több embert akarnak bevonni. Őket nem jellezmően nem fogják tudni megtanítani, viszont a fejlesztésnek mennie kell és programnak is futnia kell. Ha már a hardveren nem tudnak gyorsítani, akkor sem a forráskódot fogják faricskálni, hanem az optimalizációra gyúrnak rá példának okaként ott van a futás idejű optimalizáció és ez még csak a kezdet.

[ Szerkesztve ]

tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!

Nekik igen.
Csak az user szopja meg az egyre dráguló hardver árak mellett.

Amd - Radeon - Ryzen

te dolgoztál már komolyabb szoftverfejlesztő cégnél?
a vezetőség ült a géped előtt és döfködte a klavit, vagy te?
mert ha véletlenül az történt, hogy te csépelted be a kódot, akkor bizony a vezetőség max. kérhet, de mindig is kibic marad.

következmény: az, hogy milyen minőségű kódot adsz ki a kezedből, kizárólag rajtad múlik és senki máson.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

"de amit Linus mond az szerintem az első vészcsengő...": mert amikor a tesla beszállt a kamion alá, az nem volt vészcsengő? amikor a volvo elgázolta a biciklist, az se? amikor a boeing beleszállt a földbe több példányban is, az nem volt vészcsengő?
az, hogy amióta a w10 átállt erre a fejlesztési metódusra, még egy update se jött ki balhé nélkül, az nem volt vészcsengő?

ezer éve üvölt minden, hogy sz.r a fejlesztés...

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Persze a programozó írja a kódot, de ugyanezt a programozót kérik meg a legacy hibajavításra, induló porjekt támogatásba és a mostani kifutó pátyolgatásba. Akkor még nem beszéltünk arról, hogy kik azok akik kapják a prémiumot meg az előléptetést? Akik időre tudnak szállítani, még ha kétséges annak minősége.

Megfordítom a kérdést. Cégen belül kinek az érdeke a jó minsőgéű kód? Nem a programozóé . (Ez a kérdés vonatkozik a #24-es hszedre is.)

[ Szerkesztve ]

tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!

Ezzel nincs is problémám, hiszen egy logikus gazdasági döntés. Ennek a korlátairól szól a cikk, és nagyjából én is ez alapján trollkodtam.

(#25) buherton

Cégen belül kinek az érdeke a jó minsőgéű kód?

Valójában mindenkié. Egy kompetens vezetés ezt egyébként tudja is, nem véletlenül alkalmaznak code review-t jobb helyeken!

[ Szerkesztve ]

tehát ha ugyanaz a programozó fogja elvégezni a legacy hibajavítást is, akkor valójában kinek az érdeke a hibátlan kód?

másik kérdés: ha valaki 10-20 éve programoz, hogy van az, hogy 20 év gyakorlattal a háta mögött még mindig ugyanolyan csotrogány kódot ír, mint kezdőként? és akkor ebből levezetjük szépen, hogy a verziószám fetisizmus miért ökörség.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Marpedig Bicinek igaza van. A fejlesztes menetet jobb-komolyabb helyeken megtervezik.
A vezetosegnek, product owner-nek, vezetoprogramozonak ra kell bolintani az adott funkcio implementalasara.
Barmikor mondhatjak hogy bocsi, de a 24 oras tesz framework-nek most alacsony a prioritasa.
Ergo, a tisztelt programozo azt csinalja amit mondanak neki. Marmint a legtobb helyen (kiveve az 1 fos bt ofc)
Ausztral kollegak viszont sokszor meglepnek hogy ott ennyire nincs ez, es tenyleg jo featureket raknak a termekbe.

HP ZBook Workstation A3000 - Linux Mint; Raspberry Pi4 - Raspbian

Nem érted. Adott egy idő, az alatt el KELL készülnie. Az idő általában kevés, ezért úgy oldja meg a programozó, ahogy belefér az időben. Ha lenne több idő, és szempont lenne a kód minősége, akkor nyilván megoldaná: lásd a fent említett példák.
Vagy úgy gondolod, hogy te majd kioktatod a vezetőséget, hogy te nem tudod megoldani ennyi idő alatt? Ok, majd jön más a helyedre, aki megírja a kívánt szar kódot annyi idő alatt amennyi alatt kérik.

https://www.youtube.com/channel/UCGzkAM74dJ_Vo2r73Y1tv2Q

A vezető érdeke a jó minőségű kód és ez alatt értem a jól megírt és hibamentest is.

A kód minőségnek rengeteg területe van és ebből egy a code review. Kellene a megfelelő cégen belüli képzés, tervezett fejlesztés (ne csak az legyen meg, hogy mit kell tudnia a kódnak, hanem azt is, hogy azt hogyan kellene a meglévő kódba illeszteni), használható processzek a code reviewra, beszállításra, több szintű tesztelés, statikus és dinamikus kód analizátorok, stb.

tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!

A Volvo esetében ki volt kapcsolva a Volvo rendszer beavatkozása, amelyik amúgy érzékelte és meg is akadályozta volna a balesetet.

Szerintem a jó kód és a rossz kód előállítása között nincs számottevő időbeli eltérés. Tudásbeli van.

Nem értünk egyet. Jön egy új funckió, széttolja az eddigi kódot. 2 út van:
1. refaktor. Eredmény szép, gyors kód, ráfordítás: 1 hónap
2. gány. Eredmény ronda bugos kód, ráfordítás: 1 hét.
Szerinted a főnök / megrendelő melyiket fogja választani? Ha nem tudod a választ, akkor félek, Te nem dolgoztál fejlesztő cégnél. Alternatív lefutás: ha nálatok az 1-es megoldást választják, akkor jól becsüld meg a helyet!

A vezetőé természetesen. A programozó van a tápláléklánc legalján, aki kb semmiről semmit nem tud, csak elvégzi azt a munkát, amit mondanak neki. Aki már tud is valamit, annak már nem csak programozói titulusa van.

Van aki hivatásszerűen űzi a programozást és folyamatosan képzi magát és folyamatosan reszeli a kódot, hogy ésszerű legyen. Van aki csak bejár és haza viszi a fizut. Mindekettő fellelhető a legtöbb cégnél, csak az arányok szoktak változni.

tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!

azok a projektek, amikről nekem infóm van, gyakorlatilag mind csúsztak. komolyan hiszek benne, hogyha elkezdeném túrni a netet ilyen irányú statisztikákért, találnék olyan tanulmányt, ami szerint a szoftverfejlesztési projektek legalább háromnegyede csúszik.

például az ms desktop oprendszer projektjei mindig csúsztak, rendszerint sokat.

tehát akkor ki a fenét érdekli, hogy a főnökség milyen határidőt tűzött ki? a tapasztalat azt mutatja, hogy akkor is csúszik, ha gányolnak, meg akkor is, ha nem. akkor miért gányol?

másrészt még mindig ott van a kérdés: ha valaki életvitelszerűen programoz, miért nem javul a teljesítménye minőség terén is?

"Vagy úgy gondolod, hogy te majd kioktatod a vezetőséget, hogy te nem tudod megoldani ennyi idő alatt?": fel sem merül, hogy vitát nyissak a vezetőséggel ilyesmiről.

egy kivételt látok: a debian. ott akkor van release, ha készen van a cucc. ez a hivatalosan kommunikált álláspont.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

igen. nem a saját szórakoztatásomra csinálok projekttervet, a fejlesztők sem azért esztimálnak, mert annyira szeretnek. lehet ragaszkodni az irreállis határidőkhöz, de akkor a szkópból kell majd vágni, adott esetben annyit, amennyi akár az egész projekt értelmét is megkérdőjelezi (túl nagy effort, túl kevés nyereségért). vagy önként, vagy majd azért, mert használhatatlanul megbízhatatlan lesz.

Tudod, mit jelent az, hogy nemezis? Az érintett, erősebb fél kinyilatkoztatása a méltó büntetés mértékét illetően. Az érintett fél jelen esetben egy szadista állat... én.

és? a nem volvo rendszert, ami kivasalta a biciklist, nem programozók írták?

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Ez óriási tévedés. A programozó a számára rendelkezésre álló információ alapján írja meg a kódot, amiről aztán megfelelő környezetbe kerüléskor, integrációs teszteknél derül ki, hogy mennyire állja meg a helyét. Aztán vagy adnak rá pénzt, hogy javítsák, vagy nem.

W10 topikba nem menjél. Mert ott ezért a véred veszik.

Amd - Radeon - Ryzen

én üzemeltetőnek tartom magam, aki akkor programoz valamit, ha az üzemeltetéshez kell. tehát programozok is, csak nem életvitelszerűen. a vezetőség olyan kérdésekben dönt, amilyen kérdések elé kerülnek. ami nem kerül elé, abban értelemszerűen nem dönt.

neked például mennyivel több idő olyan kódot írni, ami legalább nem elvi hibás? például ha c-ben programozol, mennyivel több idő az sprintf helyett snprintf-et írni (meg a plusz argumentumot és egy plusz vesszőt)?

"az optimalizálásnak a komplett munkafolyamat részévé kell válnia": nem kell, KELLETT VOLNA. hogyan akarsz rendes programot kiadni a kezedből úgy, hogy az optimalizálás nem alapértelmezetten része a munkafolyamatnak? ha még nem is optimalizálsz, akkor hogy lesz minőségirányítás integrálva a folyamataidba? pláne és kifejezetten és magas szintűen hogy lesz biztonságtudatos a fejlesztési folyamatod? hint: sehogy.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

"A programozó van a tápláléklánc legalján": ha a vezető nem ül a klavi elé, hanem a kódot a programozó írja meg, és nincs ember, aki 100%-ban újraírja az egészet, akkor a valóság az, hogy a vezető van a tápláléklánc legalján, a programozó pedig a tetején.

különösen mostanában, amikor a programozónak új állást találni könnyebb, mint kidebuggolni egy elcseszett mallocot.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Nem, mert az egy hús vér ember volt. aki valami sorozat nézett éppen, vagy videochatelt vagy mit csinált.

"az egyik megfontolandó opció az Intel Hyper-Threading technológiájának letiltása"

nem egy nagy veszteség, de akkor meg minek belegyártani a procikba, ha úgy is disabled....

igen, optimalizálni tudni kellene...programot írni művészet, jó programot meg pláne az, ami optimálisan gazdálkodik az erőforrásokkal, de ugye a munkáltatóknál ez nem szempont....optimalizálni? minek? a profit az első, az meg az újabb funkciókra jön....

saját tapasztalatom : programozó vagyok eredetileg, de rendszergazda voltam egy megyei kórházban 17 éven át a gazdasági rendszereken.....elég száraz és uncsi meló.
kezdetekben 1993 vala egy Novell 3.11-es server 80486 DX-33 + 16MB RAM + Adaptec SCSI kontroller és tükörben 2db 500MB-os SCSI disk, Computrend CTGAZD futott rajta tökéletesen, és a 286-os terminálokon...10Mbites ethernet + 2 Mbites arcnet kombó, kevert hálózat

2005-ben Dual Xeonos DELL server 32GB RAM, windows server 2010 vagy mi, terminálok C2D 2GHz-es procik, 4GB RAM....várakozások, időtúllépések, serverleállások, rengeteg felhasználói panasz, lassú, lassú, lassú......Ecostat rendszer.....

GIGABYTE B550 Aorus Pro, AMD Ryzen 9 5950X, Noctua D14, Crucial Ballistix 4x16GB DDR4 3200Mhz@3800MHz CL18, Powercolor 7900XT, M.2 Samsung 981 2TB, M.2 Kioxia (XG6) 2TB, 2 x Intel 730 SSD 480GB, Crucial MX500 2TB, SEAGATE SkyHawk 6TB, 750W Gigabyte Aorus Gold, Evolveo T4, Samsung S43BM700UUXEN

Processzort fejleszteni is muveszet, csak eddig a hardver oldali gyorsulas olcsobb volt, mint a szoftver oldali. Most, hogy eltolodik a merleg lesz majd optimalizalt szoftver is.

Azert 93-ban az adatbazisok merete, a megjelenitett(es feldolgozott) informacio mennyisege, tranzakciokezeles, lockolas, stb. meg erosen gyerekcipoben jart.

[ Szerkesztve ]

A vezetőség is hibás sok cégnél, de egy ismerősöm egy megavállalatnál programozó (vezetőbb beosztásban), az ő sztorijai alapján a programozók 90 százaléka alkalmatlan a programozásra. De nincs jobb szakember, így maradnak a buggyártó programozók, akiknél az önálló gondolkodás, logika, és a problémamegoldás mint olyan, nem létezik.
A hardveres fejlődés ellustította a programozókat, és az iskolák érdemi tudás és gyakorlat nélkül képzi a szoftveres embereket. Nem kell csodálkozni. Hány programozó van aki azt sem tudja minimális szinten sem hogy hogy is működik egy processzor...

[ Szerkesztve ]