Egy, a Linux Foundation-t, Microsoftot, GitHub-ot magában foglaló szövetség zöld szoftverfejlesztést sürget

Programozás

A Green Software Foundation egy, a Linux Foundation által igazgatott non-profit szervezet, ami a fenti célokat szolgálná. Címszavakban:

  • carbon-free applications
  • to make code more efficient and reduce carbon emitted from the hardware it's running on
  • to set standards, best practices and patterns for building green software
  • nurture the creation of trusted open-source and open-data projects and support academic research
  • grow an international community of green software ambassadors
  • to help the Information and Communication Technology sector to reduce its greenhouse gas emissions by 45% before 2030

Részletek a projekt weboldalán.

( buccaneers v | 2021. 05. 30., v – 12:33 )

Szerkesztve: 2021. 05. 30., v – 12:35

zöld desktop háttér nem elég ?

v. green themes ?

907. Július 4-7.

( lacesz v | 2021. 05. 30., v – 12:40 )

Inkább az egyszerű weboldalakat erőltetnék: https://motherfuckingwebsite.com/

Amíg van javascript, flash, stb. addig nem beszélhetünk zöld szoftverfejlesztésről.

Amíg kell minimum 8Gb ram egy normális böngészéshez, addig nem beszélhetünk zöld szoftverekről.

De nem csak a web.

Volt egy 2010-es évben kiadott alaplapom, abban egy 2005-ös processzor, nvidia integrált kártyával.

Erre akármilyen linuxot tettem, i386, i486, i586, i686, x86_64 stb akármilyen ablakkezelővel, herbstluftwm, openbox, i3 stb, borult egy két nap használat után mint a sicc. Még a legegyszerűbb tinywm-nek is kevés volt. pedig lecsupaszított, agyon butított linux vagy xp is lassú volt rajta...

.Amíg van javascript, flash, stb. addig nem beszélhetünk zöld szoftverfejlesztésről. Amíg kell minimum 8Gb ram egy normális böngészéshez, addig nem beszélhetünk zöld szoftverekről.

Ahhoz meg kene tanulni programozni es kevesebb spyware meg adware meg whateverware kellene... az meg hova vezetne?

A 2005-ös processzor tág fogalom. Meg nagyban függ, hogy mennyi memória van benne. De azért egy i3, Openbox, herbstluft, tinywm nem kéne, hogy problémát jelentsen. Annak simán kéne mennie, borulások nélkül. Amire gondolni tudok, hogy NV GPU van benne, és nem a jó driverrel hajtottad, a laikusabb felhasználók 99%-ának konkrétan ezen, meg a tearingen úszik el az egész Linux, pedig megoldható, de akkor érteni kell hozzá, nincs mese. A web az már más téma, annak tényleg kevés lehet a 2005-ös gép. Bár elvileg egy 2006-os, erősebb Core2Duo-val, mint. 4 GB RAM-mal, sovány Linux disztróval azért abszolválható, nem lesz villám, de azért komótosan el lehet rajta böngészni, igaz nem túl sok fülön, és Chrome-ot és származékait el kell felejteni, Firefox vagy származéka az egyedüli alternatíva. De mondom, mint 4 GB RAM (sovány disztrónak elég a 2 GB is, de a böngészőnek nem!), és nem árt, ha egy SSD is van benne, nem kell drága, egy legszutyokabb, noname, kínai, TLC/QLC-s, DRAM-mentes, 120 gigás csotrogány is elég bele, csak ne HDD recsegjen alatta a maga lassúságában.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Ja, de ez fejlesztés, ezt meg nem egy 4 giga RAM-os, 2005-ös processzoros gépen csinálod. A git egyébként használható shellből, mindenféle GUI nélkül, még vim-be is be lehet drótozni. Böngészők azok tényleg akármennyi memóriát meg tudnak zabálni, azokat óvatosan kell kevés RAM-os gépen használni, csomó letiltott cuccal, max. 1-2 fül, stb., gyakran érdemes újraindítgatni, stb..

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Nekem van egy adag 2000 előtti akármilyen gépem és akármilyen linux-al 1-2 éves uptime-jaim vannak. Csak azért indítom újra, hogy az fsck lemenjen. Vagy, hogy kondenzátort cseréljek az alaplapon, VGA kártyán....

WindowMakerrel és KDE 3.1-el ;)

http://plazmauniverzum.hu <> A látható anyag 99.999%-a plazma <>

( nagy_peter v | 2021. 05. 30., v – 13:56 )

Szerkesztve: 2021. 05. 30., v – 13:58

És mégis mit takar a "carbon-free applications"? Maga az app általában nem termel közvetlenül semmilyen károsanyagot. 

Az appot futtató hardver gyártása, szállítása, és a hardver által elhasznált áram megtermelése járhat mondjuk szédnioxid keletkezésével. Ez viszont nem az appon múlik, hanem az üzemeltetőn. A 64 magos processztort és 128 Gb ramot felzabáló számológép is lehet carbon-free, ha napelemről látod el árammal a gépet, és még egy hektár erdőt is ültetsz mellé.

Ha meg azt akarja jelenteni, hogy optimalizáljuk a szoftvert, attól nem lesz karbon-semleges, csak kevesebb erőforrást fog felemészteni.

Nagy Péter

Ez igaz. De ha a hardver energiatakarékosabb, és a szoftver is, akkor eleve kevesebb energiát kér, ergó ha szénalapú energiával is hajtod, akkor is környezetkímélőbb. Ma már sajnos a legtöbb kód nagyra hízott bloat, és emiatt a funkciójához mérten sok erőforrást kér (futási és fejlesztési oldalon is) Én részben ezért is használok minimalista megoldásokat. Nem a környezetet védem vele, hanem a kisebb, egyszerűbb kód nem törik el, gyorsabban frissül, és azonos hardveren gyorsabban, lagmentesebben, kisebb betöltési idők mentén fut le. Ezzel inkább a saját rendszerem átláthatóságát, biztonságosságát, és gyorsaságát védem, meg hogy ne kelljen x évente azért hardvert lecserélni, mert az újabb bloat kódok elavulttá tették. De kétségtelen, hogy ez a fajta hozzáállás a környezetet is védi, mert kevesebb régi hardver lesz kidobva, és a gépek kisebb áramfogyasztással futtatják a kódokat.

Bár egyébként most a legnagyobb ludas nem is a kódok bloatsága, hanem a coinbányászat, iszonyat áramot égetnek el, abszolút értelmetlen hülyeségre. A második számú probléma a böngészők és web bloatsága. Csak ezek után jön a többi szoftver, OS, stb..

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

De ha a hardver energiatakarékosabb, és a szoftver is, akkor eleve kevesebb energiát kér, ergó ha szénalapú energiával is hajtod, akkor is környezetkímélőbb

Teljesen mindegy: a megtakarítást nem környezetvédelemre használja az ipar, hanem arra, hogy változatlan erőforrás-keretből (= változatlan környezetszennyezés mellett) több munkát végezzen el (több pénzt csináljon).

( KGer | 2021. 05. 30., v – 14:19 )

úgy látszik a környezetvédelem jön a szoftverfejlesztésbe is

jelentése:
zsarolunk
befolyásoljuk a fogyasztókat így a piacot is
kontrolláljuk az ipart hogy még több pénzünk legyen (mármint akik ezt tolják)
és persze utólag kiderül hogy pont ők az egyik legnagyobb energiapazarlók, de ez mellékes
 

( buki | 2021. 05. 30., v – 15:33 )

Ha egy ilyen szervezet alapítójaként azt szeretném, hogy komolyan vegyenek, akkor bizonyára azzal az adattal kezdeném, hogy reprezentatív felmérések szerint a szén-dioxid kibicsátásának X %-áért a szoftverfejlesztés a felelős.

Én nem tudom, hogy ez a bizonyos X mekkora lehet, de elég nagy összegben mernék rá fogadni, hogy egy átlagos kínai szénerőmű hetek alatt übereli. Hangsúlyozottan a fejlesztésről beszélek - hiszen a szervezet is ezt teszi - és nem a szoftverhasználatról. (A kriptovaluták bányászata se azért fogyaszt sokat, mert rosszul van megírva a szoftver, hanem mert használják.)

Science for fun...

A kriptovaluták bányászata se azért fogyaszt sokat, mert rosszul van megírva a szoftver, hanem mert használják.

A kriptovaluták bányászata azért fogyaszt sokat, mert így lett megtervezve: a proof of worknek egy erőforrásigényes dolognak kellett lennie. Szerintem nagyon jól szemlélteti, hogy mit kellene elkerülni: Argentína energiafelhasználását fordítjuk arra, hogy SHA checksumokat pakolgassunk a blockchainre, miközben azzal a számítási kapacitással valami hasznos dolgot is kezdhetnénk.

Az alternatív bankrendszer működtetése jó dolog, de szerintem környezetterhelésben túl sokat fizetünk a létéért.

int getRandomNumber() { return 4; }  // ← aláírás
//szabályos kockadobással választva. garantáltan véletlenszerű.  xkcd

Az egységsugarú, legkisebb ellenállás felé tendáló megoldások azok, amiket el kellene kerülni.

Tehát pl. a bitcoin proof of work-je simán lehetne valami értelmes számításigényes feladat, pl. időjárási modellek számolása, WiFi jelszók, /etc/shadow-ok brute force-olása stb. de nem, inkább értelmetlen hash pöcögtetés. Mennyivel lett volna nagyobb munka egy publikus API-t létrehozni számításigényes feladatok beküldéséhez a bitcoin bányászok hálózatába? Nem lett volna könnyű munka, de nem is halt volna bele senki.

( zeller | 2021. 05. 30., v – 19:55 )

Na kinek fog ez nagyon tetszeni...? :-D

( STP | 2021. 05. 30., v – 20:58 )

De jó!
Akkor egy Win desktop install nem csiliárd GB lesz ezek után?

( aszijg v | 2021. 05. 31., h – 10:30 )

Ez nem az az eset, amikor a zöldek zöldséget beszélnek? :D

( YleGreg | 2021. 05. 31., h – 10:30 )

Szerintem megartott nekik a sok zold.

Fuvezz vagy kodolj, a ketto egyszerre nem megy.

( hajbazer v | 2021. 05. 31., h – 11:24 )

Nem újkeletű a dolog. Az olajcégek már régesrég indítanak zöld marketinghadjáratokat, hogy így leplezzék, valójában ők maguk a probléma, illetve a legnagyobb szennyezők. Nincs ez másként most sem. A multik (Microsoft) beszennyezik, beszennyeztetik a környezetet, utána pedig elhitetik magukról, hogy zöldek™ és bizony igen sokat tesznek a zöld™ ügyekért. Miközben meg lehet nézni egy JS-CSS-bloat Office 365-öt mennyivel több erőforrást pazaroltat el, mint egy Office 2010 vagy XP. Hogy ez világszinten, a felhasználókkal beszorozva hány gigawattóra többletenergia. Aztán lehetne még sorolni a Windows 10 frissítgetését, egyre inkább lassulását, a driver-inkompatíbilitás miatt kidobált nyomtatókat, scannereket, munkaállomásokat. A divatból újravásárolt, de amúgy is pár év után használhatatlanságig lassuló okostelefonokat.

Mutass jó példát - csökkentsd az eszközeit energiafogyasztását, meg a miattad történő adatforgalmat - kapcsold ki a gépedet! Két gépem van, az egyikben a CPU TDP-je 77W, a másikban 15W. Válaszidőkben, megjelenítés minőségében nincs különbség a kettő között normál használat mellett - oké, a számolós feladatokban lehet olyat találni, amivel a régebbi gyorsabban végez.
A valós fogyasztásban azért nincs ekkora különbség, de néhány kWh havonta "összejön" intenzív irodai használat esetén - az újabb gép javára.

"pár év után használhatatlanságig lassuló okostelefon" - Első kézből szerzett tapasztalatod ugye? Ja, nem :-) Nekem első kézből szerzett tapasztalat, hogy ha nem telepítek/törlök rogyásig mindenféle sz1rsz@rt a telefonra, akkor semmiprobléma nincs a sebességével. évek múltán sem. Ez egyébként olyan, mint a "szaravindóz mert rendszeresen újra kell rakni" - ja. ha minden vackot fel/le pakol valaki, akkor bele lehet ilyenbe futni - de mobilnál is van megoldás, ahogy a Windows esetén: "all reset" :) , és újrarakni mindent, elindulva a "kályhától".

Relatív, mi a felesleges. Számomra az a felesleges, amit te firkálsz az okostelefonokról, a tech-multikról, mert ugyanúgy megtalálom egy egótrigger élménybuzi kényelemhajhászatot népszerűsítő reklámban, Google keresés után az első 3-4 helyre SEO-zott marketing bullshit trágyadombon, meg a support fórumok házigazdái által kinyilatkoztatott korporatokrata kifogásáradatban.

( trey | 2021. 05. 31., h – 13:48 )

Zöld szoftverfejlesztés:

Kinn a kertben a gyepen, közben zöldet szívva  ...

trey @ gépház

( uid_2716 | 2021. 05. 31., h – 18:06 )

Ha ez nem paródia, akkor vagy elismerésre méltó naivitás, vagy elismerésre méltó képesség a rezzentelen arccal hazudozásra.

Ha a meglévő szoftvert hatékonyabb hardverre tesszük, akkor ugyanazt a munkát kisebb energiafelhasználással el tudjuk végezni.

Ha a szoftvert tesszük hatékonyabbá, akkor ugyanazt a munkát a meglévő hardveren kisebb energiafelhasználással el tudjuk végezni.

A fentiekkel szemben azonban évtizetek óta arra használjuk mind a szoftver optimalizálását, mind a hardver fejlesztését, hogy egységnyi idő alatt minél több munkát végezzünk el (= minél több $$$-t húzzunk ki a piacból), tekintet nélkül az energiafelhasználásra. Az energiafelhasználás egyedül ott számít, ahol a $$$ termelése szempontjából rugalmatlan korlátozó tényező (laptop akksi meddig bírja -- mennyit lehet eladni az új laptop-modellből; szervertermet mennyibe kerül hűteni; processzor mikor hevül túl). Az energiafelhasználást évtizedek óta maximumon húzzák. Most összedobtak egy új weboldalt, hogy "innentől nem így csináljuk, becs'szóra". Tök hiteles.

A másik meg (kifejezetten a fejlesztői tevékenységhez kapcsolódóan) a CI. Ma már követelmény a fél univerzumot újrafordítani és ötmillió automatikus tesztet lefuttatni minden topic branch beolvasztásakor. Egyáltalán nem véletlen, hogy a börtöntöltelék kriptobányászok rászálltak a különféle nyilvános CI rendszerekre, ellopva a jobb sorsra hivatott gépidőt. Onnan lopnak gépidőt (és ezzel energiát), ahonnan érdemben lehet lopni, vagyis ahol amúgy is tékozlás folyik. (Ezzel párhuzamosan évek óta probléma közösségi projektekben, hogy ki fizessen a CI CPU igényéért.)

A CI nem haszontalan, de a "full coverage" és az energiatakarékosság között alapvető ellentét van. A legkisebb elengedhetetlen teszthalmaz megállapítására kellene törekedni. A normál fejlesztési folyamatban amúgy is szerepel integrációs és egyéb teszt; az ilyen teszteredmények érvényességét kellene adott esetben átmenteni a beolvasztás idejéig. Illetve le kell nyelni, hogy az energiatakarékosság ára néha az, hogy a lefedettség hiányos, és emiatt regressziók vannak.

Ami még fontosabb: végre fel kell ismerni, hogy a CI nem helyettesíti az alapos peer review-t. A github ebben a tekintetben elképesztő károkat okozott a fejlesztési morálban és folyamatokban. (A "squash on merge" mis-feature önmagában indokolná a github beszántását és behintését sóval.) A peer review valóban nagyon nehéz, és szűk keresztmetszetet is jelent, de a környezeti lábnyoma elenyésző (etetni, itatni, aludni hagyni kell a reviewer-t). Alapos kódbírálat jó hatékonysággal meg tud fogni regressziókat. Ez valóban lassítja a fejlesztést, de az miért baj? Megint ott vagyunk, hogy"time to market", vagyis a lehető legtöbb $$$ kihúzása egységnyi idő alatt.

Fejlesztő vagyok. Nekem nem lenne kedvem és időm minden módosítás után végigkattogni több száz vagy ezer tesztet.

Nem számoltam ki, de saccolom, hogy hatékonyabb és kevesebb áramot fogyaszt, ha az 1000 tesztem 1 másodpercen belül lefut, mint ha én vagy bárki napokon keresztül kattogna a gép előtt, mire végez.

Most néztem egy átlagos projectet. 200 teszteset esetenként 10-20 ellenőrzéssel mondjuk 3000 teszt. Napokig tartana végigkattogni, ha nagyon gyors lennék és sose fáradnék el. Ehhez képest a gép 400 ms alatt végez velük.

Nekem nem lenne kedvem és időm minden módosítás után végigkattogni több száz vagy ezer tesztet

Nem is javasoltam ezt. Azt javasoltam, hogy (a) minimalizáljuk a tesztek számát, (b) mivel a teszteket amúgy is lefuttatod a helyi (vagy más értelemben "szűk") fejlesztőkörnyezetedben, azért az ottani teszteredmények érvényességét kellene megőrizni a beolvasztáshoz.

Nekem nem lenne kedvem és időm minden módosítás után végigkattogni több száz vagy ezer tesztet.

Kezdetnek elég lenne, hogy ha valaki bejelenti, hogy a szoftvered túl lassú egy viszonylag régi gépen, akkor nem zsigerből lezárod WONTFIX, és küldöd el új gépet vásárolni, az idealista termékmenedzserrel egyetértésben.

Alapvetően a hozzáállást kell megváltoztatni és ha az megvan, akkor sokkal kevesebbszer fordul elő bloat, pláne ha már a tervezési fázisban kiküszöbölitek a bloated frameworkökben való kényelmeskedést.

"akkor nem zsigerből lezárod WONTFIX" - persze, csak ha odaírja, hogy az optimalizálás adott hardverre 1234USD, akkor meg azon lesz a háborgás, mint ahogy akkor is lenne ordenáré nagy felháborodás, ha nem a "bloated frameworkök" hanem kerék feltalálása mindenütt lenne a módi, az egyszer már elkészített (és jó esetben karbantartott) komponensek, keretrendszerek használata helyett. Nagyságrendileg nőne a szoftverek fejlesztési költsége, és a fejlesztési idő is.

Nem, nem engedhető meg a fejlesztések/módosítások időigényének a rétestészta módra történő növekedése - egy jogszabályi kötelezettség miatti átdolgozásra nincs tetszőlegesen hosszú idő, de egy üzletileg kritikus rendszer módosítása sem tarthat az örökkévalóság+2 napig.

Vannak nem bloated frameworkök is és senki nem írta elő kötelezően, hogy mindig a legtrendibb, leghájpoltabb bloated szarkupacot kell használni, aminek több a marketingértéke, mint a szakmai értéke.

Az 1234 USD pedig már csak egy következmény. Annak a következménye, hogy multiéknál az idealista termékmenedzser és a sztárfejlesztő kiegyeztek egy agyonra hájlpolt, bloated frameworkben, mert épp a másik, sikeresebb multi is ezt használja, akkor rossz™ nem lehet. Igen, ha valaki egy alapvetően szar fejlesztési irányt jelöl ki, ami megannyi szoftveres és hardveres elavulást hoz magával, akkor végül valóban relatíve sok USD lesz visszaoptimalizálni régi hardverre az adott szoftvert.

A mondandóm lényege az volt, hogy a green computing ügyén csak és kizárólag a hozzáállás megváltoztatása tud segíteni. Hogy mondjuk nem 12. generációs 8 magos, 1 TB SSD-s, 64 GB RAM-os erőműveken fejlesztenek a babzsákfejlesztők, vagy tesztelnek a babzsáktesztelők, és máris, fejlesztési stádiumban feltűnik a bloat. Vagy eszébe nem jut bárkinek Electron-os szutykot fejleszteni, mikor napi szinten tapasztalja, mennyi memóriát zabál egy Chromium.

"Vagy eszébe nem jut bárkinek Electron-os szutykot fejleszteni, mikor napi szinten tapasztalja, mennyi memóriát zabál egy Chromium." - 8 vagy épp 16GiB-ból nem mindegy? Amíg nem reszeli a paging területet, addig azért van az a k.va memória. hogy használjuk... Tudom, nálad a 16giB az már szentségtörés, a 8 is olyan, hogy "de mi a fenének, mikor bithegyezéssel a fele sőt a negyede is elég lenne, de akár 640k-ban is el lehetne lenni" - csak azt nem veszed észre, hogy ezeknek a szerinted "must have" CPU és RAM-optimalizálósdiknak igen-igen magas a költsége. Te vennél olyan mondjuk irodai szoftvert, ami 567890Ft, de elmegy mondjuk 2GiB memóriával, és tudja mindazt, amit egy aktuális MS Office? Vagy fizetnél olyan böngészőért (és ha igen, mennyit?), ami 1-2GiB-tal megelégszik 10-20-több tab-ot megnyitva, természetesen a jelenlegi használt technológiákkal kompatibilis kivitelben?

Házi feladat: számold ki, hogy ha csak az ideje 10%-át fordítja arra a fejlesztő, hogy a build/teszt lefusson, az mennyibe fáj a munkáltatójának, illetve mennyit hoz a konyhára megtakarításként az, ha ezek a holtidők a korszerű munkaeszköznek hála mondjuk feleződnek - nem beszélve arról, hogy  jó munkaeszközzel dolgozni jobb, mint vacakkal, és aki eheti, az a jobb munkakörülmények miatt simán vált munkahelyet - egy ilyen váltás mekkora Forintban kimutatható kárt okoz a cégnek azzal, ha pl. a vezető fejlesztő lelép, mert sz@ gépet raknak elé.

Tudom, nálad a 16giB az már szentségtörés

A szentségtörés az, amikor kifejezetten azért kell 16 GB, hogy az önmagában 8 GB-ot felzabáló Electron bloat elfutkározzon rajta.

a 8 is olyan, hogy "de mi a fenének, mikor bithegyezéssel a fele sőt a negyede is elég lenne, de akár 640k-ban is el lehetne lenni"

https://a.te.ervelesi.hibad.hu/csuszos-lejto

Az a helyzet, hogy a jelenleg piacon elérhető desktop (és desktopnak hazudott Electron szutyok) alkalmazások által elvégezhető feladatok komplexitása távolról sem indokolja a szóban forgó erőforráséhséget. Egyedül a babzsákfejlesztők kényelmeskedése indokolja ezt és az is csak multiéknak, akik túl milliárdosok optimalizálni.

csak azt nem veszed észre, hogy ezeknek a szerinted "must have" CPU és RAM-optimalizálósdiknak igen-igen magas a költsége

Te meg azt nem veszed figyelembe, hogy ha tervezési fázisban erős szempont az, hogy ne legyen bloat és régi, erőforrásszegény hardvereken is fusson, akkor nem lesz magas az optimalizáció költsége, mert eleve nem egy bloated frameworköt kell a végén csűrni-csavarni-faragni, hogy leszorítsd a memóriát. Mert én erről beszéltem, ha nem tűnt volna fel.

Te vennél olyan mondjuk irodai szoftvert, ami 567890Ft, de elmegy mondjuk 2GiB memóriával, és tudja mindazt, amit egy aktuális MS Office?

Vennék, mivel ezzel 2006-2008 óta 4-5 munkaállomás költségét megspórolnám (ami jóval magasabb, mint 567890 Ft) és a rengeteg környezetszennyezést, ami a legyártásukkal, 6000 km-ről idepöfögtetésükkel, 3 év után működő állapotban kidobásukkal, újrahasznosításukkal jár.

Házi feladat: számold ki, hogy ha csak az ideje 10%-át fordítja arra a fejlesztő, hogy a build/teszt lefusson, az mennyibe fáj a munkáltatójának, illetve mennyit hoz a konyhára megtakarításként az, ha ezek a holtidők a korszerű munkaeszköznek hála mondjuk feleződnek

Kerekítési hiba az említett milliárdos multik költségvetésében. Nagyjából annyiba kerül, mint amikor Elon Musk rakétája beleáll a földbe és felrobban. Belecsődöltek? Nem. A Microsoft se csődölne bele, ha 2 GB RAM-ra és 10+ éves gépekre optimalizálnák az alkalmazásaikat a mostanival azonos funkcionalitást megtartva.

A CI nem haszontalan, de a "full coverage" és az energiatakarékosság között alapvető ellentét van. A legkisebb elengedhetetlen teszthalmaz megállapítására kellene törekedni. A normál fejlesztési folyamatban amúgy is szerepel integrációs és egyéb teszt; az ilyen teszteredmények érvényességét kellene adott esetben átmenteni a beolvasztás idejéig. Illetve le kell nyelni, hogy az energiatakarékosság ára néha az, hogy a lefedettség hiányos, és emiatt regressziók vannak.

Megfelelő instrumentálás mellett ezt simán lehetne automatizálni. Ha az összes tesztedről tudod, hogy melyik sorokra fut rá, akkor azt is tudod, hogy a megváltozott kóddal melyik teszteket kell lefuttatni. Nem tudom, hogy csinált-e már valaki ilyet, de az eszközök szerintem rendelkezésre állnak. A kérdés csak az, hogy az extra tooling miatt nem kellene-e ehhez több erőforrás, mint simán lefuttatni az összes tesztet. Unit tesztek egy közepes méretű projecten egyébként sem kellene, hogy néhány másodpercnél tovább fussanak.

Integrációs/E2E tesztek meg soha nem fognak teljes lefedettséget adni a tesztpiramis miatt. Lassabbak is, több erőforrás is kell nekik, ezért inkább ezeket próbálnám ritkábban futtatni.

Ami még fontosabb: végre fel kell ismerni, hogy a CI nem helyettesíti az alapos peer review-t. A github ebben a tekintetben elképesztő károkat okozott a fejlesztési morálban és folyamatokban. [...] A peer review valóban nagyon nehéz, és szűk keresztmetszetet is jelent, de a környezeti lábnyoma elenyésző (etetni, itatni, aludni hagyni kell a reviewer-t). Alapos kódbírálat jó hatékonysággal meg tud fogni regressziókat. Ez valóban lassítja a fejlesztést, de az miért baj? Megint ott vagyunk, hogy"time to market", vagyis a lehető legtöbb $$$ kihúzása egységnyi idő alatt.

A CI nem csak a regressziók csökkentésére jó, lehet vele code stylet, test coverage-t, egyéb nem funkcionális dolgokat ellenőrizni, mindezt szinte valós időben. Így egy PR el sem jut review-ig, amíg a formai követelményeket nem teljesíti. Egy alapos review egy nemtriviális kódon minimum fél óra. Fejlesztőként, ha aznap még dolgozni is akarok, praktikusan nem tudok egy nap 2-3-nál több reviewt csinálni (szerencsére nem is kell). Ha ezen felül még az ilyen apróságokkal is foglalkozni kell, az növeli a review idejét, növeli a visszadobott PR-ek számát, ezáltal növeli a review-k számát. Arról már nem is beszélve, hogy egy gépnek nehezebb ellentmondani, mint egy embernek (pl. ha nem tetszik a code style).

A CI nem csak a regressziók csökkentésére jó, lehet vele code stylet, test coverage-t, egyéb nem funkcionális dolgokat ellenőrizni, mindezt szinte valós időben. Így egy PR el sem jut review-ig, amíg a formai követelményeket nem teljesíti.

Egyetértek, viszont ezeknek a követelményeknek az ellenőrzése nem igényel sok energiát (gépidőt).

Egy alapos review egy nemtriviális kódon minimum fél óra. Fejlesztőként, ha aznap még dolgozni is akarok, praktikusan nem tudok egy nap 2-3-nál több reviewt csinálni (szerencsére nem is kell).

Gyors vagy; én, ha igazán komplex kódot nézek (vagy valamilyen specifikációval kell részletesen összehasonlítanom), van, hogy önálló patch-enként töltök el 1 órát. (De májusban volt olyan önálló patch is, amivel 2 órát töltöttem.) Korábban volt olyan hetem, amikor egész héten mást nem csináltam, csak napi ~10 patch-et néztem át egy nagyon nagy patch series-ből.

Ha ezen felül még az ilyen apróságokkal is foglalkozni kell, az növeli a review idejét, növeli a visszadobott PR-ek számát, ezáltal növeli a review-k számát. Arról már nem is beszélve, hogy egy gépnek nehezebb ellentmondani, mint egy embernek (pl. ha nem tetszik a code style).

Teljesen igazad van, de ez akkor is oda vezet, hogy inkább a gépet dolgoztatjuk meg tízszer, mint magunkat egyszer -- és ennek nagyobb a környezeti terhe. Senki sem vitatja, hogy az automatizáció, gépesítés kényelmes (és jövedelmező).

Én azt gondolom, hogy mind CI-ra, mind peer review-ra szükség van, de egyiket se vigyük túlzásba azért, hogy a másikkal spórolhassunk. Én sem szeretem, amikor a coding style hibák miatt tompulok el egy egyébként hasznos patch sorozattal szemben, de az is nonszensz, hogy mennyi CPU időt fel tud zabálni a CI-ban egy kicsi patch set build test-je és unit test-je (20 perc folyamatos tekerés simán lehet 4-8 szálon, projekttől függően).

Reviewer-ként az ember akkor kezd a CI után kiabálni, amikor annyi bírálatot varrnak a nyakába, hogy nem bírja aggyal, vagy nem bírja mellette elvégezni a fejlesztői feladatait. Ami ugyanaz a probléma: a fejlesztő/bíráló túlterhelése (amit gépesítéssel próbálunk enyhíteni, és a környezet szenvedi meg) ugyanarról a tőröl fakad (minél rövidebb idő alatt minél több patch befogadása).

Ma már követelmény a fél univerzumot újrafordítani és ötmillió automatikus tesztet lefuttatni minden topic branch beolvasztásakor.

Elég rosszul szervezett CI folyamat lehet ez, nem csoda, ha ennyire nem szereted. :)

Illetve le kell nyelni, hogy az energiatakarékosság ára néha az, hogy a lefedettség hiányos, és emiatt regressziók vannak.

A millió dolláros kérdés pedig az, hogy melyik környezetbarátabb:

  1. minden merge előtt egy automatizált teszt csomag, release előtt adott esetben valami részletesebb
  2. utólag fixálni a hibákat, és adott esetben elhárítani az okozott károkat

végre fel kell ismerni, hogy a CI nem helyettesíti az alapos peer review-t

No arguments here, de ki mondott ilyet egyáltalán?

Alapos kódbírálat jó hatékonysággal meg tud fogni regressziókat.

Az ember téved. Gyakran. A code review szükséges, de egyáltalán nem váltja ki az alapos, jól átgondolt teszteket.

A millió dolláros kérdés pedig az, hogy melyik környezetbarátabb:

Valóban jó kérdés -- az biztos, hogy az az olcsóbb, ha a folyamat minél korábbi részénél elkapjuk a hibát. Hogy melyik a környezetbarátabb, azt nem tudom.

(nem tudom, hogyan lehet többszintű idézetet készíteni:)

>> végre fel kell ismerni, hogy a CI nem helyettesíti az alapos peer review-t

> No arguments here, de ki mondott ilyet egyáltalán?

Ez nyilvánvaló abból, hogy a github / gitlab WebUI mennyivel gyengébb eszköz a részletes code review-ra, mint a rendes email (git-format-patch, git-send-email). Nagyon hosszú és nagyon részletesen megvizsgált, több projektet érintő workflow váltásban vettem részt; teljesen egyértelmű számomra, hogy a "git forge" módszertan arra helyezi a hangsúlyt, hogy gyorsan olvasszunk be mindent, minél több contributor tudjon minél hamarabb csatlakozni, a code review másodlagos, a tesztek majd megfogják a hibákat. A squash-on-merge ennek tökéletes szimbóluma -- tökéletes jele annak, hogy a "git forge generációnak" nem jelent szinte semmit egy patch series szerkezete, sorrendje, evolúciója több verzión keresztül, illetve az eredményként létrejövő git history alkalmassága a biszekcióra (git-bisect), regresszió esetén. Például (tudtommal) sem a gitlab, sem a github WebUI nem kínál a mai napig a git-range-diff paranccsal összemérhető funkciót (amely egy több patch-ből álló sorozat inkrementális (v1, v2, v3...) bírálatánál kritikus); ennek üzenete egyértelmű.

A "git forge generáció" elsősorban működő(-nek látszó) kódot akar, amit esetleg át lehet nézni.

Az email alapú review-ban hívő generáció elsősorban emberek számára ír olvasható, részletesen dokumentált, minimalizált patch-eket, ahol a vezérelv az, hogy az olvasót (reviewer-t) lépésről-lépesre vezetve okítsuk, mintegy mellesleg felépítve a megoldást. Kódot nem a számítógépnek írunk, hanem a többi programozónak. Amikor a patch-et készítjük, az csak a nulladik rendű kérdés, hogy "hogyan írjam meg". Az első rendű kérdés az, hogy "hogyan értessem meg a reviewer-rel"; ez a fontosabb szervező elv. Egy patch akkor van kész, amikor már nincs mit elvenni belőle.

Nem azt mondom, hogy a "git forge módszertan" teljesen leszámol a review-val, de a hangsúly abszolút máson van. Számomra eltéveszthetetlen a különbség.

Mi köztes megoldásként (a gitlab-ra költözéshez, de a szigorú-gondos review eszközök / workflow megtartásához) külön projektet csináltunk / indítottunk: https://gitlab.com/bichon-project/bichon (ld. különösen a History / Motivation részt).

A code review szükséges, de egyáltalán nem váltja ki az alapos, jól átgondolt teszteket

Egyetértek, csak én úgy érzem, átestünk a ló túloldalára.

az az olcsóbb [...] Hogy melyik a környezetbarátabb, azt nem tudom.

Erre van egy klasszikus megoldás: úgy kell a dolgok árát meghatározni, hogy az tükrözze az externáliákat. Azaz ha valami környezetet pusztító dolog, akkor annak legyen pénzben kifejezhető ára (pl. adó, büntetés), és az legyen arányos a pusztítással. És máris összevethetők a dimenziók.

( BaT | 2021. 05. 31., h – 18:49 )

Szerkesztve: 2021. 05. 31., h – 18:51

Szerk.: átraktam a választ ide.

( turul16 v | 2021. 06. 08., k – 08:23 )

Vegre betiltjak a szerver oldali php/python/javascript/.. -et  ;-)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.