https://techcrunch.com/2018/07...r-real-passwords-to-trick-you/

I da, jeste pass koji sam koristio tipa 10-15 godina :D (pametno, znam)




Dakle moze biti i ovo i da nikakve veze sa GRUB2 nema (bar sto se mog zaeba tice :D )...

Koristio si istu šifru i za gomilu (ne)bitnih servisa? Ako jesi, onda je to verovatno mesto gde su je pokupili, a ne tvoj PC

Proveri i ovde
https://haveibeenpwned.com/Passwords
https://monitor.firefox.com/

Pamet u glavu i Password Manager na PC

Jel postoji takav "Pasword Manager" i za WIN7?

Ne znam, pa pitam.
Ako ima neko volje da pomogne...

Izvinite sto to pitam u Linux temi,
ali je nekako povezano.
pOz

@SpaceBeer, moguce je i to, ko ce ga znati... ima sifre na prvom sajtu, a drugi javlja Last.fm i LinkedIn za known data breaches za moj mejl... 2016. godine :D

...no to je off-topic.

Nije baš veliki off-topic. Prosečan korisnik ne mora mnogo da brine, samo da ažurira svoj OS redovno. S druge strane, ponovo se vidi koliko đubre je UEFI sa svim svojim secureboot mehanizmimima. Izmišljanje tople vode i još jedno mesto za napad na našu sigurnost ;)

@Living Light
https://www.privacytools.io/software/passwords/
Možeš pogledati i Firefox Lockwise, ako koristiš FF

e ulopsao si mi dan

https://nakedsecurity.sophos.c...ole-bug-what-you-need-to-know/

Apdejtujem sve bukvalno cim izadje, sistem mi je uvek up to date,
nego ono cinjenica da je neko tamo imao pass... neka fala, ide ceo OS
za svaki slucaj, kakvo menjanje boot-loadera :D

I pre toga sa live flesa dd-om jedno gigabajt nula na pocetku SSD-a
da od EFI particije ne ostane ni traga ni glasa :D

Postoji, ja koristim KeePass Password Safe ( https://keepass.info/ ) na kompu pod Windowsom i KeePass Droid na Android telefonu, oba mogu da koriste istu bazu šifara pa kad promeniš neku šifru na kompu, onda bazu sa šiframa uvezeš na telefon i imaš iste šifre na oba uređaja. Naravno, pristup obema bazama je pod šifrom!
Program ima verzije i za Linux, i za Mac OS X, iPhone/iPad, čak i za one stare nepametne mobilne telefone!

Pardon zbog offtopica!

Brate buffer overflow je u GRUB-u a ti pominjes EFI? WTF?

EFI je sistemski firmware, danasnji sistemi ne mogu da se bootuju sa BIOS-om zato sto samo inicijalizacija procesora zahteva kod kompleksniji od svih BIOS-a zajedno.

Da nema UEFI-ja, to bi radio OS. Nikakve razlike ne bi bilo osim sto bi to bilo sppektakularno bacanje resursa, opet bi imao BLOB-ove, sistemski kod najnizeg nivoa (UEFI "PEI" moduli) koji je napisan samo jednom: za konkretnu platformu (tipa Intel Skylake + Lewisburg, tj. Purley) sto znaci da je testiran tacno onoliko koliko mora.

Postavlja se pitanje i koji djavo bi to OS morao da radi. Prva stvar koju OS uradi posle bootloadera je ucitavanje kernela.

Gde ces kernel da ucitas dok ti procesor jos nema ni pristup memoriji (radi u "Cache as Memory" modu), u MP sistemima imas samo "boot" socket aktivan, nemas PCI express, nemas ni jedan periferni uredjaj inicijalizovan, nemas pojma ni koliko memorije imas (jos manje kako da joj pristups)?

U toj fazi podizanja sistema, koja bi uopste funkcija bila kernel-a za nesto sto nema 90% komponenti koje kernel koristi? I sta bi tacno taj kernel doneo sto bi nazvao nekom dobiti? Ko ce da ga koristi? Za sta? Pisanje u fajlove.. oops! Alokaciju memorije... oops. Drajvere... oops.

Sta, neko planira da trci multithreaded kod u L2 kesu i na jednom procesoru? Treba mu mapa sistemskih poziva koji qr*u ne sluze niti ima ko da ih zove?

A da, posto jos nemas niti pristup disku (posto nemas ni PCIe magistrale) odakle ces da ucitas kernel? Iz flash ROM-a? OK...

Znaci "kernel" koji zapravo nije kernel i koji se ucitava iz flash ROM-a i trci proprietary platformski kod?

Zvuci bas kao... UEFI?

Ja sam ga pomenuo jer ako mi neko ownuje masinu moz da menja i sadrzaj
efi particije verovatno, pa bih je zato radije skrljao i prepustio sveze instaliranom
i patchovanom boot loaderu da sa nje cita novi sadrzaj jer ko zna sta je i po
toj particiji moglo biti prckano :D

Nije baš jasno, da li se radi o bug-u u firmware-u ili grubu...

Pazi, nema nista specijalno u EFI particiji - 0wnovanje bez da znas mozes da zahvalis CPU proizvodjacima koji vec godinama u procesore ugradjuju funkcije koje sluze pre svega na sistemima koji imaju vise musterija (vlasnik, neko ko iznajmljuje CPU, neko ko izvrsava svoj softver).

Sve je to super u serverskim/cloud/DC sistemima, ali kad se to primeni na kucne racunare ili mobilne telefone to obicno znaci "vise babica" gde ti (vlasnik) otprilike imas jednaka (u najboljem slucaju) ili manja (u dobrom delu slucajeva, tipa mobilni ARM sistemi) prava od ostalih "musterija".

Kucni PC racunari se jos donekle drze - dokle, pitanje je.



Brate, bug je u GRUB-u. Dodatni "bug" je u idiotskom sistemu verovanju raznim "shim" bootloader-ima sa jednim kljucem, sto je bio kompromis izmedju platform vendora i "Open Source Komune" (stagod). Da ne bi komplikovali stvari, Microsoft je kreirao jos jedan kljuc sa kojim su potpisani svi "shim" bootloaderi koji ucitavaju OSS bootloader-of-the-day kao i kernel itd.

Naravno cela ta stvar ocigledno ima fatalnu manu, za sta ti ne treba PhD iz kriptografije: jedan kljuc za sve 3rd party bootloadere. Ali posto bi "Open Source Komuna" vristala "ubistvo" za bilo koje drugo resenje, to je to sa cime zivimo u PC industriji :-)

Naravno kada je konacno neko nasao rupetinu u GRUB-u danas, istom GRUB-u potpisanom sa jednim jedinim kljucem koji postoji, saberi 2 i 2.

Za to je kriv UEFI, ko drugi :-)

Ne znam ja na desktopu koristim BIOS, zato sto ne volim da imam dodatnu particiju samo radi boot-a ;)

Inace bug je fantasticni buffer overflow dok GRUB cita config file.



Brate mili, bootloader jbt - upada u komu citajuci config fajl i dozvoljava "arbitrary execution"... 2020: 1999 zvala i hoce svoj String I/O nazad :-)

"Krivica" UEFI konzorcijuma je sto su uopste prihvatili ovako idiotsku ideju (da jedan kljuc bude koriscen za sve 3rd party bootloadere, sto ga efektivno cini "too big to fail" tj. "too big to revocate").

A, da, UEFI nema ni mehanizam automatske revokacije kljuceva. Revokacija postoji, ali ce da se desi kad neko apgrejduje firmware (mislim...).

Mada, sta ce im uopste automatska revokacija kad imaju jedan kljuc za pola sveta :-)

Plus, sta god dodatno da su ubacili imali bi Richarda Stallmana za petama. "Bloody murder!".

Znači hakeri...

Baš sam se pitao zbog čega pre neki dan Ubuntu nije hteo da mi se učita. U konzoli vidim da pokušava da jedno 30 puta startuje sesiju, bezuspešno. Editovao sam GRUB tako da startuje neku stariju verziju kernela i proradilo je.... ali sad se ne osećam sigurno.

^^ to verovatno nema veze sa ovim bugom

Znaci bug u grubu...

Bug?



Jos jednom ^ ovo ^ je >bootloader< - iako po listi bagova vise lici na web browser u 2020 bog te mazo :-)

E, sad, da je "SecureBoot" kompletno smisljen feature, sa automatskom revokacijom kljuceva i svakim bootloader-om sa svojim (bar vendor) kljucem, problem bi vec bio odavno resen, moduli blacklist-ovani, ako treba i kljucevi revocirani.

Ali posto je SecureBoot cirkus osim ako sam vlasnik ne gospodari kljucevima (dakle, ne koristi tudje) sto verovatno radi <0.1% ljudi, onda je cela stvar upravo ovo sto jeste.

Bez obzira, ne treba gubiti stvari iz vida: pre svega, GRUB je ocigledno hrpa bagova, za pocetak.

UEFI SecureBoot je, takodje, polu dovrsen feature, sto ne cudi kada je jedna od odgovornih strana Microsoft. Mada situaciju ne cini nista boljom cinjenica da su morali da zadovolje i hrpu... "aktivista". Aktivizam i softver ili generalno bilo kakav rad koji zahteva intelekt cesto ne idu zajedno :(

Nemo se sekiras, dokle god je C programera i C/C++ :P

Sta, mislis da bi bootloader pisan u JavaScript-u bio bolji? :-)

Eto ideje za novu verziju UEFI-ja - dodati i JavaScript engine.

Krene sistem da se boot-uje i onda se zakuca zato sto je npm izbrisao modul koji... sta znam, proverava da li je broj paran jbmliga.

Meni licno smeta i sto se danas po BIOS-u klikce misem.

Hehe, da, umanjuje ozbiljnost situacije :)

Boljaka C-a su jedni te isti bagovi. Uzme se staticki niz i onda neko ko to mejntejnuje to zaboravi. Nemas pojma kolko sam bagova
ispravio kada sam C staticke nizove zamenio za vektore :P

Nije u pitanju C vec qrcobolja.

Mozes zamenis C sa cime god hoces dobices isti klinac, sve dok ljudi ne kapiraju sa cim imaju posla. Nece te vektori spasiti od idiotskog programiranja koliko god se trudio.

Probaj da nadjes ovakve bagove u bootloader-u novih iPhone-a ili Pixel-a od Google-a. To ce malo teze da ide.

Apple-ov low-level bootloader nije menjan skoro, sastoji se od minimalnog payload-a koji je verovatno izresetan uzduz i popreko od provera.

Mozda GRUB ekipa ne smatra ovako nesto potrebnim, sto samo jos vise ukazuje na cirkus kao stanje uma PC industrije.

Ja lepo kazem da s tim nema problema ko ne restartuje Linux.
Linuxu restart ne treba. ;)
Ko je "dig'o" masinu pre otkrica bug-a , dig'o je. :)

OK, jedina dobra stvar ovde je da nije remote exploitable.... Ali sad ako ti neko zarazi masinu, postaje mnogo teze da ga se resis. Sto nije ni malo zabavno. Ali da, Ivan je u pravu, ovo samo govori o bolu u jednom predelu tela.... F/OSS community treba vise Linus-a i generalno likova koji nemaju problem da svima spomenu gospodja mamu....

Upravo, svetu treba vise a ne manje Linusa :-)

Kad neki sampion pokusa da commit-uje kod sa ovakvim ludilima:

https://access.redhat.com/errata/RHSA-2020:3216



Sta qratz, ko jos proverava koliko bajtova pokusavas da alociras... i to jos u bootloaderu :-) Smejali se ljudi Intel-u kad u Management Engine-u rade to isto, ironija bi bila da je u smejavac ekipi bio neko i od GRUB dev-ova :-)



Jbg, bogtemazo, da li su ovi ljudi culi, sta znam, za sanitizer? Linter? Ne smem ni da pitam da li rade fuzzing...

Linus bi im verovatno ruinirao karijere :-)

Imao sam kolegu, jedan od onih "1 u milion", na zalost ne medju nama vise. Lik dodje sa 6-meseci sabatical-a i posle prvog "radnog vikenda" obrise drugom kolegi 6 meseci rada zato sto je kod djubre, ode do njega i lepo mu objasni da mu je kod djubre i da ga je uklonio i raspisao bolji ekvivalent preko vikenda, i zamolio ga da ubuduce pre commitovanja pita za dozvolu.

Kolega (obrisani) ne bi idiot, nego je naucio nesto iz svega toga i danas pise vrlo pristojan kod.

Danas bi verovatno mogao da ode do nekog HR-a i da se pozali na listu prekrsaja :-)

nkrgovic i Ivan Dimkovic - posetioci iz paralelnog univerzuma. Tamo su kuće od čokolade, a prozori su od marmelade.

Ma idi, sta kazes?

Znaci Apple i Google mogu da napisu posten IBL, a FOSS “komuna” ne moze? Vidi kad je poslednji put neki Apple jailbreak bio vezan za bootloader (ima bar 10tak godina). I to nije zbog nedostatka motivacije.

Ironije :-) FOSSovci su najbucniji oko sigurnosti a najpopularniji FOSS bootloader ocigledno pun sampionskog koda k’o neka Excel tabela obogacena VBA “intelektualnom” svojinom...

Apple i Google mogu da napišu pošten... Ma, idi, begaj.

Kapiram ja da KISS princip doprinosi čistoći, tako da ako su pravljeni da budu jednostavni, to je u redu, ali to je to.

Ako je nađen propust u bootloader-u, čemu ograničavanje razmatranja sigurnosti samo na njih?

Tako je, kao i mali Bobby Tables.... Posto satanizacija inputa je nesto tako... cudno? Ili jednostavno nedostojno? :)

BTW, danas je 2020-ta. Dodati linter u git pipeline, koji ce da proveri ovakve stvari je posao od dan-dva.... Cak i fuzzing dodati u test pipeline je, ajde, nedelju dana posla, recimo, ako radi jedan covek i to ne samo to sve vreme. :) Ne prica Ivan o tome da nesto posebno fancy rade ljudi, bukvalno mozes da platis i dobijes static i dynamic application testing integrisan u gitlab - bilo on-cloud ili on-prem.

@Nedeljko,



Apple nudi do $1.5M ako nadjes 0day u iOS-u. Englezi imaju izreku "put your money..." i Apple to jako lepo demonstrira.

Ja imam daleko vise poverenja u moderni iPhone i Apple Pay nego u bilo koju drugu metodu elektronskog placanja i do sada nisam imao prilike da budem ubedjen u suprotno.



Ko ogranicava bilo sta? Razmatraj sigurnost cega god hoces.

Samo je slucajnost htela da "sampionizam" u GRUB projektu izazove cirkus. Onda je neko ozbiljan uradio security audit GRUB-a i otkrio jos nekoliko slicnih sampionskih stvari.

Ali iskreno, ja uopste ne krivim GRUB ekipu. Najvise odgovoran za sve ovo je sam Microsoft koji je uopste dozvolio da se njihov kljuc koristi za kojekakve "shim-ove".

No, to je nesto za sasvim drugu raspravu. I ti i ja znamo da je Microsoft ovo uradio na pritisak kojekakvih FSF-ova, EFF-ova, Linux Foundation-a i sl. Pravo resenje bi bilo nesto vrlo drugacije, ali avaj...



To Nedeljko iz nekog razloga ne prihvata. Mislim neki leavi deabeat-i mogu da ti zahtevaju sve ovo u ugovoru zato sto valjaju robu koja zavrsi u necemu sto moze da ubije druge (iako je to "sto moze da ubije" kontrolisano sasvim drugim sistemom koji je, samo sticajem okolnosti, u istoj kutiji).

Sve to danas mozes da dobijes sa standardnim alatima, integrisano u CI/CD pipeline.

I sad neko da kaze da ljudi koji razvijaju OS bootloader to ne mogu.

WTF?

Ok, mukice iz GRUB projekta to ne mogu ili ih boli djokica (recimo rade za svoju dusu). Ali ekipa koja to koristi? RedHat? Canonical?

Idi jbt. Ovo je da se jos vise smrznes onda.

@nkrgovic

To je kad neki admin zna da instalira alate, ali ne programira, pa nema pojma o tome šta ti alati zaista mogu, a šta ne.


@Ivan Dimkovic

Zatvaranje tehnologije za ulazak novih igrača je u suprotnosti sa kapitalizmom.

Ti alati bi ti vrlo verovatno ukazali na linije koda gde je use-after-free moguc.

Ako imas srece, mozda bi ti ukazali da pogledas i kod koji je odgovoran za buffer overflow, posto k'o sto Louis Rossman kaze, "fucker*y" se obicno lako nalazi zato sto ga prati lanac idiotizama.

Ako bas nemas srece, znas kako, da si raspisao unit testove koji ukljucuju i fuzzing i "hranjenje" tvojih API-ja sa golim djubretom kako u parametrima tako i fajlovima, vrlo verovatno bi ti softver pukao pre nego sto je instaliran na dobrom delu planete.

Ali sta mi znamo, siguran sam da je GRUB primer dobro raspisanog softvera :-)

Steta sto ga odaje malloc() bez provere velicine. Ekvivalent spaljenog konektora kod Louis-a - ako hoces da lociras nekompetenciju u sumi, nasao si je direkt.



Zatvaranje sto moras da imas svoj kljuc? Idi begaj.

Evo ja bas hocu da moja tehnologija bude zatvorena za budale ili bar da postoji lak nacin da se puste niz vodu.

Zato mi vrlo odgovara App Store model, kad kupujem nesto tamo znam da je sansa za kriminal smanjena zato sto postoji lanac odgovornosti i odrasli ljudi koji ciste radnju od djubreta.

Da, defanzivni deo programiranja najcesce nije adekvatno pokriven od strane QA, a po najmanje "auto, plug and play" testiranjem. Jbg, mora "oko sokolovo". Na zalost to se ne uklapa u industriju danas.

Što je u opštem slučaju Tjuring ekvivalentno problemu zaustavljanja Tjuringove mašine, za koji znamo da je Tjuring nerešiv.

Naravno postoje dovoljni uslovi za buffer overflow, koji su Tjuring izračunljivi i to je ništa drugo do detekcija lakih specijalnih slučajeva. Međutim, pričati "vrlo verovatno", a da se ne zna o čemu se radi je ništa drugo do pričanje napamet.

Poenta automatskog testiranja nije da resi 100% problema, poenta je da se uspostavi proces koji:

- Definitivno potvrdi trivijalne probleme
- Pokaze na moguce postojanje potencijalnih problema
- Natera coveka koji je "in the loop" da mora to da pogleda i makar da klikne "OK, ja, Glavni Arhivator, svojim imenom i prezimenom, tvrdim da je ovo OK".

Jednom kad imas takav proces, onda onaj koji komituje, plus onaj koji radi code review, moraju da potvrde da misle da je to OK. Dva para ociju, koje moraju i da stoje iza onoga sto su napisali. Ovaj deo gde mora da postoji code review je isto ultra-bitan, samo to ti garantuje dva para ociju. Dodaj tu obavezno pisanje unit testova i obavezno testiranje funkcionalnosti i imas developera koji dok radi nesto mora da misli i o tome kako izgleda test i da li ce kod proci test. Bukvalno teras ljude da misle na kvalitet onoga sto pisu.

Da, desavaju se problemi i kad imas ovakav proces - naravno da se desavaju. Ali, desavaju se manje. Mnogo manje.

licno iskustvo:

Meni je ovo bas dosta promenilo nacin rada - kad imas slozen sistem, onda imas i infrastrukturu koju treba provisonovati za test, a to jedino moze ako imas infrastructure as code, pa onda i to mozes (zapravo moras) da testiras. S'druge strane, kad pocnes da mislis o tome da ce ti se instacirati novi app server svaki put kad neko pokrene test, vrlo brzo dodjes do sistema koji instancira taj app server apsolutno savrseno - i onda vise nemas problem kad treba da prosiris funkcionalnost na npr. autoscaling, jer provisioning za taj autoscaling vec imas napisan. Ne samo da stedis vreme, vec i ne testiras u produkciji, jer si, dok si podesavao test env, izvrteo ceo sistem toliko puta da si ga prilicno dobro istestirao pre nego sto je video produkciju.

U pravu si Nedeljko. Ja ne znam o cemu pricam, ocigledno se nisam pripremio i uzeo u obzir teoriju izracunljivosti i pljucnuo sam nasumicno "vrlo verovatno" ne znajuci uopste o cemu se radi, kamo li o tome sta ja uopste pokusavam da kazem.

U realnosti, GRUB ekipa odavno koristi praksu koja je postala moderna cak i u levom kodu danas, a kamo li za nesto kriticno za sigurnost.

Tako oni lepo razvijaju kod sa procesom koji ukljucuje staticku i dinamicku analizu, kao i unit-testove koji testiraju odredjen (izracunljiv, recimo koliko mozes da ih ispucas 24/7 na hardveru pristupacnom jednom RedHat-u) slucajeve van specifikacije metodama kao sto je fuzzing.

Uprkos svemu tome, eto, zadesio ih je upravo slucaj koji ce Nedeljko sigurno vrlo lako objasniti fundamentalno, iz teorije - ocigledno, nedostatak provere velicine pre alokacije je upao u "ooooooooooogromnu vecinu" (beskonacnost) funkcija koje nasa jadna metoda provere ne moze nikako ni da zagrebe. Gde mi je bila pamet!

Jel dobro do sad? Drzao sam vazduh :-)

HAHAHHAHAAHAH!

Nedeljko, mojne za*ebavas - GRUB kod je djubre pisano bez sigurnosnih pravila a kamo li nekog ozbiljnijeg procesa. Zbog toga bi nekoliko elementarnih stvari (danas) sasvim lepo hvatalo "ogromnu vecinu" ovozemaljskih problema, kada bi se potrudili da posteno prodju kroz djubre. OK, Turing bi se i dalje vrteo u grobu i pominjao sve moguce slucajeve koji bi i dalje bili moguci, ali da se kladimo da bi se to prevelo u - "prakticno, apsolutno nebitno" (u kontekstu ovog softvera).

Ne verujes? Evo ti jedan: http://git.savannah.gnu.org/cg...8287ed3af32fffe8aaf33cdff52f6b

Sta kazes, provera pointera pre free() zakucava tvoju Turing masinu? Brate, vreme ti je za upgrade masine. Svaki cestiti alat za analizu koda bi lupio samar coveku koji ovo commit-uje, mislim da smo vec odavno prevazisli "warning" poruke.

@nkrgovic:
Hell yes, vecina tako radi ili konvergira procesu koji si opisao.

E sad, batica iz QA koji unit testovima pogadja ko iz snajpera, taj ce bato u dev tim iz odmah, a na njegovo mesto ..... Plus tu je i psihologija grupe, koja navija da nesto radi a ne da ne radi, tako da je taj proces daleko od idealnog. E sad ako imas old gold school, tipa ovog Dimkovicevog kolege, koji sabije 6 meseci u 2 dana vikenda. Nije to samo talenat, znanje, inteligencija itd. to je ogromna posvecenost i zelja.

Rekoh, zavisi od jezika. C je takav pa takav, ne trpi sloppy progamiranje... no ono sto je najveci problem je da trazi bas takvo programiranje.

Ivan:"Sta qratz, ko jos proverava koliko bajtova pokusavas da alociras... i to jos u bootloaderu :-) Smejali se ljudi Intel-u kad u Management Engine-u rade to isto, ironija bi bila da je u smejavac ekipi bio neko i od GRUB dev-ova :-)"

Pa hm, koliko treba da alociras da probijes heap? Mislim ovo bas i nema smisla. Osim ako neko ne uvali takav kod, mislim ovo je vise kao debug varijanta nego nesto sto bi islo u release...
Ok niko ne spori da C programer nikad ne provera na NULL, na array bound i slicno...

To zavisi ko vodi tim. Prvo, unit testove obicno pisu sami developeri (obicno juniori) ne QA, QA team obicno pise funckionalne / acceptance testove, ako imas jako dobar QA team koji cine zapravo programeri onda pisu i integracione testove..... Drugo, sve i da imas programera u QA team-u, koji pogadja k'o snajper, zasto bi ga, aman, selio u dev team? MNOGO ti je korisniji u QA timu. :)

Psihologija grupe... Gledaj, ovaj proces treba da vodi promeni kulture. Kultura nije "idemo u kafanu, zovemo to team building" ili "idemo na meditaciju da nam se uskladi chi dok pijemo almond latte chai" - vec da promenis kako se razmislja o procesu rada. Bitan deo toga je da sve bude pokriveno testovima - i da sve radi. Dobro postavljen tim navija da nesto radi - ali to nesto su i testovi. :) Sustina je da se tim usmeri da radi kao tim. Ovo zahteva ceo devops proces, realno fuziju timova, kao i blameless post mortem - cilj je da ljudi dobiju motivaciju ne "da sve radi" vec "da sve poprave". Da budu odgovorni (idealno i ponosni) prema kvalitetu onoga sto proizvode - i trude se da isporuce najbolje moguce. Ovo nije jednostavan proces, ne radi se za mesec dana - ali daje super rezultate. Samo trazi vreme i posvecenost....

Old gold likovi nisu ovde problem, stavise takvi likovi su pure gold ako znas da ih hendlas, ali lako mogu da postanu i single point of failure.... Opet, sve zavisi od toga da li znas sta radis i kako to radis. Ako su dovoljno matori pomoci ce i oni sami da budu korisni i nece dozvoliti da budu SPOF vec ce sami da rade kako treba. Ima i likova koji su bezobrazni i koji namerno to prave od sebe (koje imo dobar management izbaci napolje sto pre).

Ono sto treba razumeti je, a to je i Ivan vise puta pricao: Odgovornost za uspeh je na managementu. Pojedinacni programeri su zamenjljivi i sustinski nebitni kao pojedinci, tim mora da funkcionise bez obzira na to. Odgovornost za uspeh snosi management i oni su duzni da obezbede i da je projekat dobro postavljen i da postoji proces i kultura. U komercijalnim projektima board drzi ceo rizik i odgovara vlasniku / akcionarima. Na zalost, u mnogo F/OSS projekata nema management-a i zato je sve ostalo kako jeste - i zato ovakvi problemi. Razlog zasto je Linux kernel super projekat je sto je Linus odlican tech manager, ne odlican programer. Mozda malo nekonvencionalan, sigurno ne "sensitive", ali efikasan.

edit: Ovo je @dejanet - isece me Bane. :)

https://www.zdnet.com/article/...across-multiple-linux-distros/

I kako se slabo testira sledi....

Mislim da FOSS programeri QA rade tako sto puste kod u divljinu a onda useri otkrivaju regresije :P

A tamo na linku neko zamenjuje "free(ptr);" sa "if(ptr) free(ptr);", što je konačna potvrda da Ivan Dimkovic ne zna šta priča.

Komanda "man 3 free" daje


Dakle, to "if(ptr)" ispred "free(ptr);" je pleonazam.

Nedeljko sa time vidis koliki je kvalitet tih programera :P
Ziasta if(ptr)free(ptr) nije nikakva ispravka, osim naravno ako ti sam ne implementiras free :)
Mislim mi ne znamo da li se ta verzija free koja je u grubu oslanja na klasican free ili je custom implementacija?

@nkrgovic

Sve sto si napisao je "by the book", stos je sto ne funkcionise najbolje.
Test driven development ili kako se vec zove je po mom skromnom misljenu i osecaju, losa stvar, jer mesa odgovornosti i generise neefikasan proces. Ekvivalent u programiranju ti je code duplication i krsenje separation of concerns ili koji je vec pravi izraz. To je ono sto programerski um misli o tome.

To da sve treba biti pokriveno testovima i da to treba da dokaze ispravnost rada aplikacije je nonsens, plus ako veliki deo tih testova pisu ljudi koji su progrmirali tu aplikaciju, pa to druze treba zabraniti zakonom uz krivicne sankcije :)
Mislim da je u vecini oblasti to i zabranjeno zakonom (gradjevinarstvo, masinstvo, bankarstvo..)

Sto se organizacije, timova, psihologije grupe itd. tek tu nema nikakvih smislenih odgovora, pa se kao resenje pominje promena kulture, motivacija, korisnost pojedinca.... pa ide dug csv, te na kraju imamo i code of conduct i slicne ludorije. Stos je sto ove i srodne metodologije nemaju organizacione i procesne odgovore, pa su delegirali pricu na opsta mesta spomenuta gore. Zasto nemaju odgovore, pa zato sto su te metodologije prepisane iz druge industrije-automobilske i iz druge kulture - japanske, plus ljjudi koji su se bavili i bave se ovom pricom apsolutno pojma nemaju o organizacionim naukama.

Kazes da su programeri zamenjivi i nebitni, ok, praksa govori drugacije. Menadzment, programeri, qa, admini, dizajneri, knjigovodstvo itd.. svi imaju proporcionalne zasluge ucescu u kreiranju, kvalitetu i prodaji proizvoda. Da li ce se sysadmin ili manadzement baviti kvalitetom aplikacije, hmm tesko, mnogo tesko.

To se lepo vidi po velikim firmama, koje su deo testiranja prepustule masama korisnika, a kao rezultat potpunog sloma tog procesa o kojem pricamo.

Branimir Maksimovic


Da, ubacivanje "if(ptr)" ispred "free(ptr);" i pisanje funkcije koja radi samo to je neznanje koje samo troši dodatne CPU cikluse. Međutim, nisi obratio pažnju na kontekst, a to je

Dakle, Ivan Dimkovic smatra da treba lupiti šamar čoveku koji ne stavi "if(ptr)" ispred "free(ptr);" i sa takvim "znanjem" C programiranja ovde pametuje.

Druga stvar: Malopre nakucah kod koji opisuje neizbežne situcacije u C programiranju. Dakle, tu nikakav analizator ne sme da vrišti jer sledeći kod nema čistiju zamenu kada je C u pitanju. Prilažem ga kao fajl.

Treba se samo malo poigrati direktnim pristupom poljima strukture ili napraviti bag u funkcijama za operacije datim tipom, pa dobiti buffer overflow, koji nijedan analizator neće da detektuje. Ovo je sasvim realno programiranje, štaviše neizbežna situacija u većini C programa.

Da ne pričamo o složenijim situacijama, kao što je custom alokacija. Ovo je nešto najprostije što treba u svakodnevnom C programiranju.

Dakle, ovde prosipaju pamet ljudi koji nemaju iole svežeg iskustva u profi programiranju. Nego, "Postoje moćni alati, superprocedure.", te ovo, te ono.

@dejanet:

Ovo o cemu pricam nije tdd. Tdd je stranputica, jer tera ljude da prave kod koji prolazi testove - a ne sisteme koji rade. :)

Ne kazem da pisu ISTI ljudi - samo da unit testove pisu programeri. Obicno mladji, kao deo ucenja... u svakom slucaju neki drugi.

A sto se tice kulture, odgovornosti i zamenjljivosti: Svi su zamenjljivi. Poenta je samo da je odgovornost ovaj "put your money where your mouth is" proces. Onaj ko je ulozio pare snosi odgovornost. Moze na druge da prenese ovlsacenja ali na kraju dana on je odgovoran i on gubi. :) Ne zaboravi, konacni sud kvaliteta aplikacije/proizvoda je prodaja, a to utice na novac koji ide u dzep onoga ko je novac dao. Zato je samo on nezamenjljiv i zato on snosi rizik i zato on u kranjoj liniji brine o kvalitetu.

Kultura je... nesto sto se pravi i neguje. Nije naivno. Sustina je da se mora generisati primerom. Ne postoji "metodologija", nema tog psihologa, HR-a ili koga vec ko moze da donese kulturu - to mora da postoji u timu, mora da ide odozgo nadole i mora da se prenosi licnim primerom. Apsolutno svi su bitni, to stoji - ne shvataj me pogresno. Sustina je da svako to mora i da oseti, bukvalno junior dev, koga uvedes u projekat i das mu da pise unit test za neki nov kod, on mora da shvati da je to sto on radi deo neceg veceg i da je i tu bitan kvalitet. To sto je on zamenjljiv ga ne cini nebitnim, to nije isto.... Odlican si primer dao, bukvalno je knjigovodja ultra-bitan i on mora toga da bude svestan. Cela ova prica je jako teska za svesti je u par recenica na forumu.... I da, code of conduct i slicno nemaju blage veze sa ovime. Sa ovime ima veze da, ako nesto ne radi, CTO i CIO su prvi koje budi telefon, onda oni sedi nocu i resavaju problem. Takve stvari. To je code of conduct, responsibility i leading by example. I da, dobar CIO i CTO ne treba da imaju taskove u procesu rada, oni su "directors" koji usmeravaju taskove i prave policies, ali, when s... hits the fan, oni su prvi na liniji, vode primerom. Nadam se da sam bar malo jasan. Mnogo je BS-a u ovoj prici, mnogo "knjiga" i "ideja" kao sto kazes iz drugih kultura i industrija, a ovo je tesko opisati u jednom pasusu....

Moras praviti testove, po moguctstvu automatizovane, a to je vec posao koji zahteva ljude za to. Ako to nemas imas situaciju sa FOSS programima, kada na svaki apdejt drhtis da li ce ti se sistem uopste
butovati( ili nece) ili ces imati GUI (ili neces) ;)
Sto se tice test driven developmenta, kada se prvo pisu testovi, pa tek onda korisni kod, ne znam, to se zove i extreme programming i slicno, sve u nadi da ce biti manje bagova. Nije
to nastalo tek tako, nego sto je softver kompleksniji imas tih bagcica sve vise i vise i to je kao neki samo ime kaze extremni pokusaj da se to eliminise. Nisam nikada video neki
dokaz da to daje ploda i da se projekti zapravo na taj nacin ciste od bagova. Elem, sam otkrijem dobar deo svojih bagova, al dok neko drugi ne isproba ispadne da ima jos gro toga :P

Ovo ti je memleak. Treba uvesti tmp kao rezultat i onda osloboditi originalni dest->text ili javiti gresku.

@Branimir Makcimovic

Razgovaraš sa zidovima.

Čuj, u 2020 godini u ozbiljnim sistemima ne može da se desi šta? Svetska pandemija? Očigledno može.

Eto, vidiš. Imao sam memleak, koji

1. Ja nisam našao.

2. valgrind nije našao.

3. Kompajlirano je gcc-om i clang-om sa "-Wall -Wextra -pedantic -ansi" i ništa.


Možemo da testiramo razne alate za statičku analizu.

Clang-Tidy and Clazy:




Toliko o statičkoj analizi.

_{[Ovu poruku je menjao Nedeljko dana 02.08.2020. u 00:29 GMT+1]}

Oooh, Nedeljko... ovo stvarno nisam ocekivao :-)

Hajde da predjemo na neku zamisljenu situaciju, lica iz iste nemaju veze sa stvarnim ljudima i tako to...

Imamo nekog iii teee "menadjera" koji nema pojma o "ceu" (ali je cuo da je mnogo mocna stvar) - covek voli da se prosipa nekim buzzwordima tipa CI/CD, fuzzing, linteri, sanitizeri, dza bu. Zvuci kao da zna o cemu prica ali, ocigledno, pojma nema.

Imamo, takodje, i senior programera (u najmanju ruku) - nazovimo ga picajzla, covek je PhD matematike, zna C uzduz i popreko, ako ga probudis u 2 AM, moze da ti kaze sve UB-ove u C standardu i tako tako. Starija picajzla jako dobro zna da C free nece da se u*ere ako mu bacis null pointer, cak je vrlo raspolozen da citira svoj mali dzepni man().

Divno, situacija cista k'o dan, jel da?

Hajd da vidimo malo mi to.

Za pocetak, predmet ove diskusije je GRUB (ocigledno jako dobro ime, larve se mogu naci na napustenom izmetu) i njegovi nesrecni dani kada su uspeli da s*ebu Internet sa sampionskim bagom koji je bio samo uvertira za nalazenje jos sampionskih bagova.

Ali iiteee menadjer "pametni" je izabrao drugi commit, ovaj, https://git.savannah.gnu.org/c...8287ed3af32fffe8aaf33cdff52f6b

Koji je naseg starijeg programera picajzlu naterao da "baci K&R (pardon, C99) knjigu" na glupog iii teee menadjera! Ako mu je rekao!

Steta sto je picajzla Sr. propustio da primeti da je neki jadni GRUB programer morao da ubaci nazad ocigledno suvisan kod koji, po nasem iskusnom picajzli, cak jos trosi i resurse (o ovome cemo da se pozabavimo na kraju).

Kako to? Neko u GRUB timu je primetio da nisu bas sigurni da na svim host OS-evima kompajleri nece za*ati stvar i puci unutar free() poziva sa null pointerom.

Sticajem okolnosti, takvi kompajleri postoje - jedan mobilni OS svakako nije cenio C specifikaciju. Cak i neki malo ozbiljniji OS-evi o kojima stariji picajzla sigurno jako dobro zna. Ali, verovatno, umesto jedne komparacije (koju ce mocni ISO, C99 i man() opremljeni kompajleri sa konformantnom free() f-jom verovatno optimizovati i pretvoriti u nop :-) stariji picajzla je verovatno spreman da se raspravi sa celim svetom i objasni im da ne umeju da citaju man(), a ni ISO specifikacije. Go, picajzla, go!

...

OK, GRUB mozda mora da se nosi sa kojekakvim nestandardnim varijantama, neko ce reci, ali ako je kod "garantovano ISO C" ili POSIX ili sta god, onda je Dr. Picajzla definitivno u pravu i itteeeee menadjer prica iz svoje g*zice?

Da, definitivno je Dr. Picajzla u pravu, trebalo bi ga poslati na sledeci svetski kviz UB-a i tajni ISO C-a!

Ali... u hladnom i iskvarenom svetu punom sampiona i idiota, insistirati na defanzivnoj proveri pointera u kodu koji je sigurnosno kritican je prilicno dobra ideja, kaze ii tee menadjer.

Mozda iiteee menadjer pojma nema o Ceeu, cak bi mozda pomenuo i jos nekih buzzword-a tipa FMEA, ali ko bi lud verovao da neko to koristi u danasnjoj sw. industriji. Cak i teorijski, taj buzzword je za menadjera i njegove kolege menadjere kad se zapiju posle sastanaka, pa necemo uopste ulaziti u to.

Za nas smrtnike je sasvim dovoljno sledece kao savet za picajzlin tim: instaliraj fckin linter i postene sanitizer-e u proces kreiranja izvr.. pardon (menadjer glas) "artefakta ba!".

A, da, i zameniti picajzlu Sr. (tj. realocirati coveka na nesto pametno) sa nekim proceduralnim grunt-om koji ce da ubija za propustenu proveru ako vec alatka za analizu udari Turingov zid. Sta bi rekao nas 'ajzla na to? Tako sljaka vojska a ne neki intelektualni tim? Da, vojska... znaju par stvari sa radjenjem kompleksnih operacija u svetu punom "naroda", pardon - GRUB dev-ova. Ako 'oces radis disertaciju, zanemari sve ovo... ako 'oces softver za narod i sa narodnim komponentama? Poslusaj glupog menadjera, covek mozda zna kako da ustedi kintu i zivce kasnije.

E jbg, ako menadjer se*e sve vreme... onda drzati se pameti. GRUB ekipi odlicno ide :-)

Konacno, za kraj, jos jedan komentar koji bi menadjeeer dao 'ajzli starijem:



Oh :-) Ali umisljeni menadjer je mozda cuo za neke mnogo pametne kompajlere koji ce nop-ovati (jel se tako kaze, a? pita menadjer) proveru koja je nepotrebna ako posle ubacuju optimizovanu free f-ju (koja i ovako i onako radi proveru)? Ili to ne umeju da urade, pih!

Ali po strani brojanje CPU ciklusa ili cak uzimanje u obzir nekompatibilnih C biblioteka, 'cajzla sr. propusta da vidi sasvim drugu vrednost provere u ovom slucaju.

Mozda zato sto 'CajzlaEx ceo svet vidi kroz svoje PhD naocare, umesto kao nesto mnogo ruznije i gluplje... jbg.

Profesionalna miopija.

Poslednjih godina vidim ogroman problem (ironije li, postavih juce post o testiranju), ljudi u OGROMNIM resenjima ne pisu testove. Aj' mogu da razumem za neke igranke, pravis nesto za sebe za 2 dana da ti zavrsi posao i nece biti u ne znam ni ja kakvoj produkciji... ali znam timove ljudi, njih recimo 2 radi front, njih 2 radi bekend, devops je neko ko ima malo znanja oko pajplajna eventualno da odradi deploy, neko takodje malo zna da optimizuje queryje i NIKO ne pise proklete testove. Pitah tako drugara koji je bio teamlead u firmi koja je uzimala projekte "sto pre da ih zavrsi" kako rade testiranje i to jer mi je bilo nerealno kojom brzinom zavrsavaju projekte, kaze mi "ko jos ima vremena za testove"... onda se vraca 5x projekat na doradu, pa pi*de sto rade jedan projekat gde je trebalo da budu u plusu ako ga odrade za 3 meseca godinu dana i odu u minus jer projekat ne pokriva troskove developmenta...

Sa druge strane razumem i da vise niko ocigledno nema vremena da obucava mlade programere o "best practices" pa ni sami ne vide poentu testiranja, al' kad sam u situaciji da ja i jos jedna osoba radimo bekend, pa prvo apsolutno nemam pojma da li ce moj kod kad se uklopi s njegovim da radi bez testova, em nemam pojma kako ce ovi sto rade front da citaju sta sam ja radio i vide funkcionalnost ako ne pisem testove. Primera radi, pre nove godine, bio veliki projekat, nas 3 na bekendu, vidim ne pisu testove, ok ajde necu da smaram, nisam teamlead, necu da drukam, radim ogromnu kolicinu koda koja mora da se istestira, pritiskaju nas sa vremenom, ovi rade lezerno i sve ide "po ps-u", ja stiskam zube i pitam se sta ce biti kad se odradi merge... odradim merge svog koda, jedini pisao testove, phpunit poludeo od gresaka, nastane opsti haos, teamlead se hvata za glavu, zove ovoga, zove onoga... prvo ispalo da sam ja napravio haos sto sam pisao testove, posle se naravno ispostavi da apsolutno neke stvari ne mogu da se uklope, a ovi sto rade front nisu imali pojma kako da gadjaju njihove endpointe jer im ni dokumentaciju nisu pisali kad vec nisu testove...

I tako se otprilike napravi od necega sto je potencijalno do jaja aplikacija jedna velika propast na kojoj treba da se radi 2x vise vremena dalje umesto da se koristilo 5% vremena da se pisu testovi kad vec i mi u bekendu moramo da koristimo bar postmana da vidimo sta smo uradili. Kako je krenulo to da se vise stiska s vremenom nego radi na kvalitetu samog programiranja tako su i programi postali busni ko nista.

E sad, GRUB je opet open source, kapiram da se testira, nisam gledao codebase ali verujem da moze da se zakrpi, samo sta raditi sa zilijardama racunara gde je on u produkciji? Pricamo samo o serverima.

A sto se passworda tice i koriscenja tudjih aplikacija... napravite "nivoe" po kojima cete koristiti iste sifre. Od ozbiljnosti aplikacije koristim odredjenu sifru i to je to. Bitno da mi se one top-level nikad ne provale i to je to, da l' ce neko da mi udje na twitter i pise statuse to me apsolutno zabole dokle god ne moze da mi otvara mail i payment aplikacije.

Enkapsulacija. SOLID. Testiranje. I nema brige. Umesto sulude teorije koje ima na svim fakultetima kod nas, zasto ne ubaciti predmet SOLID? Uce ljude da programiraju, uce ih ovo uce ih ono, sto ne posvetiti jedan semestar jednom predmetu i nauce ih neke stvari koje ce im SIGURNO trebati ako zele da programiraju i rade negde? Koja firma ce da primi ikoga ko ne zna to da postuje?

@Ivan Dimkovic

To nema veze sa operativnim sistemom (mada OS API ima tu funkciju) jer OS API može da bude bilo kakav.

C API mora da bude po standardu. Dakle ako OS API funkcija ne vrši tu proveru, C bibliotečka funkcija za taj OS mora da je vrši.

E, sad, šta ako C kompajler ne valja, a ima takvih? Onda smo u mnogo većem problemu, jer taj kompajler pravi ko zna kakve se gluposti, i to nikakve metode testiranja i debagovanaj ne mogu da reše. Taj se problem može rešiti isključivo promenom kompajlera.

Oh Nedeljko :-)



Sta ako ne mozes da promenis std. biblioteku?

Nista, baci projekat u djubre :-) Ko zna, mozda projekat bude neki softver za matori Unix koji, sticajem okolnosti, ne postuje tvoje standarde sta bi C API trebao da radi.

Baci taj Unix? Moze, kao i celu nuklearnu elektranu ili avion ili banku oko njega.

Znas sta ce da desi? Fina ekipa iz elektrane ce da ti se zahvali na savetu i lepo te isprate napolje, a onda ce da zaposle nekog ozbiljnog ko ce da stavi if() workaround.

Pitam se da li je WebOS sredio taj problem (PalmOS je, takodje, voleo da pukne ako mu podmetnes null u free() pice), ali bar WebOS uredjaje mozes da zamenis lakse od reaktora.

Ako si sad smislio da zamenis C biblioteku na projektu - odlicna ideja, koja ce ti odmah izleteti iz glave kad ukapiras da moras da razmenjujes stvari sa drugim bibliotekama koje su, sto mu gromova, kompajlirane sa falicnom std bibliotekom i... macka je pojela izvorni kod (hoce i to da se desi).

Mada ne znam koliko je uopste pametno na postojecem projektu da insistiras na zameni toolchain-a ako je to neka matora konstrukcija gde ne znas sta ce da eksplodira levo ili desno.

I dalje preferiras sve to umesto, u najgorem slucaju, suvisnog if()-a? Svaka cast na standardima!

Kontrolu nuklearne elektrane praviti šupljim kompajlerom, koji ima ko zna koliko iznenađenja.

Sjajna ideja! Černobilj, pa Fukušima, pa Dimkovićev projekat.

Moj projekat? Nisam ja pisao Unix v7 (ali, hvala, to je definitivno kompliment), mislim da se zalis na pogresnom mestu :-)

Unix v7 sam samo uzeo kao primer sistema gde si imao free() koji ce da se zagrcne sa null pointerom.

https://s3.amazonaws.com/plan9-bell-labs/7thEdMan/v7vol1.pdf

Imas na strani 297 malloc()/free() upustvo... nema nista o null pointerima.

Netware, takodje, hoce da krahira ako mu bacis null ptr u free().

Bastards!

Opet, nema veze sa OS-om, već sa kompajlerom.

http://www2.cs.uregina.ca/~hil...C%20Programming%20Language.pdf

Strana 209:


Dakle, uzmi bolji kompajler. Nekada si uz DOS dobijao neki GW Basic, Q Basic, ali za kršteno programiranje si nabavljao nešto ozbiljnije.

O čemu mi ono beše pričamo? O GRUB-u i 2020-toj godini? UNIX v7 (to su beše 70-te)? NetWare?

Ne znam da li si zaboravio vreme OS-eva sa sopstvenom "sistemksom" C runtime biblotekom.

Plus nisi bas mogao samo da zamenis kompajler ako su ti druge komponente linkovane sa sistemskom bibliotekom i nemas sors (ili ne mozes da im zamenis biblioteku iz drugih razloga).



GRUB commit gde su uveli testiranje pointer-a pre free() je datiran: 29.07.2020

E, sad, mozda neko od GRUB-ovaca ima fetis i pokusava GRUB da instalira na Palm OS, Netware, 3BSD ili mozda neku masinu iz 70-tih sa UNIX v7 sistemom.

Ili, verovatnije, imaju neku danasnju platformu sa C runtime bibliotekom koja ne prasta.

Kakva god da je sistemska biblioteka, kompajlerova je obmotava i ništa ne sprečava proizvođača kompajlera da u svoju funkciju ubaci proveru, pa poziv sistemske.

GRUB se inače ne instalira ni na jedan OS jer je preboot softver u pitanju.

Za svaki projekat, pa i GRUB važi da ne možeš da ga kompajliraš čime hoćeš, nego kompajlerom sa spiska podržanih od strane tog projekta. To može da bude i samo jedan kompajler.

Ako se recimo kompajlira GCC-om, onda se koristi GCC i binarni kod se instalira na PC kao preboot softver.

Dakle, GRUB nema nikake veze sa pravilima koja važe nakon dizanja OS-a koji podiže.

Gledaj Bane:

Ja da organizujem proces, moj prvi cilj bi bio da team lead bude neko ko zna da nadje memleak citajuci kod. :) Sustina dobrog tima su ljudi - znaci treba mi senior koji ce da 30-40% radi code review ostalih clanova tima, nekih 20% bude na sastancima (vise bi ga smorilo) a 40-50% vremena i dalje programira - i to taskove koje on zeli, jer je team lead (naravno od ponudjenih).

Ali ne zelim da moj team lead provodi vreme citajuci kod koji ima greske koje i linter ume da nadje. To je ono sto pricam kad kazem "kultura" i "procesi". Zna to i Dimkovic.... Automatika nije svemoguca, ali pomaze. Eliminise gluposti i lenjost, pomaze juniorima da ne prave pocetnicke greske. Imas "picajzle", ja sam morao da pre par godina idem i cimam CTO-a, i dajem pisanu izjavu jer smo imali lika koji nije hteo da pusti kroz linter promenljive sa manje od tri slova.... Dzaba smo mu pricali da je krajnje normalno da se kolona u bazi zove "ID", on je procitao da mora da ima tri slova... ;)

Alat je alat, oni pomazu. Nema automatike koja moze da resi SVE probleme, ali moze da ti olaksa zivot. Sustina je da automatikom postignes tri cilja:

- Naucis pocetnike da ne prave greske koje automatika detektuje
- Iskorisits automatiku da ti prijavi poznate probleme (tipa "load-ujes modul koji ima prijavljen security problem, predji na novu verziju").
- Promenis nacina razmisljanja - da ljudi misle o kvalitetu onoga sto prave.

Ovo poslednje je najbitnije. Da, radije bi da zaposlim tebe i da ti platim da radis code reivew, ali da li bi ti, kao lead, radije provodio 30% vremena na code review, posle automatike, ili bi da provodis 70% dana na tome, jer moras da ispravljas ono sto moze i automatika? Vodi racuna da u timu skoro uvek imas 30% juniora, koji - su juniori.

Testovi su odvojeni od ove price. Oni sluze da ti omoguce da potvrdis da nesto elementarno radi. Imas testove koji se prave tako sto neko uzme browser, snima gde klikce i izgenerise skriptu iz toga. Onda to mozes da izvrtis posle svakog commit-a, izbildas ono sto si dobio i probas da li radi. Da li nadje sve bugove? Ne. Ali eliminise ocigledne greske i garantuje ti elementarnu funkcionalnost. Ako si pokrivo dovoljno toga testovima onda znas da ce sve da ti radi, na tom osnovnom nivou koji testiras. Naravno, mozes da se*es da ima beskonacno slucajeva i da si ti testirao samo konacan broj sto je realno nula procenata.... i da izmisljas razloge da ne radis nista - ali mozes i da prestanes i da konstatujes da time samo znas da stvari rade na nekom nivou.

Je'l mislis da neko radi test celog facebook-a svaki put pre nego sto naprave "release"? Jok. Radi se parcijalno, imaju automatske testove, ako prodju samo se to gurne u produkciju. Bukvalno svaki commit u "release", koji prodje testove, ide automatski na live. Ako produkcija prijavi greske u nekom broju/procentu imas i automatski sistem za rollback. No biggie. Zakacio si neki procenat korisnika, ali ne veliki, jer roll-out traje par sati. Ako si dobio greske, onda je sistem sam uradio rollback, neko dobija logove greski sa ciljem da popravi, a neko drugi sa zadatkom da napise test koji to pokriva. Ide sve paralelno....

Generalno, sta god uradis provuce se neki problem u zavisnosti od toga kolika je korisnicka baza. Uvek postoji mogucnost da tamo negde kod nekoga nesto podje naopako iako kod 99% korisnika to radi dobro. No ovo je FOSS,
gde ne postoji QA uopste i gde je navika da korisnici to rade....

Je li Bane, a zašto misliš da QA ne postoji u slučaju FOSS projekata?

Ja kod mnogih prilikom kompajliranja nalazim na make check, koji pokreće gomilu automatskih testova.

Pogledaj koliko ima testova u Linux kernelu? Ima ih BAS dosta.

Ovo nije F/OSS paket za crtanje, ovo je boot softver koji je deo ozbiljnih serverskih ponuda. Red Hat Enterprise Server, Oracle Unbreakable Linux (to su likovi koji su potpisani) imaju podrsku koja se placa. Ocekivao bi covek da Red Hat i Oracle imaju QA department za ovo... Ajde, secas se gde smo nas dvojica zajedno radili Oracle? Razmisli da dodjes i kazes nekom aerodromu "E, moracete da reboot-ujete server, pa ce, verovatno, da radi posle. Nadamo se" ... E, ti likovi su placali podrsku za Oracle i placaju je i sad. Stvarno mislis da bi to kod njih proslo? Ja verujem da je tamo sad tezak "sh*t hitting the fan" period...

edit: Inace, naravno da se provuce NEKI problem. Cilj je samo da ih ima sto manje. Zato ides prvo na automatiku, pa na seniore koji rade code review, pa.... zavisi kako radis. Ali "bice uvek neki problem" ne znaci da ne treba testirati.

@Branimir Maksimovic


Manje-više što i ja mislim da nisi u pravu da FOSS nema QA (ozbiljni projekti bi trebalo da imaju QA, ali i novčanu konstrukciju).

Da li shvataš da razgovaraš sa zidovima?

Ljudi koji nisu ništa ozbiljno programirali u poslednjih 10 godina tebi sole pamet da uz ne znam kakve alate i procedure u 2020-toj godini ne može da se desi buffer overflow.

Za njih je bafer nešto što je jednom alocirano i jednom popunjeno. Nemaju pojma da postoji potreba da se bafer puni malo po malo.

Naravno, onda negde treba beležiti dokle se stiglo sa punjenjem, pa pošto alati za statičku analizu ne mogu da skapiraju značenje tih promenljivih i izvode jednostavne teoreme, da neće ni detektovati mogućnost buffer overflow-a čak i ako postoji.

@Nedeljko,

Ljudi koje mislis da sole pamet su videli jako puno bagova, neki su mozda cak radili i FMEA samog procesa. Odatle su i dosle preporuke za koriscenje alata koji se pominju.

Ogromna vecina bagova su idiotski koje automatizovani alati i adekvatno testiranje otkrivaju. Drugi (isto tako pozamasan) deo biva otkriven code review procesom koji jednostavno odbacuje gomilu antipatterna i opasnog koda, mozda bez direktnog problema u tom momentu ali sasvim sigurno potencijalnog kontributora u buducnosti. Rezultat toga je bolji kod sa manjom sansom za trivijalne bagove koji su ubijeni jeftinijim procesom nego da ih otkrije musterija. Ako to nemas, musterija ti otkriva bagove i clanovi tima post-hoc popravljaju nesto sto uopste ne bi ni trebalo da se nadje u repozitorijumu.

Mozda ti kao veliki strucnjak i senior u timu to ne vidis zato sto neko drugi rasporedjuje gomilu tih budalastina drugima u timu, ali nemoj misliti da neko to na kraju ne mora da 'opravi.

"Heisenbug-ovi" kao i drugi komplikovani bug-ovi koji ne mogu biti automatski pronadjeni spadaju u manji % prakticno otkrivenih bagova u korisnickom softveru (ne pricam o nekim specijalizovanim alatima, simulacijama i sl.). Poenta automatskih alata je upravo da razvojni tim ima posla samo sa takvim bagovima, a ne da posle N godina postojanja projekta ubacuju stvari tipa proveru vracene vrednosti malloc-a i sl.

Umesto da ti covek koji je placen 6-cifreno gubi vreme sa trivijalnim stvarima, tu je razvojni proces koji takve stvari mahom otkriva tokom commit-a. Onda taj covek moze zaista da se pozabavi sa problemima koje nije moguce automatski otkriti.

GRUB bagovi pokazuju da ocigledno nemaju nikakav proces. Zato su sad morali da oprave hrpu budalastih bagova. O steti po ceo IT zato sto ce sad bog te pita koliko ljudi gubiti vreme sa bootloader-om da ne pricamo.

Ali, samo nastavi, bolje je da se GRUB ekipa krenula boriti sa autorima kompajlera.

Ne sumnjam da, sta god odluce, da ce Red Hat uvesti red bar kod sebe.

Ovo sve pokazuje da ti i nkrgovic u poslednjih 10 godina niste ništa ozbiljno programirali i da ne pišete iz iole svežijeg relevantnog iskustva.

Buffer overflow može da ostane nedetektovan kroz sve te faze, alate i procedure.

Proveru vrednosti malloc-a naravno da treba raditi, ali je poslednja rupa na svirali, jer memorije u principu ima. Nije bag visokog prioriteta. Ako nigde ne vršiš proveru vrednosti malloc-a i to je jedini problem, problema u principu neće ni biti. Koliko ti se puta desilo da ti program kuka da nema dovoljno memorije? Ja sam uvek za pedantnost, ali čuj, to zaista nema toliko visok prioritet kao na primer buffer overflow ili pogrešan algoritam. Bag višeg prioriteta je računanje u pokretnom zarezu bez provere da li je vrednost NaN, ako je potrebna.

Ajde da odgovorim Nedeljku i tebi u paketu. Ti testovi koje piše developer, su samo provera da osnovne stvari rade kako je predviđeno, nikako nešto što pokriva sve slučajeve. Naravno pišeš neku funkciju pa i test za tu istu, ali bez qa nema ništa od otkrivanja bagova. Što se tiče FOSS-a, dobro znam da bar 5% korisnika ima neki problem nakon svakog apdejta, i da mnoge stvari ne bi prošle da postoji qa. Baš u kernelu prolaze takve regresije, da drajv er ne radi ili da je potreban patch da nekom nešto proradi... generalno, čak i ako se plaća developer, nema se para za qa. Zbog toga enerprize, android, ruter firmware i slično laguju i po više godina za aktuelnim verzija ma...

Eo ispravio sam sve bagove u grubu:

/sbin/lilo -v

:D

Testovi koji pokrivaju sve slučajeve su praktično nemogući.

Ono što može, to su razne metode kojima se povećava verovatnoća detektovanja greške ako greška postoji.

Recimo, da li je se prilikom izvršavanja testova svaka naredba izvršila barem jednom.

Međutim, garancije da će bag biti detektovan ako postoji ne postoje, već samo uslovna verovatnoča detekcije baga ako on postoji, koja se nekim metodama povećava.

Bane, nije cilj da se nema QA, naravno da treba QA. Naravno da treba i neki "Bane" koji radi code review. Sve to treba. I naravno da i pored toga moze da se nadje bug, koji je glup ali gadan....

Ja sam imao bug koji sam nasao coveku posle analize kako radi JWT token, jednostavno lik je imao 5 sajtova i na svima isti secret. Fora je sto je sajt 1 imao 20x vise clanova nego sajt 3 - i onda ti lepo otvoris nov nalog na sajtu 3, uzmes token i udjes na sajt 1 sa necijim tudjim nalogom, ali istim ID-em.... Ovo nijedan alat nece nikad da nadje - jer nema veze izmedju sajtova. Ne moze. Bug nije bug u kodu, vec u ljudskoj logici. Ne deluje bitno, ali sajtovi su bili EU, pa je to znacilo da korisnik vidi podatke drugog korisnika, pa uskace GDPR... :) Znas li zasto je bug pronadjen? Zato sto smo imali proces i zato sto smo pricali o tome i zato sto sam ja slusao nesto sto nije imalo direktne veze, ali smo imali stav "ako vidis bug pricamo o tome". Dimkovic moze, ako ga ne mrzi, da objasni koliko "user X vidi privatne podatke user-a Y" boli firmu koja je deo EU, sad kad je GDPR u igri....

Ponovo, bitan je proces. Ako dev X pise kod i zna da ce neki junior da napravi testove, da ce QA da napravi druge testove i da ce "Bane" da radi review - on ce da vodi malo racuna. Ako mu kazes "slobodno odvoj vreme da pises bolji kod" - on ce to i da radi. E to je fora.

Ako mu kazes "ma ti si do jaja baja, mnogo si pametan, samo cepaj commit i ne brini" - onda on pise "1337 c0d3", a ne brine o bagovima. Ako mu das da on "misli" sta je realno a sta ne, onda ce on da misli sta je realno za njega - a ne da li to boli end usera, ili da li neki Security baja vidi sebi ufur... zato sad i guraju DevSecOps pricu gde se security radi od day 1, ukljucujuci i pisanje testova za security, i rucno security testiranje i security team ukljucen u projektovanje.... Evo, ovaj konkretan grub bug: Prilicno sam siguran da niko nikad u realnom zivotu nije imao buffer overflow u grub-u i da je grub pukao zbog toga. Neki dev tu ne vidi veliki problem - sto bi mislio o necemu sto se ne kvari... Neki security specialist tu vidi rupcagu. :)

Dodatno, ono sto je bitno je: U sistemu gde sve ide manuelno, proces izgleda ovako:

- PM pise task developeru
- Dev pise kod, radi commit
- Dev pise note u Jira-i za PM-a
- PM pise task Ops-u da deploy-uje nov build na test env
- Ops radi deploy
- Ops pise note PM-u
- PM pise task QA-u
- QA testira, nalazi bug
- QA pise note PM-u.
- PM pise task dev-u da ispravi bug

U medjuvremenu proslo dva dana (minimum, mozda i vise), dev vec radi nesto drugo. On sad prekida to ili ne? Haos.

Uporedi to sa:

- Dev uradi commit i push
- Dev ode po kafu i da zapali dok prodje pipeline
- Dev dobije error koji moze odma da popravi, ili mu pipeline prodje.
- Dev trazi MR, ode na rucak
- Dev dobije od "Baneta" sta da ispravi za pola sata ili sat.

Ako ovo resi samo 50% problema, ustedeo si BRDO vremena. Again, code review: Ultra bitan. QA takodje. Ali testove pomazu.

Vodi racuna: QA pise neke testove. QA svaki put kad potvrdi bug pravi test koji testira tacno taj scenario. QA pravi test koji testira sve klasicne user scenarije. QA pravi testove koji njima imaju smisla. Ne mora QA ni da programira, koristi alat koji snima kliktanje i onda se radi replay.... :) Bitno je da QA zna kako radi softver i zna da reprodukuje bugove. Naravno, nisi testirao sve, ni blizu. Ali, ako spojis dev-ove koji testiraju da sve radi kao sto misle da treba, i QA koji testira funkcionalnost, onda uglavnom radi OK... I dalje nije sjajno, i dalje imas bugove, da. Ali manje.

Ja uporno pokusavam da kazem zasto se tako pojavljuju bug-ovi u FOSS softveru: sve dok neko ne pogleda, kao u ovom slucaju.... mada mislim da je bug u opnessh bio mnogo kriticniji...

TDD je nekad bio "extreme programming", danas ga ne bih nazvao tako. Ajd imaj u primeru da ja pravim neki API, neka bude u PHP mada je to stvarno irelevantno. Meni da bih video da li mi API radi, treba http klijent preko kog bih slao zahteve. Ja za to moram da koristim Postmana ili napisem klijentsku aplikaciju jer moram da cuvam negde token, ili da napravim neku mini python aplikaciju koja ce da radi sve to.

Ako pisem testove, sto bih morao to da radim? Phpunut ce poslati post/get request, ja cu proveriti da li je json onakav kakav treba da dobijem, da li je status 200 ili kakav treba da bude, provericu situaciju u DB, potom cu napisati novi test kontradiktiran tom i to je to. Nema nista "ekstremno" cak i da pocinjem od testa koji ce failovati, jer opisujem ono sto zelim da radi kako zelim da radi.

Ali da, postoji taj problem da je nemoguce testirati svaki usecase. Bukvalno kolicinom funkcionalnosti kvadratno raste i kolicina testova koja treba da se pise. Mada se zato ne radi na kolicini testova, nego na recimo validaciji... opet se vracam na ono sto sam pisao pre 20ak postova a ne verujem da je iko procitao, ljudi ne pisu ni osnovne testove. A fora kod osnovnih testova je kad ti neko prijavi bag, ti napisi takav test, nek ti fejluje, onda lepo TDD dok ne pozeleni i ispravio si bag. TDD moze da se koristi i na prosirenju postojecih aplikacija.

Bane, nemaš kome da pričaš.

Code review rade ljudi, a iz istorije matematike (koja je za one koji dobro znaju oboje isto što i programiranje) je poznato da su i najveći umovi pravili najelementarnije greške.

To ne znači da code review nije neophodan, već da ne postoje srebrni meci, čarobni štapovi i slično.

Drugim rečima, tvrditi da ne postoji propisna procedura koja se temeljno sprovodi, samo na osnovu toga što je pronađen buffer overflow bug je čisto lupetanje.

GRUB možda ima temeljnu proceduru, a možda je i nema. Ako je ima, buffer overflow bug u C-u itekako može da se provuče, tako da je navedeno zaključivanje neosnovano i ne potiče od nekoga ko ima iole ozbiljnog svežeg iskustva.

Buduci da je znacajan deo exploita zasnovan na raznim buffer overflow,
da li metode kao Canaries, Bounds checking, Tagging... pokrivaju sve moguce scenarije
u kojima bafer moze da se prelije, tj. da li bi striktnom proverom svega ovime
bile izbacene sve mogucnosti za prelivanja? Da li recimo -fstack-protector-all u GCC resava
sve ili opet moze da se prelije bafer u nekom scenariju?

Nedeljko, da ne postoji qa je to sto su ipravke tih bugova izazvale da ljudima sistemi nece da butuju.

Srdjane stack protektor moze da detektuje samo overflow na steku i to onda kada se probije ceo stek, znaci ne otkriva overflow
niza koji recimo gazi neke varijable na steku...

@Zlatni_bg, kako proveravas da li su testovi ispravni? Mislim, svakako mozes imati bug i u testu. Kako se povecava broj testova, tako se povecava i mogucnost da oni imaju neki bug.

Tako sto mi svaki test ima gomilu asertacija/provera u odvojenim sekvencama. Uz to, nemam samo izolovane testove za jednu funkcionalnost vec i glomaznije testove za kompletan usecase. Naravno konkretniji odgovor bi morao da ima konkretnije pitanje, svaka situacija je situacija za sebe :) Ako test prolazi sa ispravnom datom, a drugi test sa neispravnom datom koju test ocekuje kao neispravnu, kapiram da sam pokrio veci broj slucajeva.

U pravu je svako ko kritikuje GRUB tim, bilo na fin način, bilo na LT način. Ali kritikovati FOSS (bilo zajednicu, bilo ideju ili način rada) je besmisleno u ovom slučaju.

Prvo, već je rečeno na temi da ovo utiče na Red Hat (IBM) i Oracle proizvode. Dodajte tu i Microsoft, Citrix, VMWare, SUSE (EQT), HP, Dell, Lenovo... koji ozbiljan novac uzimaju na sistemima koji koriste GRUB (ko bi rekao da će Intel uraditi nešto pametno po pitanju sigurnosti i izabrati systemd-boot). Ako oni nisu odradili QA proizvoda koji koriste, onda su oni krivi za taj propust. Ako bi ti crkao SoC u telefonu, ne ideš da se žališ ARM-u, Qualcomm-u ili TSMC-u, nego Samsungu. Ako se nekad autonomno vozilo spuca u banderu, nećeš psovati nVidia system za upravljanje, nego Mercedes koji ti je prodao taj auto.

Ako gorepomenute kompanije (i još 100 drugih) ne žele da kontrolišu kvalitet svojih "dobavljača", onda su oni gori od GRUB tima. Ako ne žele da se uključe kontrolu kvaliteta (signurnost) delova OS-a kao što GRUB, SELinux, systemd, networkmanager, firewall... onda su podjednako neozbiljni, možda i gori.

Drugo, GRUB nije jedini (FOSS) bootloader. Kao što sam napomenuo, Intel za svoj ClearLinux koristi drugo rešenje. Jednostavnije i sigurnije (mislim da ni on ni nema config fajl). ChromeOS takođe.

Treće, navoditi Apple ili Google kao dobre primere za bilo šta po pitanju sigurnosti je uglavnom besmisleno. Da, njihovi proizvodu jestu na samom vrhu po tom pitanju, ali po koju cenu? Jer to je ista sigurnost koju ti daje CCP u Kini. Hvala, ali ne hvala. Ja sam vlasnik hardvera, hoću da stavim bootloader/OS koji ja želim, da startujem GUI file manager u root modu, da kliknem Run Anyway kad me SS upozori, instaliram aplikativni softver odakle hoću (čini mi se da i procentualno Playstore ima više đubreta i malware-a nego F-Droid). Upozori me da radim nešto što ugrožava sigurnost sistema, i da mogu da napravim belaj, ali ako znam šta radim, pusti me. Što kaže moj kolega, naš sistem je toliko siguran, da ni mi sami ne možemo da pristupimo svojim fajlovima. Ne treba mi takav uređaj.

Na kraju, da se bi se ova rupa iskoristila, potreban je fizički ili admin pristup računaru. Tj. uz dobru politiku sigurnosti, nije baš lako stići dotle.

FOSS radi bez QA 30 godina bez obzira ko
ga koristi. Osnivna ideja je da useri sami
ispravljaju i otkrivaju bagove..
systemd-boot sam koristio jedno vreme na
laptopu dok se nisam smorio da sam nameštam
kernele prilikom svakog apdejta... ima konfig fajl,
i nije podržan out of box na Manjaru.
na kraju krajeva za uefi ni ne treba butloader
ako nećeš dual boot direktno poturiš kernel...

To da rade 30 godina bez QA-a je poprilično neozbiljana izjava. I netačna naravno. Možda se odnosti na neki one-man projekat skripte za skidanje klipova sa YT-a, ali u takvim slučajevima ima (ozbiljnog) testiranja. O velikim projektima da i ne govorimo.

Da koristis FOSS znao bi.

edit:
mislim svaki releaze Gnome-ta i KDE- nosi gomilu regresija i bagova koje otkrivaju korisnici. A gde ces vecih i ozbiljnijih projekata od tih?

Naravno da koristim FOSS. Linux (openSUSE) mi je primarni OS, Firefox primarni browser, Thunderbird mejl klijent, Libreoffice za office paket, Nextcloud za cloud servis, Wire, Signal, Element... za IM/VoIP, KDevelop/Spyder, Octave, FreeCAD, Duplicati, Cryptomator... skoro sve aplikacije na telefonu su mi sa F-Droida. Bagova ima svuda, ali nisam primetio ništa lošiji kvalitet u odnosu na vlasničke alternative. Microsoft proizvode pre svega, pošto jedino oni (još uvek) i prave kudikamo funkcionalan aplikativni softver, a ne teletabis verzije za nove generacije korisnika. I otprilike podjednako problema i bagova imam i sa vlasničkim i sa FOSS proizvodima. Pogledaj na šta liče forumi nakon svakog novog Windows build-a. Džabe QA i toliki insajderi. Zato je meni feature upgrade odložen bar za 2-3 meseca na svim računarima. Sad mi stigao 2020 na jednom i nije znao ni koliko je sati.

Inače, najveće đubre od apliaktivnog softvera koje koristim je AutoCAD. Program koji postoji i razvija se 40 godina, i opet je đubre gde najosnovnije stvari ne rade kako treba. Kao i svi Autodesk proizvodi. Npr. Vault je imao bag da se neki elementi UI-a ne vide kada je u dual-monitor okruženju desni monitor primarni, a njega prebaciš na levi. Sreća pa košta samo 500€ godišnje, pa je sasvim na mestu da se takve gluposti ne testiraju. Jednom mi je zvanična podrška rekla da je rešenje problema sa radom sa njihovim vlasničkim formatima reinstalacija OS-a i njihovog paketa. I to dok su prodavali trajne licence od po 3-4.000€. Mnogo mi je manji problem da restartujem plasmashell kada zabaguje nakon login-a, restarta, update-a ili slično. Ako ništa drugo, bar u Plasmi mogu da istrpim bagove, pošto je to otplike jedino out-of-box funkcionalno (normalno) grafičko okruženje, uz Windows 10.

FOSS nije ni bolji ni lošiji od vlasničkog. Ni sigurniji ni bušniji. Nema to toliko veze sa licencom koliko sa svim drugim stvarima koje su bitne kada se pravi bilo šta. Od OS-a do četkice za zube.

Izjedančavati FOSS sa GNOME-om i KDE-om je neozbiljno.

Ozbiljniji projekti su kernel, llvm, GNU, FireFox...

GRUB je valjda deo GNU projekta. Međutim, tvrditi da nema QA samo na osnovu buffer overflow-a, a da se ne zna kakav je buffer overflow u pitanju je glupost.

Ma u zadnjih 5 godina je jos dobro, kako je bilo :P
Ovi iskusni tipa RedHat i Oracle gledaju da se bagovi ispeglaju prvo kod drugih,
pa kad prodje jedno godinu do dve onda i oni uzmu sto je proslo kroz iskustvo:P

Pa, to rade i vodeći proizvođači komercijalnog softvera. Naravno da imaju celu QA proceduru unutar preduzeća. To se zovu fabrički testovi.

Onda se objavljue beta, pa se kod beta testera ispoljava sve što se provuklo kroz fabričke testove, pa se i to ispravlja.

Onda se objevljuej final, pa se kod korisnika ispoljava šta se provuklo kroz fabričke testove i beta fazu, pa se i to ispravlja.

Onda se kroz godinu do godinu ipo dana stabilizuje.

Tako je i kod komercijalnog softvera.

Da osim, sto kod FOSS-a beta testeri su korisnici... no opet bugovi se provlace i kod komercijalnog softvera
koji ima beta testere i QA... kako god se okrenes ispada da je nemoguce izbeci ih...

I za komercijalni softver su beta testeri korisnici. Gomila igara ima (open ili closed) beta testiranje od strane korisnika. Ja sam koristio/testirao beta/dev verzije gomile komercijalnog softvera (Windows, Softmaker Office, nanoCAD, DraftSight...).

Ponovo, to što je GRUB (bio) bušan nema nikakve veze sa tim što se radi o FOSS projektu

"Ponovo, to što je GRUB (bio) bušan nema nikakve veze sa tim što se radi o FOSS projektu"

Ali ima zato sto pola korisnika nakon "fix-a" nije moglo da butuje sisteme...

Da, tako nešto se nikada ne može desiti ako OS, bootloader i update pravi ozbiljna IT korporacija, umesto gomile bradatih likova iz podruma ;)

Microsoft Confirms New Windows 10 Update Crashes, Boot Failures
Android 10 update stuck on the boot screen? You're not alone
How to fix Galaxy S10 won’t boot up after an update | stuck at boot logo screen
How to Fix: iPhone iPad iPod Won’t Turn on After Update

Branimir Maksimovic

Za svaki softver su beta testeri korisnici.


Space Beer navodi neke primere iz vesti. Ja bih naveo primer iz ličnog iskustva.

Na poslu sam imao dual boot ubuntu 16.04/Windows 10 Home. Da sa GRUB-om (ne, nego sa kikirikijem). Radi zaštite intelektualne svojine u slučaju servisa, instalirao sam ubuntu sa home folder encryption opcijom. Preko toga je instaliran Windows 10 Home.

Posle nekog Windows 10 update-a (koji je trajao u beskonačnost), nije mogao da se digne nijedan od dva sistema, ali je boot loader popravljen tako da se diže Windows.

Kolega je isto imao Windows 10 Home i neki update je uskočio u beskonačnu petlju. Ostavljanje uključenog računara preko noći nije dalo rezultate.

"Za svaki softver su beta testeri korisnici."

Netacno.

Sto se tice dual buta Windows ne pokriva situaciju, pa si na svome.

Sto se tice fix-a koji je netestiran pusten u divljinu to se desava samo na FOSS-u...

U ovoj temi ljudi navodili primere gde se netestiran vlasnički softver pušta krajnjim korisnicima, i ti opet kažeš da se to dešava samo na FOSS-u. Uostalom, šta meni znači to što su MS, Apple, Google, Samsung... testirali sve, kad ja nakon update-a ne mogu da koristim svoj uređaj.

Spinujete, ako se neki bug provuce, to ne znaci da nije testirano. No praksa FOSS-a je da se uopste ne testira, jer nema ljudi placenih za to...

edit:
mislim o cemu pricati, samo model razvoja softvera u FOSS-u je divljina... ima onih primera bazar vs katedrala i slicnih diskusija...

Ti spinuješ. Ako te mrzi da proveriš, reci, ja ću napraviti spisak FOSS projekata koji ima QA bolji nego većina vlasničkih

Ajde napravi spisak pa me pobij. Samo mi navedi i ko radi QA jer ako je FOSS to ima negde zapisano.
No u ovom slusaju je FOSS klasika. Neko iskopa neki prepotopski bug onda neko grunu "fix" koji netestiran sleti
medj distroe.. i napravi vecu stetu nego da se nije diralo...

Nego ko su beta testeri? Kada je MS objavio Windows 10 beta, ko su bili beta testeri? Ljudi koje MS zapošljava i plaća? Ne. To su bili Pera, Mika i Đoka, koji su se prijavili za da budu beta testeri, a MS ih prihvatio za beta testere. Nije prihvatio svakoga zato što ne želi da se to koristi kao besplatna zamena za komercijalan proizvod, da bi ga naplatio, ali to je to.


Jeste. Znaš koliko sam srećan zbog toga. To me je baš utešilo, jer eto, priroda posla zahteva dva sistema, a nešto me mrzi da na službeni put nosim dva laptopa. Da, tačno je tako kako si opisao, MS ne pruža nikakve garancije za mene. Who cares for me!

Nedeljko:"Nego ko su beta testeri?"

Testeri su ljudi koj su placeni da rade taj posao. To sto se M$ dosetio da ustedi na ljudima i zbog toga sto neki broj placenih ljudi
ne moze sve da pohvata, ne znaci da sada sav softver tako funkcionise sto je tvoja tvrdnja.

Kako placeni, sto puta mi ponudio neki softver da budem "beta tester" nekih novih "featuresa",
al se ne secam ni jednom da su ponudili kintu :D

Znaš li Bane da navedeš primer nekoga koga su platili kao BETA testera?

P. S.

Ako se muškarac koji testira zove tester, kako se zove žena koja testira? Testera!

Microsoft je davao Windows licencu prvim Win 10 insajderima.

@Branimir
Imaš open-source programe koje pišu velike korporacije i neprofitne organizacije ili fondacije, gde ljudi dobijaju platu da rade na FOSS projektima (Firefox, Chromium, AOSP, VS Code, Signal, Blender...)

Imaš ozbiljne projekte, uglavnom open-core, gde firma koja vodi projekat i plaća programere, zarađuje na business/enterprise verzijama, hostingu svog softvera (SaaS) ili plaćenoj podršci (Nextcloud, Odoo, OpenProject, Mattermost, Matrix/Element...)

Ima i velikih projekata koje vodi zajednica (podržana od nekih organizacia), a rade uglavnom ljudi neplaćeni za taj posao, ali opet su veoma složeni i funkcionalni programi, sa standradnim QA procedurama (Libreoffice, openSUSE, KDE, FreeCAD...)

Imaš i one-man projekte koji su od početka razvijani po PS-u i postali su izuzetno kvalitetni. I sada kada ih u proseku održavaju i dalje razvijaju 2 čoveka uopšte ne zaostaju za vlasničkim rešenjima (Bitwarden, Joplin, Sourcehut...)

I naravno, najbolji primer je Linux kernel (a i mesa, llvm, gcc, openCL/Vulkan....) , na kom uglavnom rade ljudi iz velikih korporacija (Intel, IBM, Google, AMD, Samsung, Valve...) pošto svako od njih ima koristi od toga.

Svi navedeni programi (i još gomila drugih) se rade ozbiljno, imaju QA, i može se reći da su kvalitetniji od mnogih vlasničkih alternativa. To ne znači da nemaju rupe, bagove, gluposti u kodu i slično. Ali ništa što se ne viđa i u vlasničkom softveru velikih kompanija.

Kad pričamo već o sigurnosti, neverovatno je koliko navodno ozbiljnih kompanija, čiji softver i servise koriste i velike firme, ima najjadniju politku kreiranja šifre (min. 8 karaktera, 1 veliko slovo, 1 malo, 1 broj, 1 specijalni karakter). Ko to napiše, "testira" i pošalje krajnjem korisniku, treba da dobije lopatu po leđima. Ili nemaju normalan ili nikakav 2FA (je l' beše PayPal do skoro imao SMS kao jedinu 2FA opciju? Asana i dalje nema ništa, imaju samo Google SSO i SAML). I tako dalje.

Naravno, opet treba i ponoviti da FOSS nije sigurniji samo zato što svi imaju uvid u kod i mogu da ga prekontrolišu, što i ovaj GRUB slučaj dokazuje
https://infosec-handbook.eu/blog/software-security-myths/

Odakle ti to da na ozbiljnim projektima uglavnom rade ljudi neplaćeni za to, što LibreOffice i openSUSE svakako jesu? Znam čoveka koji je bio plaćeni dev na KDE projektu, a koliko je FreeCAD "ozbiljan", treba pitati mašinske i građevinske inženjere.

Mit je glupost koju su linkovao. On tvrdi da "nije sigurnije A nego B" i onda dokazuje iskaz "A nije apsolutno siguran". Sa takvom logikom ne vredi dalje komentarisati članak.

Mit broj 3 zaista obrazlaže upoređivanjem, ali izvodi pogrešan zaključak. U navedenom slučaju je mali studentov brauzer sigurniji upravo zato što ga malo ljudi koristi, pa nije interesantan za napade. Sigurniji znači da je manja verovatnoća da ćeš da fasuješ nešto.

Ako je sors dostupan, onda postoji mogućnost javne i nezavisne provere, što ne znači da se ta mogućnost zaista i koristi. Javno dostupan sors i povremeno održavanje javnih revizija zaista doprinose sigurnosti, što ne znači da ničega od propusta nema.

Dalje, kaže da te revizije ne vrede, jer su devovi u međuvremenu mnogo toga menjali. Ako su menjali, nisu menjali na mom računaru ako nisam ažurirao softver (što je još gora praksa), ali svakako doprinosi sigurnosti. Naravno, bitno je i kako se organizuju te revizije i koliko su kvalitetne. Dobro je da postoje nagrade za uspešne (kao što Apple tvrdi da radi).

Nigde on ne tvrdi da je A sigurnije od B, niti da je B sigurnije od A

Takođe, nema ni potrebe dokazivati da je bilo šta sigurno, pošto znamo da nije. GRUB je jedan novi primer u FOSS-u, ili npr. CVE-2020-1036 u vlasničkom softveru.
Sigurniji ne znači da je manja verovatnoća da ćeš da fasuješ nešto, već da je manja verovatanotća da ćeš da fasuješ nešto ako te neko napadne. To je upravo i problem Linux advokata koji tvrde da je Linux desktop sigurniji jer se krekerima ne isplati da pišu malver za OS koji koristi 2% ljudi. I ciljani napadi nisu jedina opcija. Uzmi taj one-man browser i kreni po sumnjivim zabitima interneta ;)

Što se plaćenih developera tiče, da, i KDE i ostali imaju i ljude koji rade za platu, ali je procentualno veći broj ljudi iz zajednice koji to rade u svoje slobodno vreme ili za neku malu naknadu. I opet poštuju sve preporuke i dobru praksu prilikom pisanja i testiranja softvera

Ali to nije tacno.

Gledaj, F/OSS nije siguran zato sto svi imaju uvid u kod - ali jeste SIGURNIJI. F/OSS ti cinjenicom da je Open garantuje da svako moze da vidi kod. Pretpostavka je da ce NEKO i da gleda - imas "security watchdogs" tipa EFF, ACLU i slicne koji ce bar da "bace pogled". To ne cini F/OSS inherentno sigurnim, to je tacno, ali ga cini sigurnijim, jer je razumno pretpostaviti da takav softver nema backdoors koji su skriveni u kodu.

Jako je bitno razumeti razliku izmedju "siguran" i "sigurniji". F/OSS i dalje ima greske, kao i svaki softver, ali ga model cini nepodesnim za prikrivanje namernih mana i kao takav je bolji ako ti je stalo do tvoje privatnosti pre svega.

Dakle, ovako piše u linkovanom članku:


Dakle, opovrgava se mit da je open source softver sigurniji od vlasničkog softvera. Šta on dokazuje? Da se mogu potkrasti propusti u open source softveru. Argument mu je da ne mogu ja to sve da iščitam. A, šta ako su drugi iščitali, svaku komponentu po neko? Argumant pada.

Dakle, opovrgava mit da je revidiran softver sigurniji od nerevidiranog.

Argument mu je da i u revizijama može nešto da promakne. Naveo je primer gde su na reviziji uočeni sigurnosni propusti, koji su i ispravljeni, ali da su naknadno pronađeni još neki. Pa sigirno je softver sigurniji sa manje propusta (ispravkama uočenih propusta na reviziji) nego sa više (da nije bilo revizije i da onda nisu ni ispravljeni). To što su naknadno uočeni neki zanači da revizijom broj propusta smanjen na nulu, ali znači da je smanjen.

Dalje kaže da se ispravkama mogu uneti novi propusti. Mogu, ali to obično nije slučaj. Ponekad naravno jeste.

Konačno, tvrdi da pošto se izmene vrše svaki dan, a revizije ne vrše svaki dan, da rezultat nije validan. Revizije zapravo doprinose sigurnosti jer se na njima uoče neki propusti koji ne bi bili uočeni.

Ovo je zaista mit, ali mu obrazloženje ne valja.

Da, sigurnost je verovatnoća da ću nešto da fasujem. Ako nisam zanimljiv cajberkriminalcima ili pripadam grupi koja im nije zanimljiva, to zaista doprinosi sigurnosti, jer mene zanima da li ću nešto fasovati ili neću, odnosno kolike su šanse da mi se nešto desi.

Inače, manje izveštaja o propustima zaista ne znači veću sigurnost, ali iz sasvim drugog razloga. Da li je teže biti svetski prvak u bacanju koplja ili u bacanju kugle? Koplje je lakše od kugle, ali mora dalje da se baci nego kugla. Kugla je teža od koplja, ali ne mora da se baci toliko daleko kao koplje. Na kraju, u obe discipline imam konkurenciju vrhunskih sportista, tako da na kraju izađe na isto.

Ovde imamo konkurenciju između istraživača koji traže propuste da bi se otklonili i kriminalaca koji traže propuste da bi ih zloupotrebili. Sve jedno je da li je iz nekog razloga teže i jednima i drugima (pa ima manje prijavljenih propusta) ili lakše i jednima i drugima (pa ima više prijavljenih propusta).

Ovde daje iskaz o paketima, a onda u obrazloženju priča o riznicama paketa. Očigledno ne zna šta priča.

Zaista se može nešto fasovati iz riznica, ali su zaista manje šanse nego iz sumnjivih izvora, mada on ovde nije upotebio izraz "sigurnije", već "sigurno".

Metodologija razvoja kod FOSS projekata nije ista kao kod kompanijskih. Ajde necu da gresim dusu mozda se nesto od toga razvija ne stihijski, ali
za Linux kernel znam kako ide : Linus, please pull: Linus, yeah. ... bugs/regressions in a wild: I the user report the issue. Thanks!

FOSS ima prednost sto ce neko pre ili kasnije sam uociti i popraviti bug nego da ceka da se neko smiluje kad nadje vremena :P

E ja ni pod razno ne pristupam sa Windows-a i telefona kriticnim za bezbednost resursima, tipa racun u banci :P
Mit ili ne mit na Linux-u tacno znam sta sve radi i zasto radi, tako da se osecam sigurnije. Mislim opet mozes
da downloadujes neki binary sa neta i pokrenes ko u Windows-u :P

Opet sve netačno :D Pored toliko navedenih primera, gde su korporacije godinama imale uvid u kod, iščitali su sve po hiljadu puta, i nisu videli takve rupe (openSSL, openVPN, GRUB, kernel...), vi i dalje tvrdite da je zbog toga sigurniji. A s druge strane niko nema pojma šta je Apple napisao i ubacio u svoje uređaje, ali retko viđamo takve propuste. I naravno, sve to dalje zavisi i od korisnika, tj. njegovih navika.

Ni to za backdoor ne mora biti tačno. Ako me pamćenje dobro služi, (open)BSD je dugo imao neki CIA/NSA/FBI backdoor koji je niko nije uhvatio.

Seafile je FOSS i ima lošu E2EE implementaciju, a developeri su u fazonu: "To je ionako planirano za self-hosting rešenja, E2EE nije toliko bitna stvar". I to tako stoji godinama. S druge strane, Tresorit je zatvoren, prošao je security audit, i nije poznat slučaj da su nekome kompromitovani podaci. Što ne znači da nema backdoor ili da vlasnik servisa ne može kompromitovati klijentov uređaj. Ili da takođe nema neku rupu. Ali za mene je Seafile podjednako (ne)bezbedan kao i rešenja bez E2E enkripcije. Da ne govorim da je veća verovatnoća da će moji podaci kod malog Seafile-based provajdera biti kompromitovani nego na Google serverima.

Nedeljko, niko od nas nije zanimljiv kriminalcima. Ali ako koristimo servis koji je ranjiv zbog rupe u PHP-u, Javascript-u ili nekom trećem projektu, svako od nas je podjednako ugrožen, bez obzira koji OS ili browser koristi. Neće neki kriminalac reći: "E, ovaj lik pristupa sa Linuxa i iz Firefoxa, neću uzimati njegov pass, lične podatke, info sa kreditne kartice...". I opet, ako neko ima interes tebe da napadne, to što koristiš FOSS te neće izvući.

U svakom slučaju, ne mogu dalje da diskutujem. Imate brdo primera gde je FOSS bušan k'o sir. Na kraju, džabe vam sve to kada vam je firmware na hardveru zatvoren, a i u većini distribucija je neki vlasnički blob u koji zajednica nema uvid. Znate i sami šta koriste ljudi koji zaista brinu o sigurnosti i privatnosti i da to prosečan korisnik nikada neće moći

Da, velika je razlika između "siguran" i "sigurniji".

Međutim, pretpostavka da će neko da pogleda nije razumna. Bleferi iskorišćavaju upravo tu ljudsku slabost: postoji velika razlika između "proverljivog" i "proverenog". Dostupnost sorsa predstavlja samo mogućnost provere, ali to ne znači ništa ako se ta mogućnost zaista ne koristi. Zato je bitno još nešto, što mogu da budu novčane nagrade (ako je politika firme da zaista nagrađuje istraživače i da onda zaista prione na posao da to zakrpi) ili revizije.

A kako ide u kompanijskom slučaju kada se u divljini nađe propust od strane korisnika? Nekada se nude novčane nagrade, OK. Ali beta testeri nikada nisu plaćeni, što znači da su uvek korisnici.

Mit ili ne mit, čovek lupeta po sve četiri tačke, što sam obrazložio.

@Space Beer

Niko nije rekao da je FOSS SIGURAN.

U slučaju FOSS-a ne možeš da ubaciš malver kod koji radi baš to. Možeš da ubaciš nešto što je sigurnosi propust, pa da kažeš: "Nisam namerno, majke mi.". Dakle, donekle se sužavaju mogućnosti za ubacivanje backdoor-a. Takvi backdoor-ovi su pronađeni u FOSS projektima koji nisu imali odgovarajuće revizije.

Takođe, formulacija sigurnosti kao uslovne verovatnoće fasovanja ako te neko napadne, a ne kao verovatnoće da ćeš da fasuješ ne odgovara potrebama. Sada okrećeš priču na nešto drugo - da postoje propusti koji ne zavise od izbora OS-a i browser-a. Pa, to onda ne govori ništa o odnosu sigurnosti jednih i drugih. O odnosu sigurnosti govore primeri gde se razlika pojavljuje, a ne primeri gde se ne pojavljuje.

I u slučaju FOSS-a možeš da ubaciš malware koji radi baš to. Navedeni su slučajevi. Razlika je možda što se brže otkrije, ali to mi ne znači mnogo ako sam ja taj koji je pokupio malware. Takođe, to što koristiš vlasnički softver, ne znači da on ima malware, backdoor ili slično. Kao što ne možeš da tvrdiš da nema, ne možeš da tvrdiš ni da ima. Čak ni da je veća verovatnoća da ima. Baš je u "The Cathedral and the Bazaar" Raymond lepo objasnio kada ima smisla zadržati kod za sebe.

Upravo Linux/FOSS advokati govore da je Linux desktop/FOSS sigurniji od Windows/vlasničkih alternativa, ne uzimajući u obzir navike i potrebe korisnika. To je pogrešno.


Jesi obrazložio, ali nisi u pravu ;)

Ako u FOSS ubaciš backdoor koji radi baš to, ideš u zatvor. Ako ubaciš nešto što može da bude greška (a nije, nego je namerno ubačeno), e onda kunjenje u majku da nije namerno pomaže.

Evo da se ja jednom 100% slozim sa tobom.

Ja zapravo provedoh ovde vreme tupeci o tome da je neophodno negovati kulturu trazenja bug-ova da bi ih bilo sto manje.

Da, velika je razlika izmedju proverljivog i proverenog i tu si u pravu. Opet, iza nekih F/OSS projekata (npr. Linux-a) stoji nekoliko dosta velikih firmi (IBM, Oracle) koje svojim parama podrzavaju i nude podrsku - i koje su radile proveru. Tako da, ako obratis paznju, naci ces na proverene. Ne mislim da je Bane u pravu, postoji velika razlika izmedju "Linus pull" i kernela koji dodje uz Unbreakable Linux ili RH EL.

Da li su oni sigurni? Ne. Da li su provereni? Da. Da li u njima postoji neki namerni backdoor? Jako tesko - pricamo o projektima koje proverava bas bas mnogo ljudi.

Ja ne kazem da npr. Apple ima backdoors, stavise relativno sam ubedjen da ih nema. Za Microsoft vec nisam siguran, iskreno. Zapravo, postoji dosta use cases gde mislim da je bezbednije koristiti Mac, kao deo corporate ekosistema, nego F/OSS softver - uglavnom zato sto na Mac mogu da dodam razne security dodatke (EDR, 2FA, DNS security agent, network admission control agent, sa mogucnoscu izolacije. NetFlow agent... svasta). Da mi je cilj da podrzim kompaniju u US, to je odlican izbor.

Ovo nije jednostavna prica - ali se svodi na neke jako bitne stvari:

- Sav softver ima greske (duh!)
- Da softver ne bi imao greske, mora se aktivno misliti o tome.

Pa imas onu severno korejsku distribuciju :P
Verujem da nui kineske nisu bez toga, a verovatno ni ruske ni neke americke:P
Zato ja verujem Linus-u bar :P

Ako izuzmemo Severnu Koreju, koja se ideološki uopšte ne uklapa u FOSS model (da, kapitalizam se uklapa), ja ne bih izvodio zaključke na osnovu geografije. To je pogrešno. Poverenje se ukazuje na sasvim druge načine.

Zar ne reče Snouden da NSA špijunira svaki Windows računar na svetu?

Reče da može, ali to ne znači da to rade. Realno, imaju oni pametnija posla. S druge strane, sigurno je da MS prikuplja sve što može od svojih korisnika, i analizira te podatke (sve automatski naravno). Pa ako nađu nešto sumnjivo znaju kome da proslede. Otrpilike sve to funkcioniše ovako nekako :D

https://fedi.absturztau.be/media/0ff3e4e5e362e4874b371c409848a80e77dba7e4ecd93a66bd9d0799f1d3d256.jpg

^^ Hahahah, upravo... fokusiras se na kolicinu necijih napora da skriva stvari... a onda ovan na vrata :D

Koliko je bitan ovaj propust ako napadač već može da menja Grub konfiguracione fajlove? Mislim ako je to već slučaj postoji i bezbroj drugih stvari koje može da uradi.

^ svaki bug je vazan jer je potencijalno opasan.
Za sada se informisi sta ti je ciniti da jednostavno resis ako zapadnes u problem.

https://access.redhat.com/solutions/5272311
https://ubuntu.com/security/notices/USN-4432-2

Bitno je da tamo neki ljudi resavaju problem. "Ne tupe tastaturu" u prazno.

http://savannah.gnu.org/bugs/index.php?50809

Ovo iz 2017 btw... nekako jos nema oznaku Fixed.

https://mikegerwitz.com/2012/0...-integrity-with-signed-commits

Ja bih jednostavno samo uklonio GRUB ako sistem ima posten firmware koji moze direktno da ucita Linux (EFI stub: https://wiki.archlinux.org/title/EFISTUB)

OEM sistemi i serverske/WS ploce imaju relativno OK UEFI boot manager implementacije koje podrzavaju visestruke kernele (OS-eve). Na "gejmerskim" plocama kao i konfekciji je nekad potrebno primeniti trikove tipa EFI shell kao inicijalni "bootloader" i sl.

Uklanjanjem GRUB-a se smanjuje kolicina koda koji moze da se exploit-uje - pogotovu ovako loseg koda. Nisu ni neke UEFI firmware izvedbe cvecke ali tu bar mozes da insistiras na Secure Boot i haker ce prvo morati da nadje nacin da upisuje u NVRAM pre nego sto moze da pravi dodatnu stetu na taj nacin.

Plus, mnogo toga se promenilo za ovih 10-tak godina - poterajte CHIPSEC na vasoj masini. Do pre nekoliko godina je situacija bila tuzna (firmware busan ko sito, od SMM exploita preko otvorenog SPI flash-a i pogasenih mera za proveru integriteta pa sve do bagovitih S3 resume skripti) a danas je normalna stvar imati relativno obezbedjenu konfiguraicju "out of the box". Plus, neki vendori (tipa Dell, za divno cudo!) imaju izuzetno prociscene konfiguracije. Nije nemoguce naci rupu i tu, ali je posao daleko tezi nego ranije.

Jesi probao mozda slucajno efistub s nekim linuxom i ako jesi jel radi suspend/resume ok?

Bukvalno u 2022. sa svezim (>= 5.15.xx) kernelima nabasavam na resume koji ne radi kako treba... (freez komplet, samo hard reset ostaje).

Sanjam dan kada ce na Linuxu suspend / resume da radi konzistentno i glatko.

Probao? Intel-ov Clear Linux se tako po default-u i instalira.



Hahahaha, mislim da ces nastaviti da sanjas.

Zato sto suspend/resume prestaje polako da radi i na Windows-u - Microsoft je odlucio da forsira S0ix "Connected Standby" sto je dovelo do laganog nestajanja podrske za S3 u novim CPU/SoC projektima.

I dalje ima desktop/laptop platformi koje podrzavaju S3, ali za sledece 2-3 godine ce to pasti na nulu.

Ostaje jedino da se molis Manitu-u da ce za to vreme nekome poci za rukom da napravi platformu koja ima S0ix koji ne trosi 5% baterije tokom jedne noci. Linux je tu u boljoj poziciji zato sto vecina distro vendora nema interes da registruje gomilu servisa koji smeju da arce struju dok je sistem u standby modu.

Milina. Da ne pricam da u 2022. mora da pljune bar jednu ACPI gresku / zbunjivanje necim pre boot-a, znaci ne mere bez toga.

Plus: Imas cron, pa tacno znas sta treba da se startuje tokom noci.

Minus: Imas cron. :)

Vidim ja, ako hocu laptop koji koristim, zatvorim i odem negde - i dalje cu nositi MacBook.....

Jedan od prvih detalja koji sam počeo da koristim na linuxu je suspend. Vrlo brzo sam i glavno power dugme na kompu podesio da to radi. Obično mi je lakše da komp uspavam tako što pritisnem power dugme nego da kombinujem miškom i tasterom i godinama svaki put tako radim. To mi uglavnom nije uspevalo na windowsu gde se uglavnom odmah ponovo uključi, mada sam izbacio buđenje miškom. Na prethodnim pločama sam podešavao kombinaciju tastera za uključivanje, sada je malo komplikovanije pa i to radim glavnim power dugmetom. Ne znam gde je kod tebe problem, možda se svaki hardver ne ponaša isto a možda i razni linuxi to rade drugačije.

To kod drugara nisam uspeo da izvedem jer bi kod njega ostajalo da radi napajanje.

E da, mislim na sleep a ne na hibernaciju.

Svejedno - to je sve S3

S3 ce nestati zato sto vise ni jedan OEM nece to da testira, Microsoft je jos u 2004 reviziji W10 izbacio podrsku (moguce je i dalje hakovati ali sa sve manjim sansama da radi kako treba na laptopima, a na dekstopima je oduvek to bilo ruski rulet).

Connected Standby zahteva bukvalno da >sve< radi savrseno - znaci sve povezano na PCH tj. I/O hub mora da ode da spava, sam procesor isto tako, ne sme nista da nastavlja da bombarduje interaptima - tek onda PCH kaze "e, ok, sad mogu da ugasim struju", isto kao i za CPU PCx stanja (PC10) koja su za ceo paket - da to prodje, ne sme nista da dr*a procesor preko mere. Ako hoces min potrosnju - mora i RAM i kes da se ugasi, isto kao i refresh ekrana i sl.

Znaci softver i drajveri (heh) moraju da rade kako treba i bez przenja CPU ciklusa za dzabe (o I/O da ne pricamo).

Ajd nekako to sve i izvedes (moze - evo ti jedan recept npr: https://github.com/psyq321/Dell5750FirmwareOptimizationRecipe) ostaje NAJVECI problem: hardver.

Apple je od kad znam za sebe uvek to imao kao #1 prioritet - kada je masina/telefon/tablet u standby, potrosnja je stvarno minimalna moguca. Iz nekog razloga, celokupna PC i Android industriija sa tim ima problem otprilike koliko i sa kontrolisanom termonuklearnom fuzijom.

Deo problema su softver+drajveri ali siguran sam da je drugi deo problema jednostavno jeftin hardver, tj. komponente. Da bi imali prakticno nista od potrosnje, kola moraju biti optimizovana za to, odabrane komponente sa najboljim karakteristikama. Ocigledno je da PC ekipa to ne radi.

Zato taj moj Dell laptop - uprkos svoj optimizaciji koja stvarno pogasi sve sto moze i dalje trosi 800 mW - sto? Pa pitaj hardver jbg.

--

S3 nije imao problema sa ovim, zato sto S3 gasi sve.

Ali... kako ce onda Cortana da radi? :))))

Jbg...

Btw, brz ovaj Clear Linux prilicno :)