- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Mintha csak az Apple keze lenne a dologban, ök szoktak hasonló bug-okkal elöállni.
Erre szokott az lenni a válasz, hogy használj LTS-t, csak az a baj ezzel, hogy akkor ki fog bétatesztelni?
Aki meg tesztel persze ne lepödjön meg azon, ha a rendszere nem úgy müködik, ahogyan szeretné.
Ilyenkor bukik meg az elmélet, hogy a linuxhoz tudni kell HW-t venni.
Az megbocsáthatatlan, ha egy szoftver tönkreteszi a vasat.
--
robyboy
- A hozzászóláshoz be kell jelentkezni
ugyan már, ez rendben van mer linuksz
- A hozzászóláshoz be kell jelentkezni
pontosan
- A hozzászóláshoz be kell jelentkezni
intel... ezért szurkolok az armnak meg az nvidiának.
--
GPLv3-as hozzászólás.
- A hozzászóláshoz be kell jelentkezni
az nvidiának? :D ez jó vicc volt...
"all submitted complaints will be forwarded to /dev/null for further investigation"
- A hozzászóláshoz be kell jelentkezni
Főleg, ha kevered a szezont a fazonnal. A "hardvert venni tudni kell" nem erre vonatkozik, hanem támogatottságra.
Nyilvánvaló, hogy megengedhetetlen, hogy egy szoftver tönkretegyen egy hardvert. A problémát inkább ott látom, hogy OS telepítés sosem végződhetne ilyen hibával. Az a hardver, amit egy installerrel ilyen szinten haza lehet vágni, az eleve szarul tervezett valami.
A szánalom az, hogy az Apple a saját vasán képes ezt a mutatványt előadni. Amit elve ő gyárt(at).
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Vagy 15 éve az egyik Linux terjesztés (talán Mandrake???) az egyik LG CD-író firmwaret vágta haza.
Érdekes módon semmi mást csak azt! Na erre hogy lehetett volna felkészülni?
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox
- A hozzászóláshoz be kell jelentkezni
Az LG CD-író firmware-ét kellett volna úgy megírni, hogy ilyen ne fordulhasson elő.
Több dolog egyezőségét kell ilyenkor vizsgálni, pl.:
- formátum
- lemezcímke
- teljes fáljnév
- a fájl megfelelő helyén egyedi karaktersorozat, amolyan fejléc jelleggel, ami csak arra az egy típusra jellemző
- a firmware mérete
- CRC
stb.
Ha minden stimmel, csak akkor hihetné el a CD-író, hogy ebben az állományban az ő firmware-ének frissítéséhez szükséges dolgok vannak.
A feltételeknek megfelelő dolgokat véletlenül elég nehéz lenne előállítani.
- A hozzászóláshoz be kell jelentkezni
Vegyük már észre, hogy a firmware-ek egyik sajátossága, hogy írhatók. Régen még védték öket hardveres jumperekkel az írástól, és igen, az volt az egyetlen és jó védelem. Aztán ezt felszámolták, mert megspóroltak vele egy csomó gyártási költséget.
Szofver oldalról meg a jelszavas levédés lehetne opció, ha valaki frissíteni akar, kérjen jelszót, ami változtatható lenne házilag.
Nem tudom amúgy, ha a bios le van védve jelszóval, akkor is lehet frissíteni? Sosem próbáltam.
--
robyboy
- A hozzászóláshoz be kell jelentkezni
Szerintem ne "régen"-ezzünk. Itt a laptopom idevágó BIOS-beállítása (jaaaj, trey-nek nem romlott el a gépe, mik vannak):
Be van állítva, hogy End-User ne tudjon BIOS-t flash-elni jelszó ismerete nélkül. Ha ennek ellenére egy telepítő vagy op. rendszer képes összebaszni a BIOS-t, az igenis a gyártó hibája.
A többi maszatolás, ahogy lentebb megjegyezték (csak rosszul).
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Ez ok, ezen kívül pedig:
Ránéztem az Ubuntu oldalára. A certified hardware-knél csupán a két támogatott LTS verzió választható opció:
https://certification.ubuntu.com/desktop/
Szóval aki nem LTS-t használ, az ne reklamáljon, még akkor sem, ha a gyártó hibájából vágja szét a gépet a szoftver.
--
robyboy
- A hozzászóláshoz be kell jelentkezni
ingyen van, mit vársz. :)
- A hozzászóláshoz be kell jelentkezni
Èn semmit. Amúgy pár száz eszközt támogat a két LTS verzió mindösszesen, ami eléggé sovány felhozatal szerintem, ahhoz mindenképpen, hogy a desktop piacon komolyan labdába rúgjanak.
Bármennyire is szar a Windows, eljutottunk oda, hogy sokkal jobban támogatja a különféle hardvereket. Nem volt ez mindig így, még a 90-es években a Linux ezen a fronton jobban teljesített.
--
robyboy
- A hozzászóláshoz be kell jelentkezni
1,A linux lehet, hogy igen, de ubuntu nem volt. Most te egy disztrót veszel alapul, ez így hibás megállapítás.
2, A windows támogatását ne feszegessük. Messze van az még attól is, hogy beszéljünk róla, bár némi javulás valóban történt...
üdv: pomm
A 852-es kídlap telepötúsa sikeresen befejezádétt
- A hozzászóláshoz be kell jelentkezni
Nem volt ez mindig így, még a 90-es években a Linux ezen a fronton jobban teljesített.
El tudom képzelni, mikor még a kilencvenes évek vége felé is felhasználói ráhatás kellett egy elterjedt videokártya vagy épp egy sima PS/2 egér ~működésre bírására... A Linux disztróban a driverek konfigurálására ugyanannyi idő elment, mint Windowsnál a hardverhez mellékelt driver telepítésére. A különbség annyi volt, hogy Windowson általában működött is a cucc, míg Linuxnál már annak is örült az ember, ha működésre utaló jeleket látott.
:)
- A hozzászóláshoz be kell jelentkezni
Azért a Windows 95 eléggé egy szopóálarc volt... persze a linuxhoz már akkor is tudni kellett hardvert venni, pedig akkor még alig lehetett certified hardver... vagy éppen nem is volt?
--
robyboy
- A hozzászóláshoz be kell jelentkezni
+1 - most is rohadt nagy szopóálarc, amikor megpróbálsz linuxon elterjedt videokártyákat működésre bírni... user oldalról csak a puszta szerencséden múlik, h működik-e vagy sem. (linux user IS vagyok)
-------
It is our choices that define us.
- A hozzászóláshoz be kell jelentkezni
én baromi erősen meg lennék lepve ha ez magától alakult volna így. lásd nvidia (direkt kisbetűvel)
"all submitted complaints will be forwarded to /dev/null for further investigation"
- A hozzászóláshoz be kell jelentkezni
Vegyük már észre, hogy én sem állítottam azt, hogy egy firmware ne legyen írható a felhasználó által, pusztán azt mondom, hogy az írási folyamat csak bizonyos feltételek teljesülése esetén történhessen meg. Ha egy LG-író firmware-e egy akármilyen lemez akármilyen tartalmának beolvasásakor "véletlenül" felülíródik, akkor ott komoly problémák vannak a fejlesztői oldalon.
- A hozzászóláshoz be kell jelentkezni
+1
User inputot mindig ellenőrizzük.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
+1 :)
--
robyboy
- A hozzászóláshoz be kell jelentkezni
Erdemes viszont Linus mantrajat is elhozni -- 'we don't break userland'. Tehat ha valami eddig mukodott a felhasznaloi oldalon, es egy alacsonyabb szintu komponens valtoztatasa azt megtori, akkor hiaba 'fixaltak egy bugot' az adott komponensben, ez nem jo erv arra, hogy miert doglik meg az userland.
----------------------
while (!sleep) sheep++;
- A hozzászóláshoz be kell jelentkezni
Az userspace és a BIOS minden csak nem userspace.
- A hozzászóláshoz be kell jelentkezni
az userspace nem userspace? mivan?
"all submitted complaints will be forwarded to /dev/null for further investigation"
- A hozzászóláshoz be kell jelentkezni
Az userspace, és a BIOS minden csak nem userspace.
- A hozzászóláshoz be kell jelentkezni
Egy vessző a megfelelő helyre teve néha nagy jelentésbeli változásokat tud hozni.
http://writingwithaesop.blogspot.hu/2011/10/lets-eat-grandma.html
--
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Az userspace, és a BIOS minden, csak nem userspace.
- A hozzászóláshoz be kell jelentkezni
Az userspace; és a BIOS minden, csak nem userspace.
- A hozzászóláshoz be kell jelentkezni
A pontosvessző indokolatlan, mivel itt nem többszörösen összetett mondatról van szó.
- A hozzászóláshoz be kell jelentkezni
Indokolatlan, mivel nincs megindokolva.
- A hozzászóláshoz be kell jelentkezni
Annyi volt az eredeti történet, hogy az LG CD-ROM-ok az opcionális ATAPI FLUSH_CACHE parancs helyett ugyanarra a parancskódra implementált UPLOAD_FIRMWARE funkciót hajtották végre. A linux fejlesztőknek annyi róható fel, hogy hatékonyabb kódot szerettek volna írni. Ha a gyártó 'hülye', akkor arra valóban nem lehet felkészülni.
https://www.theregister.co.uk/2003/10/29/mandrake_linux_ate_my_cd/
- A hozzászóláshoz be kell jelentkezni
soha egyik frissítés sem tette tönkre egyik hardveremet sem ami az Appletol jött. :(
- A hozzászóláshoz be kell jelentkezni
Nekem meg soha semmilyen frissítés sem tette tönkre egyik hardveremet se, akárhonnan is jött.
Én nyertem!
--
♙♘♗♖♕♔
- A hozzászóláshoz be kell jelentkezni
nekem igen, tehat tevedsz, nincs igazad
- A hozzászóláshoz be kell jelentkezni
Az Ubi bug sem jön elő mindenkinél, tehát fifty-fifty ;)
--
robyboy
- A hozzászóláshoz be kell jelentkezni
Sőőt, még a Windows sem vágott haza soha semmit, pedig vagy 100 ezret telepítettem fénykoromban.
--
robyboy
- A hozzászóláshoz be kell jelentkezni
Jo, hogy a linkelt cikkben egy szo sincs errol, amit allitasz.
--
L
- A hozzászóláshoz be kell jelentkezni
Az nem tűnt fel, hogy nem a cikkre írt választ, hanem robyboy hozzászólására?
--
♙♘♗♖♕♔
- A hozzászóláshoz be kell jelentkezni
Egesd magad tovabb :)
--
L
- A hozzászóláshoz be kell jelentkezni
Jah! Bar a sajat vason is, azert eleg egyszeru elszurni ha van tobb revision es pont azon pont ugy nem tesztelik ...
- A hozzászóláshoz be kell jelentkezni
Btw az Ubuntunál nem a standard "as is" warranty van mindenre? Ergo nincs? Ha igen, akkor nincs értelme az applet iderángatni, végül is ott azért ennél azt hiszem, hogy ennél több van vállalva.
Attól még kellemetlen hiba.
- A hozzászóláshoz be kell jelentkezni
április 1 van trej? nem úgy volt hogy a linxuéknál nincsenek hibák?
- A hozzászóláshoz be kell jelentkezni
Anno a Mandrakelinux nyírt ki nálam 2db LG CD meghajtót.
Párhét után elismerték az iso-ban volt olyan dirib-darab, amit a CD olvasó BIOS frissítésnek gondolt.
- A hozzászóláshoz be kell jelentkezni
az nem nagy probléma, hogyha a linux anyagi károkat okoz, mert legalább ingyen volt!
ha viszont az apple fun-ból berak egy featuret (amit nem kötelező használni...) a telefonjaiba (amiket nem kötelező megvenni...) akkor trey már az istenhez is imádkozva szarozza le napi 50x a márkát.
objektív látásmód ftw!
- A hozzászóláshoz be kell jelentkezni
es jogosan, mert szar is :)
- A hozzászóláshoz be kell jelentkezni
Dehogy! It just works! Ja? Dehogy!
Apple seems to have forgotten about the whole 'it just works' thing
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
ez sem semmi!
Átmenetileg visszavonták az Ubuntu 17.10 letöltési linkjeit BIOS korrupciós hiba miatt
- A hozzászóláshoz be kell jelentkezni
1 infinite loop
- A hozzászóláshoz be kell jelentkezni
:D
-------
It is our choices that define us.
- A hozzászóláshoz be kell jelentkezni
persze, hogy szar. de ha az ubuntu megoli az alaplapod akkor egyszerre veszed mosolyogva a szadba mark es linus ferfiassagat. ugye? :)
- A hozzászóláshoz be kell jelentkezni
csak ha adnak masik alaplapot :)
- A hozzászóláshoz be kell jelentkezni
> amit a CD olvasó BIOS frissítésnek gondolt
Ez nyilván oprendszerhiba. (nem.)
- A hozzászóláshoz be kell jelentkezni
+1
"all submitted complaints will be forwarded to /dev/null for further investigation"
- A hozzászóláshoz be kell jelentkezni
Ha nem ír az Ubuntu bugjairól az a bajod, ha ír akkor meg az. Nehéz eset vagy. :D
- A hozzászóláshoz be kell jelentkezni
Teglásított BIOS a Buguntuban.
Thnx Intel!
- A hozzászóláshoz be kell jelentkezni
Nekem a Lenovo G50-45 -ön szerencsére nem jött ez a probléma. Ne is jöjjön :)
A disztró-hopperkodásból kifolyólag sem :) De ki az a ...... aki Buguntut tesz a gépére? Milyen kezdő az?? :D ;)
- A hozzászóláshoz be kell jelentkezni
Miért?
A Trey pl. az?
- A hozzászóláshoz be kell jelentkezni
nem, trej az isten.
- A hozzászóláshoz be kell jelentkezni
Nem. Gyuri az Isten!
Klárikám ...
Hol vagy?
- A hozzászóláshoz be kell jelentkezni
buguntu, trej jével, tényleg a dedóban vagyunk, vagy ovis szintű névcsúfolásnál jobbra nem telik?
- A hozzászóláshoz be kell jelentkezni
Azok iOS autocorrect bugok.
:)
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Ilyen a zUbuntu! Hol rombol, hol megGyógyít! :D
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox
- A hozzászóláshoz be kell jelentkezni
Van az a helyzet, amikor az Ubuntu megfelelő. Nekem most ér véget egy 2-3 hónapos fix projektem, ahova külső gépet nem tudtam bevinni, viszont a belsőre telepíthettem. Mivel Linuxon szeretek dolgozni, ezért felcsaptam rá egy Ubuntut. Arra nem akartam energiát befektetni hogy a kedvencemet felrakjam és customizáljam (Arch). Egyébként a fő munkagépem sok éve az. Pénteken a projekt végén letörlöm, oszt jónapot.
--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead
- A hozzászóláshoz be kell jelentkezni
Van Ubuntu radírod is? :)
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox
- A hozzászóláshoz be kell jelentkezni
Ja, toltam egy rm -rf -et a home folderemre, utána meg egy dd -t a blokkeszközre. :)
--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead
- A hozzászóláshoz be kell jelentkezni
ha jol ertem, akkor intel only a hiba, tied meg amd.
- A hozzászóláshoz be kell jelentkezni
(sub)
- A hozzászóláshoz be kell jelentkezni
Amióta Gnome 3-ra visszaálltak, már telepítettem egyet és teljesen jól fut. A BIOS-"korrupció" nekem inkább AMT-vel basz*kodó hülyegyerekeket feltételez, sem mint az Ubuntu-t magát. (Max. kezükbe adja a "drótot" hozzá.)
- A hozzászóláshoz be kell jelentkezni
Az ubuntu standard desktop kiadása már Gnome-os?
--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead
- A hozzászóláshoz be kell jelentkezni
Lemaradtál?
https://lists.ubuntu.com/archives/ubuntu-announce/2017-October/000226.h…
Ubuntu Desktop has had a major overhaul, with the switch from Unity as
our default desktop to GNOME3 and gnome-shell.
- A hozzászóláshoz be kell jelentkezni
Csak annyira érdekel az ubuntu hogy a hupon olvassak róla :)
--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead
- A hozzászóláshoz be kell jelentkezni
Sokak által várt trollkodás:
A hiba csak a Mészáros és Mészáros Kft. által gyártott lapkákat érinti.
- A hozzászóláshoz be kell jelentkezni
A probléma valószínűleg megoldható két teljes reboot-tal, miután a letiltásra kerül az driver (SPI-NOR) :
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1734147/comments/1…
https://github.com/torvalds/linux/commit/d9018976cdb6eefc62a7ba79a405f6…
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Sajnos, ezt még senki sem erősítette meg..
Az már egy elég nagy probléma, hogy az Ubuntuba ilyen kód egyáltalán bekerülhet. Azonban hibák mindenütt előfordulnak, csak hatalmas blamázs.
Az viszont gondolkodásra ad okot és nálam mostantól kilövi a rendszer használatát, ahogy a problémához álltak hozzá (hülyének nézik az embert):
"ez nem az Ubuntu hibája"
"a Lenovo-t kérdezd"
aztán mikor előjöttek más laptopokon is
"a BIOS szállítójának hibája"
sőt kiderült, hogy ezt már nyáron jelezték nekik, de lezárták a kérdést, SŐT ki is törölték még a nyomát is, mert kényelmetlen volt
https://launchpadlibrarian.net/349959106/askubuntubiosissues.png
Tipikus: you're holding it wrong
Szerk
Most már egy vicc az egész, komolyan mondom ilyen embereknek miért adnak írási jogot bárhova:
"I think we are off on the wrong track. This is fundamentally a CVE against Insyde Software BIOS and possibly other vendors. Any attacker with kernel mode access could do the same thing, regardless of Linux install."
Tudja mi az a CVE egyáltalán? Kernel módban le is nullázhatod a BIOS-t. Ezt is jelentse már! Az összes hozzászólást le kellene menteni és mehetne egy IT kabaréba.
- A hozzászóláshoz be kell jelentkezni
Ez a hiba nagyon gáz, de néhány dolgot hadd jegyezzek meg:
"ez nem az Ubuntu hibája"
Ha a mainline kernelben benne van a hibás kód, akkor ez _nem csak_ az Ubuntu hibája.
"sőt kiderült, hogy ezt már nyáron jelezték nekik, de lezárták a kérdést, SŐT ki is törölték még a nyomát is, mert kényelmetlen volt"
Nem "nekik". Az askubuntu nem bugtracker, egy közösségileg egyengetett kérdezz-felelek fórum, a Stack Exchange része, nem sok köze van az Ubuntu-hoz (a témáján kívül). Az, hogy miért törölték egy fórumról, az jó kérdés. Az, hogy ha buot akart bejelenteni az Ubuntu-nak, akkor rossz helyre jelezte, az biztos.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
most akkor megy a magyarázkodás? :S:S:S:S
- A hozzászóláshoz be kell jelentkezni
“Ha a mainline kernelben benne van a hibás kód, akkor ez _nem csak_ az Ubuntu hibája.”
Hasonlattal elve, ha a szakacs megfozi a romlott hust, es te beteg leszel, az sem a szakacs hibaja, mert romlottan kapta mar? :)
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"
- A hozzászóláshoz be kell jelentkezni
Lassan kéne írnom egy "minimum követelmény a HUP-hoz" FAQ bejegyzést, amiben benne lenne az "értő olvasás" követelményként.
A "nem csak" mit jelent szerinted?
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
> A "nem csak" mit jelent szerinted?
Maszatolás?
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
- A hozzászóláshoz be kell jelentkezni
Mert szerinted ha bekerült a mainline kernelbe, akkor az Ubuntu-n kívül más - pl. a maintainer, aki ellenjegyezte a patchet - nem hibázott.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Nagyon jók az ilyen semmilyen kommentek. Ha én veszem a fáradságot, hogy normálisan válaszolok, akkor elvárnám, hogy akivel beszélgetek, szintén vegye a fáradságot, hogy kifejti a véleményét.
Ha szeretnél valami érdemi érvet letenni az asztalra, nyugodtan tedd meg.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
" Az askubuntu nem bugtracker, egy közösségileg egyengetett kérdezz-felelek fórum, a Stack Exchange része"
Teny, a kepen a Canonical Group tanusitvanya zavart meg.
- A hozzászóláshoz be kell jelentkezni
Teljesen mindegy. A Canonical segít a Stack Exchnage-nek fenntartani, gondolom ennek része, hogy vesz rá tanúsítványt.
Az egy community support fórum. A bugtracker tök más fogalom.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
ott a launchpados link a képen, az hivatalos. Mindegy, ezt Márkék csúnyán elszabták, hogy nem néztek utána.
Nem kell jópofizni a zintellel, keményen rájuk kell borítani a bilit ha elkúrnak valamit.
Van elég pénzük, vegyenek fel több debuggert. Ez érvényes az applere is.
--
GPLv3-as hozzászólás.
- A hozzászóláshoz be kell jelentkezni
Ne legyél már ennyire hülye... "Edited 13 hours ago"
Ott a link:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1734147/
November 23-án hozták létre. Az Ubuntu 17.10 októberben jelent meg.
Az illető 13 órával ezelőtt szépen beleszerkesztette egy 4 hónappal ezelőtti kommentbe.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
haha és tényleg, a júliusi kommentbe betette a novemberi linket a kis geci.
Akkor ezt le is zárhatjuk, tényleg nem jó helyen jelezte a srác a problémát. Márkék meg elmehetnek a picsába, hogy azt a posztot nem vették komolyan. Aki lezárta azt a topicot, mint offtopic az is elmehet a picsába.
Szóval sokan elmehetnek a picsába ezzel a buggal kapcsolatban. Úgyhogy én is elindultam, szevasztok...
--
GPLv3-as hozzászólás.
- A hozzászóláshoz be kell jelentkezni
Még egyszer megjegyezném, hogy az Ask Ubuntu-nak semmi köze a hivatalos bugtracker-hez (Launchpad). Az egy community support fórum, ami kap (anyagi) segítséget néha a Canonical-tól (a téma miatt), de egyrészt user-driven, másrészt nem nem bugracker. Az üzemeltetője a Stack Exchange Network.
Hibakövetésre és megoldásra teljesen alkalmatlan felület és ebből kifolyólag a Canonical/Ubuntu fejlesztők valószínűleg nem is követik.
Kb. mintha én egy iOS hibát a meszmac.com-ra jelentenék be, aztán csodálkoznék, ha nem történik semmi.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
én csak azt nem értem, hogy egy hibátlan és tökéletes rendszerhez, minek kell egyáltalán bugtracker. :(
- A hozzászóláshoz be kell jelentkezni
Ki mondta, hogy hibátlan, és tökéletes rendszer?
- A hozzászóláshoz be kell jelentkezni
A hangok. Egy almából átmászott féreg adja ki őket. Valószínűleg csak böfög és fingik, de az ember mindenben a valamit keresi.
:)
- A hozzászóláshoz be kell jelentkezni
Es a twitter mennyivel jobb bugkoveto rendszer?
Mert az utobbi idoben eleg sok bugot ott jelentenek be....
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
- A hozzászóláshoz be kell jelentkezni
Kevered a dolgokat szerintem. Amikor te azt látod a Twitter-en, hogy ott hibákat jelentenek be, akkor azokat általában rég jelezték már az érintett cégek felé.
Főként biztonsági hibákat jelentenek ott be, de ha megnézed a disclosure timeline-ját egy-egy hibának, akkor azt láthatod, hogy a felelős közlés miatt azt akkor már rég jelezték a gyártónak.
Egy-egy ellenpéldából felesleges messzemenő következtetéseket levonni. Minden Ubuntu kiadás release notes-ében ott a megjegyzés és a link, hogy HOVA KELL bejelenteni a hibát:
https://help.ubuntu.com/community/ReportingBugs
Első lépés, hogy készíts egy Launchpad accountot. Kifejezettek ki van emelve, hogy ha nem bugot akarsz bejelenteni, hanem támogatást akarsz kérni, akkor menj a mindenféle support csatornára - Ask Ubuntu, IRC csatorna stb.
Még egyszer: a bugreport és a support kérése nem ugyanaz. Hibát bejelenteni a megfelelő módon és helyen kell. Úgy lesz hibajegye, úgy kerül a megfelelő team-hez, úgy tud a fejlesztőcsapat további infókat kérni, úgy tudják kiadásokhoz rendelni, úgy tudnak súlyossági besorolás alá tenni és minden egyebet úgy tudnak vele megcsinálni, amit egy bugtracker-ben lehet, de nem lehet egy fórumon.
Egyébként aki a napi munkája során használ bugtracker-t, az tudja mi a különbség mondjuk egy vBulletin meg egy Mantis közt.
Akinek nincs fogalma, az nézzen utána. Nem hiszem, hogy neked mesélnem kéne neked ezeket, szerintem egyszerűen csak trollkodsz.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Szerintem a bugreport igy nez ki:
1. felmesz egy support csatornara (pl. ask ubuntu), es leirod a problemad, hogy masnal is jelentkezik-e, vagy user error.
2. amennyiben masnal is megvan a hiba, akkor bugreport.
A gond akkor van, hogyha az egyes pontot bezarjak offtopik miatt (itt ez tortent), vagy a 2-es pontig senki se jut el.
DE, mivel ez egy eleg kritikus hiba, igy a 2-es pontot nem csak az eredeti kerdezo teheti meg. Veheti mas is a faradtsagot, hogy bejelenti.
A twitterre visszaterve, rengeteg apple ios es macos hibarol irtal te magad,
amit kizarolag a twitteren jelentettek be eloszor.
Volt valami mexikoi sofor, aki bruteforce kitalalta, hogyan kell belepni iphoneba, vagy egy eve. Sztem az is twitter-only volt.
Most volt, hogy a jelszo mezo nincs fokuszban, es kiposztolta slack-re, sztem az is twitter-only volt.
Es akkor mintha te magad mondtad volna, hogy mit var az apple, amikor nincs normalis hibabejelento rendszere.
Osszefoglalva: Szerintem hibas hozzaallas az, hogyha tudsz az esetrol,
csak azert nem foglalkozol vele (barmilyen kritikus is),
mert nem pontosan ugy jelentettek be, ahogy elvarod.
De ez csak az en velemenyem.
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
- A hozzászóláshoz be kell jelentkezni
Én 2006 óta a Launchpad-et használom a bugok kezelésére:
https://bugs.launchpad.net/~gmicsko
Nekem bevált!
Útbaigazítottalak, ha ezután is tartod magad a rögeszméidhez, akkor magadra vess. Világosan le van írva a bugreport menete. Véleményed persze lehet ettől. Végül is mindenki úgy baszik ki magával, ahogy akar.
PS: én bug bounty programról írtam, ami megint más, kevered a dolgokat újra.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
jaj latom. Kemeny egy bugra van workaround 14.04-bol a masik bugreport "elhalt".
Ha mar tanacsokat osztogatsz, en is adok egyet, hatha a jovoben tenyleg bugot akarsz javittatni: kernel.org. Oda kell a bugot bejelenteni.
De elotte ki kell jarni a szamarletrat, stackoverflow-n rakerdezni,
tuti nem te vagy a hulye, es amikor 100%, akkor ott bejelented.
De ott azert vigyazni kell, mert magas lovon ulnek az illetok, igy vagy elso korben tokeletes a bugreport, vagy pedig megy a fikazas az erdemi dolog helyett.
En javitattam mar igy suspend bugot, videokartya bugot, miegyebet.
Persze ugy szopatod magad a launchpaddal, ahogy jonak latod.
De ubuntueknal komoly javitasra ne szamits. Max csomagolasi hibak.
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
- A hozzászóláshoz be kell jelentkezni
Na, látod. Pontosan ezt hívják maszatolásnak. Amit csinálsz.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1734147/comments/1…
Inkább tűnik ez szerencsétlen egybeesésnek, mint hibának.
Ha elolvassátok az első leírást ami a fenti linken található, kiderül belőle:
Not all manufacturers protect the SPI serial flash, mainly because it allows upgrading the BIOS image directly from an OS.
The intel-spi driver makes it possible to read and write the SPI serial flash, if certain protection bits are not set and locked. If it finds any of them set, the whole MTD device is made read-only to prevent partial overwrites. By default the driver exposes SPI serial flash contents as read-only but it can be changed from kernel command line, passing "intel-spi.writeable=1".
Szóval két dolog lehetséges szerintem:
- Ubuntu-ék / Kernel fejlesztők gondoltak egy merészet és defaultba beállították, hogy legyen csak writeable a flash :) (ez akkor Ubuntu / Kernel bug)
- vagy az érintett gyártó implementációja gáz, mert olyan területekre történik írás egy operációs rendszer telepítése során (nem BIOS frissítés, mert az Ubuntu ilyet asszem azért alapból installkor nem csinál ...) ahova nem lenne szabad
Én a másodiknak adok nagyobb esélyt, de simán lehet az első is.
Biztonsági szempontból nem tűnik jó ötletnek mezei op.rendszerből BIOS frissítgetni, ennyi erővel egy kártevő is dönthet úgy, hogy ideje másik BIOS-t betölteni, mondjuk olyat ami titkosítja a disket és bitcoinért cserébe visszaállít ... hm? :)
A cdírós firmware-es történet meg egyenesen hajmeresztő ... a cd (minden) olvasása közben a driver mintát keres és ha valami hasonlít egy cd firmware-re akkor azt benyalja és onnantól "ujj a torkon ..." ahogy Drex mondaná.
szerk: ez mondjuk gyanús :)
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git…
author Bin Meng 2017-09-11 02:41:53 -0700
committer Greg Kroah-Hartman 2017-11-30 08:40:55 +0000
spi-nor: intel-spi: Fix broken software sequencing codes
commit 9d63f17661e25fd28714dac94bdebc4ff5b75f09 upstream.
There are two bugs in current intel_spi_sw_cycle():
- The 'data byte count' field should be the number of bytes
transferred minus 1
- SSFSTS_CTL is the offset from ispi->sregs, not ispi->base
- A hozzászóláshoz be kell jelentkezni
Azt azért látni kell, hogy évek óta frissíthetö a firmware így-úgy-amúgy, op.rendszer alól. Ez egy feature. Régebben még volt opció a bios-ban, ma már talán még az sincs. Ha nem lenne írható a firmware, akkor nem lehetne frissíteni.
Ami meg egy kapcsolóval állítható, az tulajdonképpen nem védelem.
Szóval továbbra is fenntartom, hogy a kód a hibás és nem a hardver, ugyanúgy, mint egy vírusnál is. Mondhatjuk úgy is, hogy egy vírus sem csinálhatta volna ezt szebben.
De persze egyszerübb mindent a gyártókra fogni...
Ami igazi védelem volt, az a jumper-es megoldás még az öskorban, de ugye ez meg nem felhasználóbarát.
--
robyboy
- A hozzászóláshoz be kell jelentkezni
ha az apple csinálta volna, már lenne erről szavazás, 4000 fika komment, trey 5 imát írt volna már istenhez hogy szűnjön meg a cég.
ha ubuntuék akkor pedig a hardver gyártó a hibás és amúgy is meg van magyarázva hogy ez amúgy miért jó és miért nem baj. :)
szerencsére az itteni ubuntu userek (vér-fanok) nem elvakultak mint az állat. :)
- A hozzászóláshoz be kell jelentkezni
Hali
Az egyébként valóban gáz, hogy nem a hiba jellege, hanem az eredete (gyártója) határozza meg sok esetben hogy ki hogyan ítéli meg a hibát magát.
Én személy szerint nem azt nézem, hogy Apple v Ubuntu, hanem a hibát magát és talán a hozzászólásomból sem süt az elfogultság (pláne, hogy azért mindjárt egy kernelbug-ra utaló idézetet tettem bele), az meg hogy leírtam a véleményem, szerintem még nem szentségtörés.
Személy szerint jobban zavar a HUP-on, hogy egyre inkább mobil platfom ketrecharcos klub, de hát ez van, a világ a mobil irányába megy el. Néhány éve még az számított "ejha" érzésnek, hogy de régen fordítottam kernelt, lassan meg az, hogy de régen használtam nem mobil alkalmazást arra, hogy levelet küldjek vagy olvassak, netem megnézzek valamit.
Összegezve jobb lenne több tény, szakmai tartalom és kevesebb szubjektív felhang, mert az ugye ízlés dolga az pedig: "De gustibus non est disputandum."
... most megyek és meg is írom a Jézuskának, hogy ezt kérem karácsonyra! :)
- A hozzászóláshoz be kell jelentkezni
Igazad van, az Apple-es esetekben is a hardware gyártó a hibás.
- A hozzászóláshoz be kell jelentkezni
touché
"I'd rather be hated for who I am, than loved for who I am not."
- A hozzászóláshoz be kell jelentkezni
:)
- A hozzászóláshoz be kell jelentkezni
Semmi kétség, hogy helyes az érvelésed.
De anno futottam bele olyan bug-ba (ACPI asszem) amikor a BIOS olyan memória területet mutatott az operációs rendszer által módosíthatónak amit nem lett volna szabad és az is hasonló hibajelenségekhez vezetett. (Google -> ACPI BIOS Warning (bug))
Szóval persze, hogy szoftver hiba, de lehet, hogy olyan hiba amihez két dolog kell: egy hibás BIOS és egy hibás oprendszer, melyek ha nem találkoznak az életben nem jön elő a hiba. (Ahogy valószínűleg ebben az esetben is valami hasonló lehetett, mivel nem minden eszközön jött elő a hiba, de azokon ahol előjött ott is csak az Ubuntu ezen változata hozta elő a hibát)
És innentől mehet a mutogatás, hogy ki a hibás, az aki olyan címet ad át szabadként amit nem az vagy az aki nem ellenőrzi valahogy hogy tényleg szabad azon a címen mókolni? (mondjuk, hogy hogyan lehet ilyet ellenőrizni azt spec nem tudom :))
Persze simán lehet, hogy nem ez van, de majd kiderül és akkor nem kell találgatni.
- A hozzászóláshoz be kell jelentkezni
Gondolom arra is van ötleted, hogy hogyan tesztelje le az összes támogatott hardveren a disztribútor az összes változást egyik release-ről a másikra. Sehogy nem tudja nyilvánvalóan, ezért van az alpha, bétateszt időszak.
Tetszik vagy sem, ha a gyártó (Lenovo) hivatalosan nem támogatja az Ubuntu ezen verióját azokon a gépeken, a hw gyártó nem fogja elvégezni ezt a tesztet. Ha nincs teszt, nincs "certified" plecsni. Ha nincs, akkor nincs hol reklamálni. Ezt te, aki ebben az iparban dolgozott, pontosan tudod.
Tetszik vagy nem, itt a felhasználókra marad a bétateszt (nem mintha a fizetős op. rendszerknél ez már nem így lenne).
Ha a megfelelő helyen és időben bejelentik a hibát, "release critical" bug lehetett volna.
Kérdés, hogy ez megtörtént-e. Ha igen és nem történt érdemi reagálás, akkor egyértelmű a felelős.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Nem kell a gyártókra semmit sem fogni, egyértelmű, hogy az ő hibájuk :)
Egyszerűen nem szabadna a hardvernek tönkretehetőnek lenni szoftverből, mert nem csak hibák, hanem szándékosság is létezik. Ráadásul könnyen megoldható lenne hardverből, hogy ilyenkor ne legyen gond. Páran meg is oldják. Szóval nem lehetetlen. Inenntől aki mégsem oldja meg... nos, nehéz őket nem hibáztatni, ha az opció adott.
- A hozzászóláshoz be kell jelentkezni
Jó hogy magamnak írogatok :)
UEFI Firmware Rootkits: Myths and Reality (Revisited for Black Hat Asia)
https://www.blackhat.com/docs/asia-17/materials/asia-17-Matrosov-The-UE…
- A hozzászóláshoz be kell jelentkezni
Elégítsd ki magad nyugodtan.
:)
- A hozzászóláshoz be kell jelentkezni
miután átírta a biost? vagy megint én nem értem mi van?
"all submitted complaints will be forwarded to /dev/null for further investigation"
- A hozzászóláshoz be kell jelentkezni
"miután átírta a biost?"
A magyarázat itt: https://hup.hu/cikkek/20171220/atmenetileg_visszavontak_az_ubuntu_17_10…
- A hozzászóláshoz be kell jelentkezni
Van nálunk egy érintett Lenovo laptop, ahol az első dolgom volt kipróbálni ezt az ötletet: sajnos nem oldja meg a problémát. Annyi változott, hogy a BIOS-ba már be lehet lépni, de a változtatások továbbra se mentődnek el, és az USB-ről bootolás továbbra is teljesen halott ügy.
Kíváncsian várom, mi lesz a vége...
- A hozzászóláshoz be kell jelentkezni
Nyár végén visszatértem a debianra ubunturól, mert untam az upgradek után, hogy sokszor popup hegyeket kaptam olyan hibákról,amik előtte nem léteztek. Természetesen ez ha alkalmanként történik, teljesen elfogadható, de idegesítően vált rendszeresége és szerencsére szeptemberben repült az ubuntu. Lenovom (yoga500) van, bár nincs listán, de nem is szeretném :)
Amúgy mindegy hogy hol jelezték, az azért érdekes, hogy ez senkinek nem szúrt szemet vagy, hogy pontosabban fogalmazzak, senki nem akarta ezt észrevenni.
üdv: pomm
A 852-es kídlap telepötúsa sikeresen befejezádétt
- A hozzászóláshoz be kell jelentkezni
" az azért érdekes, hogy ez senkinek nem szúrt szemet vagy, hogy pontosabban fogalmazzak, senki nem akarta ezt észrevenni."
Észrevették és kezelték is a hibajegyet, miután egy okosabb felhasználó megtalálta a bejelentés megfelelő módját a Launchpad-on.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Valaki, akit érdekelt annyira a téma, hogy elolvasta, mondja már meg, hogy hogyan tud egy (akármilyen) OS telepítés BIOS korrupciót okozni!
Feltételezem nem része a telepítésnek, hogy valami random image-dzsel elkezdi felülírni a BIOS-t.
Eddig akármit telepítettem, az valamilyen háttértárra (pl. hdd, sdd, sd kártya) firkált, a BIOS meg nem törődött ezzel.
- A hozzászóláshoz be kell jelentkezni
Itt van leírva a - feltehetően helyes - következtetés:
https://github.com/torvalds/linux/commit/d9018976cdb6eefc62a7ba79a405f6…
Úgy tűnik, hogy a Lenovo Thinkpad Yoga (és esetleg más gépek) BIOS-a ellenőrzi az SPI-NOR írásvédelmi bit állapotát és ha az írás/olvasás állapotba van billentve, akkor feltételezi, hogy a BIOS beállítások megváltoztak a következő reboot során. Ebben az esetben, valami ismeretlen okból visszaállítja a BIOS beállításokat az alapértelmezett értékekre.
A kernelfejlesztők ezt a bitet valószínűleg alapértelmezetten r/w-re állították (pl. hogy lehessen BIOS-t update-elni az op. rendszer alól). A következő rebootkor bekövetkezett a fenti állapot. Az user hiába állította be a BIOS-t, a rendszer elindulása után a kernel újra bebillentette a flag-et és az egész kezdődött elölről.
Az user pedig annyit észlelt, hogy hiába állítja a BIOS-t be, azt "nem lehet elmenteni". El lehetett feltehetően, csak a következő reboot-kor a BIOS elbaszta újra, lásd eleje.
A megoldás az, hogy a drivert ki kell szedni (mondjuk blacklistre tenni) és utána csinálni reboot-ot kétszer.
Ha a fenti feltételezés helyes, akkor semmi sem firkált a BIOS-ba, egyszerűen csak szar a BIOS.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Na, ez így rögtön hihetőbb :-)
Köszi
- A hozzászóláshoz be kell jelentkezni
Ha tippelnem kellene, akkor valamilyen bug(ok) miatt az UEFI boot beállításakor az Ubuntu installer olyan területre ír ahova nem lenne szabad.
(vagy azért van mert a BIOS olyan címet ad át amit nem lenne szabad írni, vagy azért mert bugos az Ubuntu installere, és az sem kizárt, hogy ez a kettő együtt :))
- A hozzászóláshoz be kell jelentkezni
Erről eszembe jutott a múltkori hasonló systemd-s rm -rf eset:
https://www.phoronix.com/scan.php?page=news_item&px=UEFI-rm-root-direct…
- A hozzászóláshoz be kell jelentkezni
ez is... komolyan mondom ezeknek a problémáknak a közös gyökere az hogy a gyártók nem hajlandók megállni a nyújtózkodással a takarójuk végén.
"all submitted complaints will be forwarded to /dev/null for further investigation"
- A hozzászóláshoz be kell jelentkezni
Ahogy nézem, itt mindenkinek jár a tockos:
- normális vason legalább CRC-t ellenőriznek,
- ha valamit nem írok, akkor nem kérek rá írási jogot. A kernelnek illene abból kiindulnia, hogy akár részlegesen megtörhetik/van benne hiba. Ne legyen annyira könnyű dolga a támadónak/usernek BIOS-t írni. A BIOS-t állítsuk akkor írhatóra, ha ténylegesen írni akarjuk. (Valljuk be egy gép életének elhanyagolható része az, hogy BIOS-t írunk.)
--
https://naszta.hu
- A hozzászóláshoz be kell jelentkezni