Slo-Tech - Pisali smo že o ranljivosti, ki so se v kakšni kodi skrivale desetletja, to pot pa gre za dvajset starega hrošča v kodi, ki je bil tam namenoma. Pred dvajsetimi leti je bilo upravljanje z energijo ACPI še v povojih, strojna oprema pa ni vedno delovala, kot bi pričakovali. Na sistemih z AMD-jevimi procesorji Athlon se je zgodilo, da procesor ni hotel v stanje pripravljenosti, ko smo to od njega želeli, zato je Linuxovo jedro dobilo berglo. Tako imenovano prazno čakanje (dummy wait op) je predstavljalo izvajanje nepotrebnih bralnih operacij, ki so poskrbele, da je imel procesor čas izvesti ukaz STPCLK#.
Dvajset let pozneje je v kodi še vedno enak pristop, čeprav so moderni Threadripperji neprimerljivi z Athloni, predvsem pa niso pokvarjeni. Težave dlje časa ni nihče opazil, ker ni bila zelo očitna. A novi procesorji imajo čedalje več jeder, prilagajanje frekvence in več stanj delovanja, ko se posamezne funkcije procesorja lahko izklopijo. Zaradi varčevanja z energijo se to pogosto dogaja med delovanjem. Rezultat so čedalje opaznejše upočasnitve, saj se vsakokrat brez potrebe čaka.
Pohvalno, vsa čakalna stanja so potratna, samo nekje so nujna, kot v tem primeru.
Meni je Ryzen 1, zmrzoval enkrat na teden, če sem šel gledat kaj se je zgodilo, sem ven dobil ven strojno napako, nimam več tega sistema, nevem ali je to to?
Grem stavit, da so to v zaprtih verzijah linuxa vsaka firma po svoje že zdavnaj popravili, npr. v sistemih, kjer je procesorski timing ključnega pomena. Problem je, ker večina njih ne commita nazaj v skupnost.
"If we were supposed to talk more than listen
we would have been given two mouths and one ear"
- Mark Twain
Grem stavit, da so to v zaprtih verzijah linuxa vsaka firma po svoje že zdavnaj popravili, npr. v sistemih, kjer je procesorski timing ključnega pomena. Problem je, ker večina njih ne commita nazaj v skupnost.
Grem stavit, da so to v zaprtih verzijah linuxa vsaka firma po svoje že zdavnaj popravili, npr. v sistemih, kjer je procesorski timing ključnega pomena. Problem je, ker večina njih ne commita nazaj v skupnost.
Licenca Linuxa to prepoveduje. Ce firma spremeni Linux jedro, mora dati na voljo spremembe vsem zainteresiranim. V praksi to ni ravno vedno, sigurno pa vecje firme to spostujejo.
Licenca Linuxa to prepoveduje. Ce firma spremeni Linux jedro, mora dati na voljo spremembe vsem zainteresiranim. V praksi to ni ravno vedno, sigurno pa vecje firme to spostujejo.
GPL tega ne pravi. Če jaz nekaj flikam po gpl kodi, mi ni treba tebi nič kazat kaj delam.
GPL tega ne pravi. Če jaz nekaj flikam po gpl kodi, mi ni treba tebi nič kazat kaj delam.
Tako je. Če jaz prav razumem GPL, mora uporabnik imeti kodo na vpogled. Naj me kdo popravi, če se motim.
Jaz tudi tako razumem. Če delaš zase, ni treba nikomur dati v vpogled spremenjene kode.
Če prodaš produkt, moraš zraven priložiti izvorno kodo, ki jo kupec lahko prosto razširja naprej če želi. Ni pa kupec obvezan deliti kode s komerkoli drugim če je ne želi.
Pohvalno, vsa čakalna stanja so potratna, samo nekje so nujna, kot v tem primeru.
Meni je Ryzen 1, zmrzoval enkrat na teden, če sem šel gledat kaj se je zgodilo, sem ven dobil ven strojno napako, nimam več tega sistema, nevem ali je to to?
Popravljeno. Prve verzije prve generacije... Uporabljam 1k,3k,5k,.. serije in se pojavlja pri meni samo pri zgodnjem 1700. Dodan kernel parameter - deluje stabilno 24/7.
Licenca Linuxa to prepoveduje. Ce firma spremeni Linux jedro, mora dati na voljo spremembe vsem zainteresiranim. V praksi to ni ravno vedno, sigurno pa vecje firme to spostujejo.
GPL tega ne pravi. Če jaz nekaj flikam po gpl kodi, mi ni treba tebi nič kazat kaj delam.
A nisem jasno napisal, da ce firma spremeni jedro. Linux skupnost zivi od prispevka firm. Zato sem se obregnil ob komentar, da firme skrivajo popravke za take hrosce kot je opisan v novici.
Za lastno uporabo tudi firma lahko skrije popravke na GPL kodi in jih ima le zase.
Ampak v praksi se tega ne pocne pri kernelu, ker potem bi ta firma morala vzdrževati fork za vsak kernel release in je v interesu firme da tak popravek pride do glavnegs brancha da se temu vzdrževanju ognejo.
Licenca Linuxa to prepoveduje. Ce firma spremeni Linux jedro, mora dati na voljo spremembe vsem zainteresiranim. V praksi to ni ravno vedno, sigurno pa vecje firme to spostujejo.
GPL tega ne pravi. Če jaz nekaj flikam po gpl kodi, mi ni treba tebi nič kazat kaj delam.
A nisem jasno napisal, da ce firma spremeni jedro. Linux skupnost zivi od prispevka firm. Zato sem se obregnil ob komentar, da firme skrivajo popravke za take hrosce kot je opisan v novici.
Vseeno je kdo spremeni karkoli, pod GPL mu ni treba dati nicesar na vpogled. Dokler ostane lepo za interno uporabo.
Pojdite volit drugi krog volitev. Prepricujejo vas, da se ne
splaca, zato, da bi SDS (Logar) sploh imel moznost zmagati.
In v kolikor bo, bo to zato, ker se niste udelezili volitev.
