-
Mobilarena
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
Frawly
veterán
válasz
samujózsi
#28946
üzenetére
Jó, de a log addig kell, amíg hibát keresel. Utána minek akarod telepítések között hordozni? Ennyi erővel a böngészőcache-t is kinyomtathatnánk és bekeretezve ki lehetne tenni a falra.
Továbbra is tartom, hogy elég a konfigfájlokat menteni, meg a felhasználói adatokat. A többi dolog (tmp, log, ikonok, stb.) annyira az adott telepítéshez kötődik, hogy nincs értelme átvinni egy következő rendszer alá.
Egy dolog még eszembe jutott: el szoktam menteni a telepített csomagok listáját. Az még néha jól jöhet.
-
Frawly
veterán
válasz
samujózsi
#28942
üzenetére
Én csak a /home-ot és /etc-t menteném. Mást nem. Log az mire kéne neked? /usr meg attól függ mi van feltelepítve. Meg ugyebár neked kéne tudni, hogy milyen adatokra van szükséged, milyen mappákat használsz még rajta, mi fájna, ha nem lenne meg.
Én Arch újratelepítések között csak a /home/felhasználóm/ mappát és /etc-t szoktam elmenteni (tömörített tar-ba), azt is csak a konfigfájlok miatt. Minden más lényeges adatot nem a rendszerpartíción, hanem az adatpartíción tárolok, amit nem formázok újra, meg külön mentéseket is archiválok róla.
-
#28941
Frawly
veterán
_ _ _ _ _2 3
#28937
Frawly
veterán
válasz
_ _ _ _ _2 3
#28937
üzenetére
Az egész történetedből nem látom meggyőzőnek, hogy betörtek egyáltalán a gépre. Az, hogy a böngésző kiemel találatokat, az lehet a bekapcsolt előzmények miatt is.
Nem kell ehhez sem Tor, sem 10k-t fizetni senkinek. A Fedora vagy Ubuntu telepítésekor bekapcsolsz egész lemezes titkosítást. Ennek minimum AES-256 XTS-nek kéne lennie alapból. A titkosítás jelszavának, felhasználói és root jelszónak min. 8 karakteres, bonyolult jelszót adsz meg (három különbözőt), nem négy számot, hanem tényleg min. 8 karakter legyen, kis/nagybetű, írásjelek. Pl. ez egy elég erős 27 karakteres jelszó, ilyesmire érdemes rámenni:
esZttordfel...hu3jedyE-rekLényegében: „ezt törd fel hülye gyerek”, csak zanzásítva van mindenféle módszerrel. Az ilyet se szótárazással, se brute force-szal nem töri meg senki vagy még 25 évig, de valószínű 50-ig se. Még akár ékezeteket is bele lehetne vinni (egész lemezes titkosításnál az ékezetes bevitel problémás lehet, ha nem tudod hogy kell beállítani a kiosztást a konzolon). De bármi lehet a jelszó, kedvenc közmondásod, kedvenc vers egy sora, csak ne szótárazható szavakkal legyen leírva, meg ne olyan személyes adat legyen, amit kitalálnak rólad, pl. VezetékKeresztvénSzületésiév, meg ilyen blődségek, hogy 1234, password, jelszó. A titkosítás jelszava legyen a legerősebb, a felhasználói, root jelszó lehet egy kicsit gyengébb, rövidebb, de 8 karakter alá ott sem érdemes adni, meg törekedni kell rá, hogy kis/nagybetű, írásjel, ékezet, stb. kerüljön bele.
Csak a hivatalos tárolókból telepíts programokat. Firefoxnál beállítod, hogy kilépéskor minden felhasználói adatot töröljön, sütik, jelszavak, formok, előzmények, stb..
Jelszó nélküli Wi-Fi-t ne használj. Annál is min. WPA2 az alap, min. 8 karakteres jelszóval.
Aki ilyen óvintézkedések mellett feltöri a gépet, az meg is érdemli. Az online jelenlét külön támadható gép nélkül is, ott is figyelni kell, hogy mit adsz meg magadról. A jelszó minden oldalon erős legyen, felhasználói név ne a saját neved legyen, és különböző (ne minden oldalon ugyanazt használd). Közösségi oldalakon ne posztolj ki magadról mindent, ne adj meg minden adatot publikus profilba.
A leírásodból nem is látom meggyőzőnek, hogy miért érné meg pont téged akárkinek is feltörni, miért lenne érdemes valakinek a munkát beletennie.
Ha annyira ragaszkodsz hozzá, a Tort is felteheted, Fedorán telepíted a torbrowser-launcher csomagot, majd elindítod: torbrowser-launcher
-
Frawly
veterán
/etc/systemd/system.conf fájlban ezt az értéket kikommenteled, és a megfelelő értékre állítod: DefaultTimeoutStopSec=90s
Abban egyetértek, hogy kéne lennie erre egy hotkey-nek, amivel azonnal kilőhető lenne, de nincs. P5steringet nem zavarja, ő kész 5 perceket is várni. Én pont az ilyen baromságok miatt állok majd át systemd-mentes disztróra.
Az még hagyján, hogy várni kell, de még azt se írja ki normálisan, hogy mire. A stop job is running. De melyik folyamaté? F4×ság a köbön, akárhogy nézzük
-
Frawly
veterán
válasz
samujózsi
#28909
üzenetére
De ez írom én is. Lehet más a jelszó, de a diszk tartalma elveszik (hacsak nem volt biztonsági mentés készítve valahol). Cégeknél pont ezt csinálják, amit írtál. Ott a kilépő munkatárs user passworddal használta az SSD-t. Odamegy a rendszergazda, és a master passworddel újratitkosítja a meghajtót, használhatja is a belépő alkalmazott. Semmilyen előzetes jelszót nem kell tudnia.
Elbeszélünk egymás mellett: te ezt jelszócserének tekinted, pedig nem cserélődik le, hanem a helyén egy új titkosítás jön létre. Nem a meglévőn cserélődik a jelszó.
-
Frawly
veterán
válasz
samujózsi
#28905
üzenetére
Most lehet kiderül, hogy ehhez sem értek, de én úgy tudom, hogy az ATA jelszót nem lehet megváltoztatni. Kikapcsolni ki lehet, ha tudod a jelszót, és az adatok megmaradnak (ilyet csináltam is pár hónapja), de a megváltoztatáshoz újra kell jelszavazni az SSD-t, és minden elveszik róla. Ha meg nem tudod a jelszót, mert mondjuk elfelejtetted, akkor az egész drive-nak kuka, nem hogy resetelni nem tudod, de használni sem többé. A gyártó sem tudja resetelni semmiféle elektronikai mókolással, nincs kiskapu hagyva. Ha nincs meg a jelszó, buktad az egészet, vehetsz másikat.
De mondom még egyszer. ilyenben ne is gondolkodjál, hogy te majd jelszót cserélgetsz komoly titkosításokon. Ez nem Facebook account, hogy minden 5 percben jelszót cserélsz. Ezt vagy komolyan veszed, végignyomod évekig komoly, bonyolult, lehetőleg 20+ karakteres jelszóval, vagy komolytalankodás az egész, és bele se kezdj.
@sh4d0w: kösz szépen, a kolléga már küldött linket. Nem tudtam, de most már legalább ezt is tudom. Persze ahogy írtam, én maradok egy jelszónál.
-
Frawly
veterán
válasz
samujózsi
#28903
üzenetére
Értem miről beszélsz. Ez nekem új, hogy több jelszó is lehet és meg lehet őket változtatni.
Hardveres titkosításnál ilyen tuti nincs. Vagyis van ott is user és supervisor password, de azok nem alternatív jelszavak, hanem más-más funkcióra valók, és nem lehet őket megváltoztatni sem.
-
Frawly
veterán
válasz
samujózsi
#28898
üzenetére
Írtam mit értek szoftveresen: LUKS, VeraCrypt/TrueCrypt, BitLocker (bár utóbbi állítólag be tudja kapcsolni a harveres titkosítást is, de BitLockerben nem vagyok otthon).
Tudtommal nem lehet módosítani a LUKS jelszót. Adjál olyan linket, ahol azt írják, hogy lehet, meg hogy több jelszót lehet használni vele.
Abban igazad van, hogy BIOS által kezelt jelszónál nem jó az ékezetes karakter, hiszen még nem lép életbe a nemzeti kiosztás.
-
Frawly
veterán
válasz
samujózsi
#28896
üzenetére
Nem, nem lehet módosítani a jelszót adatvesztés nélkül. Sem a hardveres titkosításnál, sem a szoftveresnél. Így a jelszót jól meg kell választani, hogy biztos hosszú, bonyolult legyen, de számodra könnyen megjegyezhető. Az ilyen 12345, password, meg egyéb amatőr húzásokat el kell rajta felejteni. Min. 8 karakter, számok, kisbetű, nagybetű, egyéb karakterek (írásjelek és/vagy ékezet). Bár egyes BIOS-ok az ATA jelszónak határt szabnak, pl. az én ThinkPad X220-amon úgy van megoldva, hogy a BIOS nem tesz különbséges kis-nagybetű között (nagybetűsként tárolja a jelszót, mindegy hogyan viszed be), és egy csomó speciális karaktert sem enged.
Persze a jelszómegváltoztatás (ami lényegében mindig újratitkosítás) nem valódi adatvesztés. Másolatnak minden fontos adatról kell lennie, meg ilyen jelszómódosítás előtt át tudod menteni az adatokat másik (szintén előre titkosított) drive-ra. Ez egyszerű szervezési kérdés, kényelmi szempont.
-
Frawly
veterán
válasz
samujózsi
#28849
üzenetére
A LUKS, VeraCrypt, BitLocker és társai gyorsabban amortizálják az SSD-t. Illetve a szoftveres titkosításoknak van egy hátránya SSD-n. Át kell engedni rajtuk a TRIM-et, viszont ez meg könnyebben törhetővé teszi a titkosítást, mintázati támadással. Ha viszont nem engeded át rajta a TRIM-et, akkor meg az SSD-nek rosszabb, nem tud működni a garbage collection sem, mivel az SSD vezérlője úgy érzi, hogy tele van az SSD adattal, és nem pakolgathat rajta semmit. Szoftveres titkosításnál ugyanis az egész meghajtó tele van írva random titkosított adattal, azok a részek is, amiken valójában nem tárolsz adatot.
A hardveres titkosítás ennyiből biztonságosabb. Viszont hardveresen titkosított SSD-ről akkor tudsz csak bootolni, ha a gép BIOS-a támogatja az ATA jelszót. Már pedig csak üzleti laptopok, céges kliensgépek, workstationök, serverek szoktak ilyet tudni, konzumer laptopok, asztali alaplapok nem! Egyébként BIOS-támogatás hiányában csak adattárolónak használhatod, és (Linuxon) hdparm-mel tudod feloldani használat előtt, meg először ATA jelszavazni is ezzel tudod.
Viszont a hardveres titkosítás veszélyesebb is. Ha véletlenül rosszul jelszavazod le, vagy elfelejted a jelszót, kizárod magad az SSD-ből örökre, nem lesz róla leoldható a titkosítás, dobhatod ki a kukába. Gariban sem cserélik, és a gyártó sem tudja róla a tiktosítást feloldani. Tehát a hardveres titkosításnál nagyon kell tudni, hogy mit csinálsz. Az ATA jelszó ugyanis nem csak az adataidat védi, hanem az SSD-t is a lopástól. Pont arra az esetre csinálták, ha valaki ellopja a gépet, az ATA jelszavazott meghajtót dobhatja ki, nem lehet újrahasznosítani. Nincs rá semmi átforrasztós, elemkivevős, firmware-frissítős, meg orosz crackes trükk, hogy leoldd róla a titkosítást.
Ha a LUKS jelszót felejted el, az nem baj, le lehet törölni a meghajtót, és csak az adatokat bukod, nem az egész SSD-t.
-
Frawly
veterán
válasz
ubyegon2
#28850
üzenetére
A hardveres titkosítást használó SSD-k mindig titkosítanak, így a 860 EVO is. Ezt le sem lehet tiltani rajtuk. Viszont alapesetben a titkosításhoz használt random generált kulcs az SSD-n el van tárolva (ez nincs külön titkosítva alapesetben), amivel automatikusan feloldja, ezért neked úgy tűnik, hogy nincs letitkosítva.
Viszont ha olyan géped van, aminek a BIOS-a támogatja, vagy hdparm-mal megcsinálod, akkor be tudod rajta kapcsolni az ATA jelszót, ez azt csinálja, hogy újragenerálja a hardveres titkosításhoz használt random kulcsot (ezzel az összes fent lévő adatnak is azonnal bukó lesz, abban a pillanatban), majd ezt a kulcsot is letitkosítja azzal az ATA jelszóval, amit megadsz neki. Így viszont már csak akkor férsz hozzá az SSD-hez, ha ATA jelszóval oldod fel.
A titkosítás nem a géphez, hanem az SSD-hez kötődik, ha be van kapcsolva a jelszó, akkor más gépeken is csak úgy lehet hozzáférni, ha tudod a jelszót.
Ez a felcsatolt fájlrendszered ez egyébként micsoda, amire az fstrim ezt a discard operation is not supported hibaüzit írja? NTFS, FAT32, vagy micsoda? Milyen meghajtón van ez pontosan, milyen SSD, min keresztül kapcsolódik a gépre? SATA, USB?
-
Frawly
veterán
Elvileg támogatottnak kéne lennie, mivel a 4.19 a legutolsó LTS. Az a legtöbb disztrón támogatott, a Debian meg amúgy is konzervatív, meglepne, ha pont ott nem lenne támogatva.
Érdekes, amit írsz, hogy egyikkel megy, a másikkal nem. A 4.19-es kernel sem olyan régi, és időben, verzióban nem esett messze az 5.x-es ágtól. Lényegében az 5.x kernelek 4.21-4.2x-esek, csak a számozás változott meg.
-
Frawly
veterán
Init rendszeren tágabb értelemben nem csak a PID 1-es folyamatot hívják, hanem azt az egész megoldást, amivel a többi folyamat indítható, az induló folyamatok konfigurálhatók, stb..
De nem véletlenül írtam, hogy a systemd-vel az a baj, hogy nagyon rég nem csak egy initrendszer. Egy komplett, bloat mini OS beékelve az kernel és userspace közé. Nem csak az initfeladatokat veszi át, hanem egy csomó hálózati, biztonsági, naplózási, hardverkezelési dolgot is, meg alkalmazások közötti kommunikációs felületet.
Ha tényleg megmarad volna initrendszernek, ami tényleg csak initként működik, semmi mást nem is tud, akkor nem lenne vele nagy baj. De így kezd egyre jobban elfajulni, most fogják behozni, hogy a homed komponens a home mappát, meg egy csomó felhasználói konfigot is fog kezelni, azt is saját kézbe veszi. Így meg egy szép nap azon kapjuk magunkat, hogy az egész Linux megszűnik Linuxnak lenni, és linuxd lesz belőle, amit nem a Torvalds-féle kernel fog hajtani, hanem Pöcstering által foltozott kerneld. Na, ennek kéne elejét venni.
-
Frawly
veterán
A P3-ast extrém példának írtam. Nyilván értelmes ember nem használ ilyen gépet, csak hobbisták, retrózók. Ők viszont szórakozásból meghúzzák, hogy modernebb OS-t tesznek rá. Ilyen körülmények között de, felmerül, hogy mi milyen gépen hogy fut, meg az is, hogy a systemd valójában bloat.
C2D, C2Q, régi genes Core i gépek, laptopok használtan, meg refurbolva elég olcsón mennek. Ezért is nem értem, hogy miért veszi még mindig sok ember ezeket az Atom-os, Celeronos szutyok gépeket, de még olyan ember is betér néha linuxos topikokba, aki Pentium 4-re meg Athlon XP-re keres sovány disztrót. Meglepődünk rajta.
Pont itt a PH-n is az egyik retrós topikban most volt egy csóka, aki kései, 14 éves Pentium M-es gépre tett fel Win10-et. Nyilván nem ezt használja fő gépnek, van vagy másik 100 gépe otthon, közöttük gondolom modernebb is, inkább csak a kihívás meg érdekesség kedvéért kísérletezik ilyennel.
-
Frawly
veterán
válasz
inf3rno
#28728
üzenetére
Offtopik itt a FreeBSD, de ha már felhoztad, egye fene, ejtsünk róla szót. Alapjában véve nem rossz rendszer, nem érték még utol a linuxos baromságok, pl. nuku systemd. Sokkal minimalistább rendszer a linuxnál is. De! Desktopra nem olyan jó, sokkal szűkebb a drivertámogatása, Wine van ugyan rá, de ilyen Proton, DXVK, Wayland és egyéb nyalánkságokat el kell rajta felejteni. Viszont cserébe azon a hardveren, amin nem okoznak gondot a driverek, azon viszont nagyon f4×ányos minimalista, ultrasovány rendszer dobható össze belőle, úgyhogy kipróbálásra mindenképp ajánlott azoknak, akik minimalista rendszert keresnek.
-
Frawly
veterán
válasz
bambano
#28727
üzenetére
Engem desktopon érdekel, hogy mennyire gyorsan bootol a Linux. Megszoktam, hogy a kis lapitopim SSD-vel ultragyorsan bootol, olyan, mint egy táblagép lényegében, bekapcsolom, és szinte azonnal az arcomba vágódik a használatra kész rendszer. Vagyis vágódna, ha nem lenne a systemd egyre bloatabb, és nem szivatna mostanában extrán a random seed miatti bootlelassulással.
Nyilván a szerverek világa más.
A systemd-vel meg mi a baj, azt legékesebben az fejezi ki, hogy egy systemd-s disztró a legminimálisabb telepítésben sem áll meg ~130 MB alatti memófogyasztással, ez systemd nélkül 30 MB körülre küzdhető le. Minimalista rendszereknél, meg nagyon régi gépeknél ez elcseszettül sokat számít!!! Egy modern i5-i7, Ryzen, Xeon, Threadripper, stb. gépen lehet nem számít sokat, de ilyen P3, P4, lóhúgy Celeron, nevetséges Atom, egyéb ultramobil gépeken, embedded rendszereken (néha még gyengébb C2D, i3-as rendszereken) baromi sokat nyom a latba, ég és föld, sebességben is, hogy nem fut a háttérben mindenféle systemd-service sallang!
A systemd-vel az a baj, hogy már rég nem egy initrendszer, hanem egy komplett mini OS az userspace és a kernel közé beépülve. A másik gond vele nem Poettering, mert ő akármilyen fost írhat magának hobbiból, hanem azok az elmebetegek, akik minden disztrót és alkalmazást a systemd-re dependeltetnek, és erről nem Poettering tehet. Ő csak egy szerencsétlen, vézna, idióta, kocka csávó, nem akar apokalipszist, hanem a sok hülye megy ész nélkül utána. Ez olyan, mint a lőfegyver, nem az öl, hanem az emberek mögötte, akik meghúzzák a ravaszt, és egymás ellen használják.
-
Frawly
veterán
válasz
inf3rno
#28702
üzenetére
A Devuan ugyanaz, mint a Debian, csak systemd nélkül. A Void minimalistább, de arra kevés a csomag, az a hátránya. Az MX-et kipróbálhatod, nem tudom mennyire minimalista a legkisebb .iso-juk, de az nem számít minimalista disztrónak, már régen sem, inkább gyenge gépes volt, mint minimalista.
-
Frawly
veterán
válasz
inf3rno
#28699
üzenetére
A legminimalistább, desktopnak is jó disztró a Gentoo. Minimalista az Alpine is, de nem desktopra való, a Linux from Scratch meg nem disztró, hanem csak egy dokumentáció.
Kicsit „könnyebb” telepítésű az Arch, ArcoLinux, Debian minimal netinstall, Ubuntu minimal netinstall, ezek akkor, ha nem zavar a systemd (vagy kifejezetten kell systemd, mert olyan fullosabb DE-t használsz rajta, aminek kell, pl. Gnome3).
Ha systemd-mentes, de még mindig minimalista, de azért könnyebben emészthető rendszer kell, akkor Devuan netinstall vagy Void.
Az Arch, Arco vonalnak előnye a sok AUR-os csomag és a rolling frissesség. A Debian, Ubuntu, Devuan vonalnak előnye a sok csomag, sok extra tároló, hosszabb támogatási ciklus.
-
Frawly
veterán
válasz
haddent
#28694
üzenetére
Igen, írtam is a legelső vonatkozó hozzászólásomban, hogy ezt próbáltam először. Látszólag le is tiltja, nem ír semmi hibaüzenetet, de aztán reboot után pofátlanul továbbra is ott virít ez a futó random seed service, és dicsekszik, hogy 9 mp-cel hosszabbította meg a bootot. Valahogy mindig visszamászik, hiába tiltom le
-
Frawly
veterán
válasz
samujózsi
#28692
üzenetére
Kösz a választ. Bootoláshoz betettem a random.trust_cpu=on kernelparamétert, de nem segített. Az első link szerint nem is csoda, mert ehhez a procinak kell támogatnia az RDRAND utasítást, az enyém (2. genes mobil Core i) nem támogatja.
Egyébként a gondot, ahogy nézem, nem is a kernel jelenti, hanem a systemd-random-seed.service. Ezt kéne kikapcsolnom valahogy.
-
Frawly
veterán
válasz
sh4d0w
#28690
üzenetére
Kösz a linket, azt tudom, hogy ez micsoda, mire való. Nagyon elszomorítana, ha nem tudnék tőle megszabadulni. Nem igaz, hogy valami kernelparaméter nincs erre, hogy az egész random-seed-es baromságot abbahagyná, és végre lehet lehetne tiltani a system service-t is.
Lassan már érik nekem egy nem systemd-s disztróra váltás, vagy Void, vagy Gentoo. A Devuan nekem nem elég friss. A választék meg korlátozott, elég kevés systemd-s disztró maradt. Így végül lehet nem is a binárisok optimalizálása miatt váltok Gentoo-ra.
-
Frawly
veterán
Na, most lett elegem ebből a linuxos random seed baromságból. Egyre jobban belassítja a bootot Archon, hosszú extra másodperceket jelent bootidőben.
Valamelyik itteni ubuntus topik hatására használtam egy ideig a haveged csomagot, ami ezt hivatott orvosolni, azzal gyorsabb is lett, de a régi bootidőt az sem hozta vissza teljesen. De egy idő után az újabb kernelekkel belassult (1 perc fölé majdnem) az is, úgyhogy eltávolítottam, nem volt más választásom.
Most viszont anélkül is egyre hosszabb a bootidő, systemd-analyze blame a system-random-seed.service-re hivatkozik, 8-10 mp. között van
Próbáltam ezt systemctl disable módszerrel letiltani, de hasztalan, minden bootkor elindul csakazért is.Hogy lehetne az egész Linuxból, kernelből, systemd-ből gyökeresen kitiltani ezt a random-seed baromságot, egyszer és mindörökre??? Nem az NSA-nak titkosítok államtitkokat, adataimat vagy külső hardveres titkosítással védem (SSD ATA jelszó), vagy egy másik gépen már legenerált kulccsal és hash-el ellátott LUKS titkosítással. Nem kell ez a random seed baromság egyáltalán, örökre meg akarok szabadulni tőle. Erre valakinek ötlete?
-
Frawly
veterán
válasz
samujózsi
#28639
üzenetére
Nem dob fel semmit. Ha csak simán indítasz grafikus felületről (indítómenü, asztal, fájlkezelő) egy progit, akkor a normál usered nevében fut, és nethez fér a progi.
Ha viszont terminálban sudo -g eléggépelésével, vagy ezt végrehajtó, módosított indítóikonról indítod, ami szándékosan ebben a no-internet csoport nevében futtat, akkor sem kérdez semmit, nem fér az alkalmazás nethez. Külön kérdezés ilyenkor sem kell, mert azért indítod akkor az alkalmazás ilyen speciális módon (speciális paranccsal, vagy speciálisan erre a célra elkészített ikonnal), mert nem akarod, hogy nethez férjen.
-
Frawly
veterán
válasz
samujózsi
#28635
üzenetére
Nem kérdés nélkül tilt. Csak abban az alkalmazás esetében tilt, amit kifejezetten ezzel a spéci csoporttal indítasz (alapesetben mindent a normál felhasználóddal indítasz ugyebár). Viszont ez a megoldás hekkelést és terminálozást igényel, szóval nem olyan kényelmes, mint Windowson. De arra jó, hogy nem kell hozzá egy újabb programot feltenni, és ha csak 1-2 szoftvernek a netelérését akarod tiltani, arra megfelelő hack.
Az Ubuntu Universe és Multiverse repók és elterjedtebb PPA-k, teljesen megbízhatók. Olyan csomagok vannak bennük, ami az alap Ubuntu tárolókban vagy nincs meg, vagy túl régi verziókban, vagy csak 64 bitesen. Tehát semmi baj nincs velük, meg lehet bennük bízni. Ugyanabból az opensource kódból forgatják őket, mint a többi ubuntus csomagot.
Vigyázni csak a teljesen ismeretlen, múlttal nem rendelkező PPA-kkal kell, meg az innen-onnan weboldalakról halászott .deb csomagokkal és franc tudja mit csináló scriptekkel kell. -
Frawly
veterán
Grafikus tűzfalban továbbra sincs ilyen funkció. A Stack Exchangen találtam rá megoldást.
Létrehozol egy no-internet nevű felhasználói csoportot:
sudo addgroup no-internetAztán iptables-ben (vagy gufw-ben) tiltod ennek a hozzáférését
sudo iptables -A OUTPUT -m owner --gid-owner no-internet -j DROPMajd az alkalmazást az no-internet csoport nevében indítod:
sudo -g no-internet alkalmazásKicsit körülményes, de nem tudok más járható utat.
-
Frawly
veterán
Igen. És azt a hibát is elkövetem, hogy ha valaki egy linuxos topikban kérdez, és nem ír kifejezetten spéci körülményt, akkor alapból feltételezem, hogy otthonról netezik és aktuális desktop disztróról van szó, és ez a feltételezés az esetek 99%-ban be is szokott jönni. Gondolatolvasó nem vagyok, ha szerverről meg céges felhasználásról van szó, akkor szépen írják a kérdezők ezt a körülményt.
-
Frawly
veterán
Első kérdés: biztosan kell neked tűzfal Linuxra? Mert dekstop Linuxra nem szokott kelleni. Kiváltképp, ha eleve routerről csatlakozik a géped, és a routeren van NAT vagy hardveres tűzfal. Második kérdésedet megelőzve: nem, vírusirtó sem kell Linuxra. A Linux nem Windows. Értem, hogy megszoktad, hogy Windowson ezek kellenek, Linuxon nem.
Egyébként Linuxra olyan tűzfal nincs, ami alkalmazásonként kérdezne. Csak olyanok vannak, amiknél te adhatsz meg IP szabályokat, pl. gufw. Ezek a tűzfalak a kernelben lévő tűzfalat használják (ami desktop disztrón 0 szabállyal jön, nincs bekonfigurálva), abba vesznek fel szabályt, és csak grafikus felületet nyújtanak hozzá felhasználóbarátság miatt. Tehát ők maguk nem tűzfalak, csak ilyen beállítófelületek a kernelhez.
-
#28613
Frawly
veterán
MasterMark
#28611
Frawly
veterán
válasz
MasterMark
#28611
üzenetére
Fájlrendszertől függ, hogy rm után nyerhető-e vissza valami, milyen tool van hozzá. De szerencsétől is függ, hogy nem írodott-e felül a törölt rész új adattal.
Ha visszaállítható törlést akarsz, használj valami lomtárat kezelő megoldást, valamelyik fájlkezelőt, mindegy, hogy GUI-s vagy terminálos, vagy konzolos, mindegyikben van hasonló funkció.
Az IPv6-ra passz, ezt a prefix delegationt meg Unraid-et nem ismerem. Kézikönyvét próbáltad?
-
Frawly
veterán
válasz
CPT.Pirk
#28545
üzenetére
Sőt, még a PowerVR-os szutykokon is megy az i915 driver, csak úgy megjegyzem, hajtja a GPU-t 2D-ben, némi energiagazdálkodás is működik, csak 2D-s és 3D-s hardveres gyorsítás és hardveres dekódolás nincs. Tehát képet még akkor is kéne adjon, meg akkor is bootolnia kéne, ha a driver nincs egészen rendben.
-
Frawly
veterán
válasz
CPT.Pirk
#28543
üzenetére
Igen, rosszat írtál. Én végig arról az Atom Z-ről beszéltem, amit említettél, azokban meg az Atom N-ek jó részében PowerVR GPU van. Ebben az X5-ben valóban HD 500, annak viszont rendesen kéne mennie, a normál i915 KMS kernel driverrel, semmilyen firmware meg X.org driver nem kell neki, csak egy mesa csomag az OpenGL-hez, meg esetleg vulkan-intel, ha Vulkant akarsz.
-
#28539
Frawly
veterán
Plasticbomb
#28537
Frawly
veterán
válasz
Plasticbomb
#28537
üzenetére
Atomja válogatja. Azok az atomok, amiket kapitány írt, azokban PowerVR van. Az újabb atomokban viszont valóban lehet Intel IGP, ezek jobbak is linuxozni, meg procierőben is jobban állnak.
-
Frawly
veterán
válasz
CPT.Pirk
#28534
üzenetére
Ezek az Atomok sajnos ilyen szutykok mind, főleg a régebbiek. Nem Intel GPU van beléjük integrálva, hanem valami PowerVR-os csoda, ami inkább integrált grafikus lassító, mint gyorsító, és általában nincs hozzájuk linuxos driver. Ezt a PowerVR-t egy külsős cég csinálja, egyszer nyújt hozzá drivert az aktuális Windowshoz és annyi, többé nem támogatják, de windowsos, se linuxos driver nem fog kijönni hozzá. Használjátok Win10-zel.
-
#28530
Frawly
veterán
Plasticbomb
#28519
Frawly
veterán
válasz
Plasticbomb
#28519
üzenetére
Igen, biztos vagyok benne. Ezek szerint az fstrim NVMe-n is támogatja a megfelelő részműveletet. Szerintem törli az üres szektorokat és azok egyben meg is trimelődnek.
Ha nem hiszed, olvass utána a TRIM parancs egy ATA/SATA utasítás, az NVMe protokollban nem létezik, viszont ott van helyette más, ami meg be van építve más általánosabb lemezműveletes parancsok közé, úgy, hogy nem kell külön progival hívogatni.
SCSI/SAS és USB-UASP SSD-ken sem létezik TRIM, ott az UNMAP SCSI parancs van helyette, ezt viszont kevés progi támogatja, SCSI/USB vezérlőtől is függ.
-
Frawly
veterán
válasz
ubyegon2
#28514
üzenetére
Végül is lefuttathatja ezeket, az fstrim vissza fogja írni, hogy a TRIM nem támogatott. Tehát bajt nem csinál vele, csak nem fog lefutni. NVMe-n nem kell TRIM-elni, ahogy már kifejtettem.
Egyébként meg fstrim kiadásokor jobb a sudo fstrim -v -a formát használni. A -a kapcsoló (vagy hosszú formában --all) az összes felcsatolt, TRIM képes partíciót végigtrimezi. SATA meghajtók esetén.
-
Frawly
veterán
válasz
kelna91
#28494
üzenetére
Az SD kártyák, meg az MMC Flash tárolók nem végeznek garbage collectiont, sem wear levelinget, így nem igényelnek TRIM-et sem.
NVMe SSD-knél meg az NVMe protokollba alapból úgy van beépítve a TRIM-nek megfelelő részművelet, ami minden vonatkozó lemezutasításkor meghívódik automatikusan (ki sem lehet hagyni), erről nem kell külön az OS-nek, drivernek segédprogramoknak gondoskodni. SATA-nál kell, mert ott eredetileg nem volt benne az ATA/SATA/AHCI protokollban (ami HDD-khez készült eredetileg), hanem utólag került bele az SSD-k miatt. De az NVMe eleve SSD-khez készült.
Ez egyébként előnye az NVMe-knek, mert SATA-s SSD-knél problémás lehet a TRIM, ha az OS vagy adott fájlrendszer nem támogatja. NVMe-knél ez nem érdekes.
-
Frawly
veterán
válasz
kelna91
#28488
üzenetére
Szerintem nem működik. De nem a sugárkövetés a probléma benne, mert az elvileg épp úgy tudna működni, ha az API és a GPU is támogatja, hanem ezek a raytracinges játékok tudtommal egyelőre csak Windowsra vannak, Linux alatt max. a DXVK Proton viszi őket, de azt nem tudom, hogy az hogyan szól bele a raytracing részébe.
De ha a fejlesztők nem lusták, és mondjuk legalább a Raytracing Quake II-őt átportolnál natívan Linuxra, akkor máris lenne egy játék, ami alatt menne. Mert amúgy technikai akadálya nincs Linux alatt sem.
-
-
Frawly
veterán
válasz
Frawly
#28449
üzenetére
Bár így visszaolvasva magam, asztali gépen a CentOS 6 lehet nem jó ötlet. Szerintem már a böngészők is olyan régiek benne, hogy egy csomó weboldalt nem jól jelenítenek meg.
@vargalex: Az AUR-ból letöltött hdsentinel is a hdsentinel weboldaláról letöltött bináris. Az AUR script csak automatizálja a beszerzési folyamatot, letölti a weboldalról, pacman csomagot gyúr belőle, amit telepít. Azzal egyetértek, hogy inkább a „minek” kérdéses itt.
-
Frawly
veterán
válasz
Doky586
#28450
üzenetére
Nyugi, a Linux Mint is dobni fogja a 20-as kiadásban. Nem a Mint döntése, hanem az Ubuntu szünteti meg, és mivel azonos tárolókat használnak, lévén a Mint az Ubuntura épül, így Minten sem lesz elérhető.
Fel tudsz tenni egyébként Arch32-őt rá. Vagy ha van rá idegrendszered, akkor Gentoot is bármikor fel tudsz tenni 32 bitre.
-
Frawly
veterán
válasz
Doky586
#28446
üzenetére
Ezek nem fognak soha eltűnni. A lemezképeket nem törlik, legfeljebb a támogatásuk szűnik meg, a tárolók tűnnek el, ahonnan ezek a lemezképek csomagokat telepítenének.
Egyébként ha marha régi Linux kell, systemd nélkül, akkor CentOS 6. Ebben minden marha régi, de még támogatott, 32 bitet is támogat, Pentium 4-nek, Pentium D-nek nem lesz sok, ha IceWM vagy Openbox ablakkezelővel teszed fel. Böngészőnek Firefox, de még inkább Pale Moon vagy Falkon.
-
Frawly
veterán
válasz
ubyegon2
#28442
üzenetére
Ezek a lemezinformációs és lemezbenchmarkos progik pont az a kategória egyébként, ahol egy GUI-s HDS-nek lenne keresni valója, mert eléggé hiány van ezekből Linuxon, csak néhány CLI-s megoldás van. De valahogy HDS-éknek egyáltalán nem prioritás a Linux, a linuxos bináris csak ilyen kísérleti, ezer éves valami, amit nem nagyon fejlesztenek.
Én már a MS-féle DiskSpd-del is próbálkoztam, mert az az alapja a windowsos Crystal Disk Mark-nak, de nem tudtam úgy felparaméterezni, hogy ugyanazokat a kategóriákat mérje.
A Gnome Disks vicc kategória. Hulladék.
-
Frawly
veterán
válasz
ubyegon2
#28440
üzenetére
Így van, pont itt van a kutya elásva, hogy csak a kezdők nyúlnak HDS-ért Linuxon. Haladók eleve a tárolókból használnak smartctl-t a smartmontools csomagból.
Linuxon a HDS-t egyébként sem ajánlom, nem felhasználóbarát (épp úgy terminálos, ahogy a smartctl), nagyon foghíjasan fejlesztik, ritkán van új verzió, az is el van maradva a windowsos változattól. Nem éri meg használni. Kipróbálni ki lehet, ha valaki nagyon kíváncsi rá, de nem egy nagy szám a linuxos HDS.
-
Frawly
veterán
válasz
Doky586
#28436
üzenetére
De miért akarod Windows alatt nézegetni? Gondolom valamihez kell Linux alatt, ott nézegesd a file parancsot a fájl elé írva. Ha meg nem kell Linux, akkor meg mindegy, hogy 32 vagy 64 bites.
Plusz Linuxon nem bűvölünk ilyen isten tudja honnan szerzett, ismeretlen verziójú és architektúrájú .so libeket. A csomagkezelővel telepítünk mindent, az majd feltesz minden szükséges függőséget, megfelelő verzióval, megfelelő architektúrához, megbízható helyről. Ez nem Windows, hogy a net sötét bugyraiból előkotort .dll fájlokkal kelljen vitézkedni, meg porn-dialer.exe-ket letöltögetni franc tudja milyen oldalakról.
Az a baj, hogy sok kezdő linuxos nem tud elszakadni Linuxon sem a windowsos logikától, weboldalakról szedett dolgokat telepít, ragaszkodik a tűzfalhoz, vírusirtóhoz, windowsos programohoz Wine alatt, stb.. A Linuxnak úgy van értelme, ha Linuxként használod, ha Windowsként akarsz valamit használni, arra ott a Windows.
-
Frawly
veterán
válasz
ubyegon2
#28423
üzenetére
Tévedés, amit a GRUB-ban odaadsz paramétereket, azt nem a GRUB-nak adod, hanem a kernelnek. Syslinuxszal, lilo-val, meg EUFI boottal is át tudod adni ugyanezeket a paramétereket.
De ettől függetlenül tényleg lehet, hogy a sysctl csak azokat a paramétereket listázza, amelyeknek az értékét menet közben is meg lehet változtatni, mikor már a rendszer fut, míg azokat nem listázza, amiket csak bootkor lehet átadni.
-
Frawly
veterán
Három hsz.-szel előtted már írtam, hogy megjelent. De ismétlés a tudás öregapja vagy mi
Lenne egy újabb kérdésem: az 5.2-es kerneltől kezdve bevezették a mitigations kernelparamétert (lehet off-re, auto-ra, nosmt-re állítani). A sysctl -a parancsnak elvileg ki kéne listázzon minden paramétert, amit a kernelnek lehet adni induláskor, de mitigations paramétert nem listázza, semmilyen formában. Mi lehet ennek az oka?
-
Frawly
veterán
Folytatva a topik floodolását, nekem is lenne egy kérdésem. Archon indítanám az AUR-ból felrakott Velox WM-et (waylandes). Azt írja, hogy FATAL: Could not open display, és nem indul.
Próbáltam az export DISPLAY=0 és DISPLAY=localhost:0.0 stb. értékkel játszani, úgy sem talál képernyőt. Hogy lehetne működésre bírni?
Próbáltam az AUR-ból a sima velox csomag helyett a velox-git-et feltenni, de az meg le sem fordul, a forráskódban jelez implicit függvényhívási hibát.
-
#28418
Frawly
veterán
magmakocka
#28416
Frawly
veterán
válasz
magmakocka
#28416
üzenetére
Ezt most nem értem, mit futtatva van ott, milyen modeset?
Egyébként ha megy az Xfce, akkor nem kell Xorg configure. A Kodi-nak valószínű jogosultságbaja van, alapból a kodi nevű felhasználót használja, ami a kodi csoportban van, ennek kéne megfelelő jogokat adni, Alpine-on nem tudom hogyan megy.
-
Frawly
veterán
válasz
Dißnäëß
#28399
üzenetére
Úgy engedték, hogy tudták, hogy this nice kolléga nem fogja úgyse feltenni a 9-est, mert 2019. július 6-án megjelent a végleges Debian 10. Igaz azzal vigyázni kell, mert még nem 10 évesek benne a csomagok, majd csak 20 év múlva jelenthet ki róla, hogy stabi, és ha használod, akkor nem támad hátba egy t-rex sem.
Itt a Debian Wiki-ben le van írva a lényeg:
apt-get install firmware-linux-nonfree libgl1-mesa-dri xserver-xorg-video-atiBár megjegyzem, hogy az xserver-xorg-video-ati nem feltétlenül kell, attól függ, hogy milyen felületet használsz, X.org vagy Wayland alapút, és hogy a kompozitor használ-e 3D-gyorsítást. Az xserver-xorg-video-ati ahhoz kell, hogy klasszik X.org WM-ek, amelyek nem használnak kompozitort, tudják használni a GPU nyújtotta 2D-s gyorsítást.
-
Frawly
veterán
válasz
Dißnäëß
#28377
üzenetére
Ez ugyanúgy működik SSD-n is, ahogy HDD-n. SSD-n csak egy extra dolog van, ha van LVM, akkor azon keresztül kell engedni a TRIM-et, és ha van LUKS, akkor azon is. Ennek a mikéntjét az Arch Wiki leírja.
Kivitelezhető, amit írsz, de én ilyen kamu rendszert nem csinálnék rá, aki ért hozzá, az úgy is tudja, ha randomnak látszó adattal van tele a meghajtó nagy része, az titkosítás. Aki meg nem ért hozzá, annak meg felesleges kamurendszert csinálni rá.
De ha SSD-ről van szó, és az SSD és a gép is támogatja, akkor az SSD saját hardveres titkosítása is használható, igaz ez nem olyan megbízható, mint a LUKS, de az esetek nagy részében ez is elég lehet, és nem kell LUKS-szal meg USB-vel szívni.
-
Frawly
veterán
válasz
kezdosql
#28339
üzenetére
Ez így nagyon kevés és ködös infó, lehet sok minden, hardveres vagy szoftveres hiba. Nem tudjuk milyen gép, milyen disztró, hányas verzió, hogyan kapcsolódik a netre. Internetes lámpát még az életben nem láttam, gondolom az Ethernet-kártya vagy a Wi-Fi kártya LED-jére gondolnak.
-
Frawly
veterán
válasz
kezdosql
#28335
üzenetére
A Firefox Súgó menüjében válaszd az újraindítást letiltott addonokkal. Vagy about:support lapon a Refresh gomb.
A FF indítása előtt indítsd egy feladatkezelőfélét, htop vagy Gnome System Monitor vagy akármit, és nézd meg a Firefox indítását, hogy mi látszik a fagyás előtt.
-
Frawly
veterán
válasz
azbest
#28254
üzenetére
Igen ám, de akkor Win10 alatt miért jó? Ott több száz fps-sel szakÍtanak a külső kártyán a régebbi játékok, egyelőre még csak azokkal próbáltam. Ott nincs lag az asztalon sem, pedig 1080p a felbontás.
Pont ezt akarom, hogy az eGPU (RX570) legyen az elsődleges. Nekem nem kell, hogy képet mutasson a laptop belső kijelzőjén, az nem is lehetséges, mert AMD kártyám van, ami ezt nem támogatja, azért is kötöttem rá HDMI-n külső monitort. Meg a külső kijelző teljesítményszempontból sem rossz, mivel akkor a szűkös PCIe x1 sávon nem kell a képet visszaküldeni.
-
Frawly
veterán
válasz
Frawly
#28246
üzenetére
Erre senki? A külső kijelző működik, amit az eGPU-ra kötöttem, de az eGPU nem, nagyon lagol, szerintem az integrált GPU erőlködik, de nehezen tudja kipréselni magából az 1080p-s felbontást.
Win10 alatt hekkelés nélkül működik a cucc, a külső kijelzőn automatikusan az eGPU-t használja.
-
Frawly
veterán
Nálam sima Archon sehogy sem ad debug kimenetet, hiába futtatom a dmesg -l debug vagy dmesg --level debug parancsokat. Sanszos, hogy kapitánynak van igaza, és külön így kell fordítani hozzá a kernelt.
De az is lehet, hogy az általad írt dynamic debug-ot nem kapcsoltam be, ezt hol lehet megtenni?
-
Frawly
veterán
Rákötöttem az X220-as laptopomra egy RX570-es kártyát eGPU-ként. Az lspci kimenetben látszik is.
Mit kell ahhoz csinálni, hogy a kártyát használni tudjam? Jelenleg a prociba integrált Intel HD3000-es GPU-t használja a rendszer. Hogyan tudnám rávenni, hogy a másik GPU-t használja?
Azt tudom, hogy állítólag kell hozzá külső monitor, meg is van rendelve, de még nem ért ide. Csak NV kártyához nem kötelező külső képernyő, de olyat nem akartam venni a fostos drivertámogatás miatt. Kifejezetten ezért lett AMD kártya véve.
Tippre bootkor kéne valami kernelparaméter, ami a külső GPU-t inicializálja.
-
Frawly
veterán
válasz
ubyegon2
#28198
üzenetére
Majd Minten is el fog csesződni, hidd el. OS független teljesen, Mac-en, Windowson, Androidon is előjön a visszajelzések szerint, és csodálkoznék, ha a BSD-k kivételek lennének.
iOS-en nincs gond, mert arra nem érhető el a Firefox, vagyis ott csak az Apple böngészője fölé húzott bőr, mivel Almáék ellehetetlenítették az összes böngészőkonkurenciát, csak a sajátjukat engedélyezik.
Vannak az ügyben fejlemények, de ezt a Firefox topikban tárgyaljuk ki, ott fut a téma fő szála.
-
Frawly
veterán
válasz
sh4d0w
#28193
üzenetére
Ja, mindenkit érint. Tele van vele minden híroldal, fórum, windowsos, linuxos, mac-es userek is panaszkodnak, érint minden verziót ESR, stable, Developer Edition.
Nagyon gáz, hogy a Mozilla távolról működésképtelenné teheti a böngészőt, egy gombnyomással vagy tanúsítvánnyal. Nem tudok másikra váltani, a Google is ugyanezt csinálja a Chrome-mal, és a többi böngésző is Chrome alapú.
Még a Firefox profilom is kinulláztam, egy csomó beállítás elveszett. Azt hittem eleinte, hogy csak nálam tört el valami. Több mint fél órát fetrengtem rajta, mire rájöttem, hogy tömeges probléma.
-
Frawly
veterán
válasz
Frawly
#28189
üzenetére
A vicc az, hogy nem csak az összes addont, de az összes témát is letiltotta. Kinulláztam a profilt, és próbáltam az addonokat és témákat újra letölteni és hozzáadni, de azt írja, hogy a Download failed. Please check your connection. A kapcsolattal természetesen semmi probléma nincs, minden oldal bejön.
Feltettem a tárolóban a 66-os stabil Firefoxot. Ez is ugyanazt csinálja. Wtf.
-
Frawly
veterán
Ma letiltotta a Firefox béta az összes addonom. Eddig is 67-es verzió volt, de frissült. Kitalálta, hogy az összes téma és addon nem kompatibilis hirtelen. A privát móddal hozza összefüggésben, de nem használok privát böngészést. Más is belefutott ebbe?
Mielőtt ubyegon éljenezne, hogy megint a rolling miatt törik el valami, csak úgy írom, hogy portable Firefoxról van szó, amit a Mozilla oldaláról letöltött tar.gz-ből bontottam ki, és egy mappába kibontva fut, évek óta így használom, először van vele baj. Tehát nem az Arch valamelyik tárolójában lévő verzió hibás.
-
Frawly
veterán
válasz
Dißnäëß
#28186
üzenetére
Mindenképp azt mondom, hogy próbáld ki. Nézd meg mennyivel lett gyorsabb a RAID tömb, mint a szimpla lemezek önmagukban. Onnan fogod látni, hogy ezért a plusz sebességért megéri-e neked RAID-ezni egyáltalán. Ez így elvi síkon eldönthetetlen, hogy melyik lemezed hogy fog tetszeni a szoftveres RAID-nek.
-
Frawly
veterán
válasz
bambano
#28183
üzenetére
Az összes linuxos particionáló tool default 1024K-s eltolással particionál, ami jó 4K-s és 0,5K-s meghajtóknak is. Viszont RAID-nél nem tudom az eltérő szektorméret mennyire lassít. Fájlrendszer oldaláról megint rendben van, mert a deafult clusterméret 4K vagy ennek többszöröse.
-
Frawly
veterán
válasz
totron
#28179
üzenetére
Ez milyen disztró? Azt is vedd figyelembe, hogy sok disztrón a grafikus felület kiosztása és a terminálban, konzolban használt kiosztás teljesen külön van kezelve. Pl. az Arch alapú disztrók ilyenek. Így telepítéskor hiába adtál meg grafius felületen Hu-billentyűzetet, attól még terminálban más lehet a történet.
Sőt, néha a grafikus Login Managerben is külön kell állítani a kiosztást.
-
Frawly
veterán
válasz
Fecogame
#28170
üzenetére
Szerintem ez valami speciális CentOS specifikus konfig. Nézz meg akármelyik distrowatch top20-as disztrót, 0 tűzfalszabállyal jön, mindent ki/bementő forgalmat fogad (ACCEPT).
(#28169) Mr Dini: az attól függ, hogy hogyan definiáljuk az értelmeset. Elismerem annyiból félrebeszélhettünk egymás ellen, hogy nem világos szerverről vagy desktopról van szó. Szerveren lehet értelme, de pl. desktopon általában nem használnak az emberek. Ha itt most a PH-n csinálnánk egy szavazást, elsöprő többséggel nyerne az a kategória, aki nem használ tűzfalat a Linuxán. De a HUP-on is hasonló eredmény jönne ki.
-
Frawly
veterán
válasz
Victoryus
#28167
üzenetére
Linuxon nem nagyon használnak az emberek tűzfalat, azért nem említik a leírások. Vagyis alapból elérhető tűzfal, de csak ilyen kerneles, és alapból 0 szabályt tartalmaz, ki/beenged mindent. Ahhoz, hogy valamit szűrjön, szabályt kell felvenni. Nyilván, ha te felvettél szabályt bele, akkor a te felelősséged, hogy a neked fontos progikat átengedd rajta.
-
Frawly
veterán
válasz
Mr Dini
#28160
üzenetére
De a DHCP által osztott cím az most belső hálózati cím, vagy külső cím? Ne feledd, hogy egy eszköznek lehet címe befelé meg kifelé is. Nyilván az internetről a külső címen látni a szervert, de a külső címet nem biztos, hogy DHCP ossza neki.
Ezért mondtam, hogy rajzold le, lássuk mi minek oszt címet, mi van belső és külső hálón.
-
Frawly
veterán
válasz
Mr Dini
#28157
üzenetére
Ez az egész zavaros, amit írsz. Van is DHCP de nincs is, meg „külső” IP, de idézőjelben. Próbáld lerajzolni rendesen a hálózati infrastruktúrát, jelezve az IP-ket, hálózati maszkokat, minek micsoda ossza a címet.
Egy biztos: virtuális gépnek semmit nem KELL kézzel megadni IP-nek. Lehetni lehet, de nem KÖTELEZŐ. Elvileg simán bridge-elt hálózatnál automatán is kaphat megfelelő címet.
-
-
Frawly
veterán
válasz
ubyegon2
#28131
üzenetére
Ja, a helyezése most is jó az Elementary-nak a DW-n, de a valóságban oldalakon, fórumokon, tényleges használati statisztikákon nem látom, hogy túl sokan használnák. Majd olvasd vissza pl. hogy itt a PH-n, vagy a HUP-on mikor volt utoljára elementary-s kérdés. Évek óta nincs. Kb. ennyi is a használói tábora a többi kimutatás szerint is.
De abban egyetértünk, hogy a többi disztrót is be lehet konfigolni elementary-s kinézetűre. Innentől egyébként sincs sok értelme, egyel kevesebb fork. Ezzel persze nem azt akarom mondani, hogy rosszabb, mint akármelyik más disztró, még mielőtt valaki megint megsértődne, inkább csak megállapítás, hogy nem népszerű, és nincs is nagyon mire fel annak lennie.
Valahogy úgy érzem, hogy a Pop is erre a sorsra jut, de azért rákérdeztem, hátha használja valaki, aki tud róla néhány mondatos tapasztalatot mondani. Megspórolva nekem, hogy leszedjem, kipróbáljam, időm pazaroljam rá. Úgy, ahogy kapitány is mindig jelent, hogy mi a helyzet a Chackrával.
-
#28130
Frawly
veterán
Plasticbomb
#28128
Frawly
veterán
válasz
Plasticbomb
#28128
üzenetére
Mélységében nem értek az RGB-hez. Az UEFI-ben nem tudod beállítani, hogy konstansan ugyanazon a színen világítson bekapcsolástól fogva? Azt értem, hogy nem az UEFI vezérli, de csak van valami beállítás, ami a boot előtti defaultot megváltoztatja, és onnan Linux alatt meg nem módosítaná semmi. Akár úgy, hogy valami windowsos progival beállítod állandóra, hogy narancs színnel induljon Windows nélkül is.
-
Frawly
veterán
válasz
ubyegon2
#28124
üzenetére
Ja, hogy erről már volt szó. Nem emlékeztem rá. A szutyok így visszaolvasva kicsit tényleg erős volt, csak abból szűrtem le a következtetést, hogy nem tudott bootolni. De ettől függetlenül komolyan érdekel, hogy aki esetleg használta már, mi a benyomása róla. Felrakni csak ezért nem akarom, tényleg csak azért kérdeztem rá, mert egyre nagyobb hájpja van a neten, bár a distrowatchon még csak 43., nem mintha sokat jelentene.
Bár ez ilyen, divat jön-megy. Pár éve az Elementary is nagyon népszerű volt, aztán gyorsan alábbhagyott az érdeklődés iránta.
Amit screenshotokon láttam, ez a Pop kifejezetten rondának tűnik, egy elég default Gnome3 kinézete van. De egy véleménynek elfogadom, hogy te próbáltad, és neked tetszett a témája. Lehet azóta reszeltek rajta, vagy csak ennyire nem vagyunk egyformák ízlés terén sem.
-
#28122
Frawly
veterán
Plasticbomb
#28112
Frawly
veterán
válasz
Plasticbomb
#28112
üzenetére
Nem szántam mérgesnek. Némi iróniát akartam becsempészni, senkit nem akartam megsérteni.
Tényleg nem érzem ennek a létjogosultságát. Nyilván kitépni nem kell, de nem lehet valahogy letiltani simán? Bányászgépnek tényleg az a dolga, hogy szép csöndben, a szoba sarkában növelje a villanyszámlát, semmi rgb, meg zúgás, meg hasonlók. De gamer gépen is vagy ki van kapcsolva, vagy ha játszol, akkor meg a képernyőt nézed, és nem azt, hogy hogyan villog az RGB. Ha ilyenre lenne igényem, nem Linuxot tennék fel, az tuti. Valahogy nem is tudok a Linuxra haragudni, hogy ilyen szélsőséges dolgokat nem támogat. Inkább szépen reszeljék a támogatást olyan hardverekhez, amiknek több haszna van, GPU-k, érintőképernyők, kamerák, nyomtatók. Én már akkor fogom a fejem, mikor a Phoronix ilyen high DPI-s egerek támogatásáról cikkezik. Persze, van, akinek ez is biztosan fontos, de ezt annyira rétegigénynek érzem, hogy nem tartom bajnak, hogy nem teljes a támogatása. Ezzel nem azt mondom, hogy nem kell támogatni, mert ha igény van rá, akkor miért ne, de ne ez legyen a prioritás, hogy ilyen rétegigényeket előbb teljesítenek, mint fontosabb dolgokat.
-
#28110
Frawly
veterán
Plasticbomb
#28105
Frawly
veterán
válasz
Plasticbomb
#28105
üzenetére
Nem kell diff fájlokat hozzáadni. Megmarkolod az RGB világítás kábelét, egy határozott mozdulattal kicibálod a gépből, és a bal vállad felett elhajítod hátra 50 métert, vagy odaadod egy 10 éves gyereknek, akinek fontos még, hogy 1000 színben világítson a gépe.
Annak kell örülni, hogy találtál olyan disztrót, amin működik az, amit akarsz, és nem azon görcsölni, hogy nem úgy világít az RGB. Főleg egy mining gépben nem érzem a létjogosultságát az RGB világításnak.
Az RGB világítással az a baj, hogy már a vezérlési protokollja sem egységes, ahányféle gyártó, annyiféle megoldás van, Windows alatt is csak saját alaplapi szoftverrel működnek ezek. És mivel Windows Géming Pistiknek csinálják ezeket, ezért csak Windows alá adnak ki szoftvert hozzá. Ez ilyen műfaj.
Az Ubi 19.04 meg valószínű azért muzsikál jól, mert új kiadás, új csomagverziók, nem volt még idejük a csomagoknak elavulni, és a friss csomagverziók jól mennek a friss hardverhez.
-
Frawly
veterán
X az biztosan van neki, mert írta a linkelt hsz.-ben, hogy van neki GUI-s kép HDMI-n. Csak a Kodi nem indul neki.
Általában ilyen jogosultság miatt szokott kiütközni, mikor valaki rendszergazdai jogokkal akar X-es progit futtatni, pl. sudo-val vagy hasonló. Tudni kéne milyen felhasználóval próbálja futtatni.
-
Frawly
veterán
Csak a gdrive és Grive utility-ket ismerem. De azok nem tudnak mappaként felcsotolni. Csak annyit tudnak, hogy beállítasz egy mappát, oda töltik le a Google Drive fiók tartalmát, majd ha ott helyben változásokat eszközölsz, akkor ezt leszinkronizálják felfelé is. Tegyél velük egy próbát.
-
Frawly
veterán
válasz
s1999xx
#28062
üzenetére
A pkill csak az illető alkalmazást lövi le, ha a -f kapcsolóval a teljes parancssort megadod. De ennek a $! változónak utánanézek, ezt nem ismerem.
Az egészet egy script hívja, grafikus felületről futtatva. Azért kell a asciiquarimot terminálemulátorban futtatni (nálam ez Termite), mert ha anélkül futtatod, akkor nem látszik, hogy fut, nem olvasható a kimenete grafikus felületről, úgy látszana, mintha nem is futna, pedig fut. Ezért a script termite -e 'asciiquarium' formában indítja a háttérben.
-
Frawly
veterán
válasz
brickm
#28063
üzenetére
Mondom, nem működik, mert a killall binárisnevet kér. Jó, talán úgy működne, ha már a bináris nevében is szóköz van. De a legtöbb progi (top, htop, vtop, gotop, lxtask, gnome-system-monitor, stb..) a folyamatoknál nem a folyamat tényleges nevét mutatja, hanem az egész parancssorát, amivel indítva volt, pl. perl /usr/bin/asciiquarium. A killall ezt nem eszi meg, mindegy hogy escape szekvenciázod a szóköz. Ez volt az első, hogy "perl\ /usr/bin/asciiquarium" és "perl\ \/usr\/bin\/asciiquariumként" megpróbáltam, de akkor még nem tudtam miért nem működik. Közben meg az adott folyamat neve simán "perl", ez a bináris fut, ez az asciiquarium nem bináris, hanem egy script, amit futtat a perl. Az megint más, hogy paraméterben a /usr/bin/asciiquarium lett megadva. A killall nevében pont azt jelenti az „all”, hogy ilyenkor mindent kilő, killall perl parancsra az összes futó Perl-folyamatot lelövi nem szelektíven.
A lényeg, hogy nem a jó eszközt próbáltam használni, a killall nem arra való, amit szerettem volna. Helyette a pkill kell, az lényegében egy kill $(pgrep "keresendő"). Megzavart, hogy a legtöbb hasonló scriptben a killallt használják, ez pedig rossz irányba vitt.
-
Frawly
veterán
válasz
s1999xx
#28060
üzenetére
Közben rájöttem, hogy a killall parancs egyrészt nem kezel szóközöket, másrészt a process nevét kéri, és a legtöbb process listázó/ps/*top alkalmazás nem a tényleges nevet írja ki, hanem az indító parancssort, ami sokszor nem egy és ugyanaz.
Ez a progi a termite -e asciiquarium parancsot futtatva valóban simán perl néven fut, míg a parancssora perl /usr/bin/asciiquarium.
A megoldás azonban megvan. A pkill utility-t kell használni, az tud rendes regexpet:
pkill -f asciiquariumA -f kapcsoló azért kell, hogy a process neve helyett (ami továbbra is csak simán perl) az indító parancssorában keressen. Egyébként meg a killall parancs onnan kapta a nevét, hogy ha valami több példányban vagy több paraméterrel is fut, akkor az összeset bezárja, pont ez a lényege, hogy nem lehet parancssor alapján differenciálni, hogy mit zárjon be és mit hagyjon nyitva. Csak egy egyszavas, azaz szóközök nélküli processnevet fogad, ha többet is talál, mind bezárja.
A másik, ami nem elegáns a scriptben, az az 1-2-es virtuális asztal konkrét bedrótozása, de ez nálam nem probléma. Mindig csak egy munkaasztalt használok, az 1-es számút. A 2-eset csak speciális esetre (show desktop funkció, ha a háttérképet akarom lecsekkolni vagy most ennek a képernyőzárolós megoldásnak). Tehát nem zavar be semmibe, úgyis olyan felállásból fut mindig, hogy az 1-es munkaasztal az aktív.
-
Frawly
veterán
válasz
Frawly
#27887
üzenetére
Na, végül ez is megoldva. Mostantól már az asciiquarium a képernyőzáram.
Írtam rá egy scriptet:
#!/bin/bash
swaymsg "workspace 2"
termite -e 'asciiquarium' &
sleep 0.6
swaylock -e -c FFFFFF00
killall perl
swaymsg "workspace 1"Az alapfelállás az, hogy előbb elindul az asciiquarium egy új terminálablakban, majd utána elindul rá a waylandes swaylock képernyőzároló, ami transparensz hátteret tesz ki, így a zárolóképernyő nem is látszik, hanem a mögötte terminálban futó asciiquarium képét látni folyamatosan. A kettő közé be kellett toldani egy várakozást, és a Sway WM-ben virtuális asztalt kellett váltani és beállítani, hogy az asciiquarium mindig fullscreen-ben fusson, különben nem működik rendesen, de ezek a Sway baromsága miatt szükségesek csak. Így zároláskor békésen úszkálnak az ASCII halacskák
Egy szépséghibája van, az asciiquarium perl alkalmazás, és a futása alatt elég magas a procihasználat (1 szálon 12%, ami 3% összprocihasználat), de a cmatrix esetében sem sokkal alacsonyabb, bár még kibírható tétel.A killall rész kicsit gányolós benne, máshogy nem tudom kilőni az asciiquariumot. Hiába próbálom regexp-pel nem fogadja el. Pedig előre tudom, hogy "perl /usr/bin/asciiquarium" néven fog futni, a PID előre nem ismert.
-
Frawly
veterán
válasz
Frawly
#28056
üzenetére
Erre is megvan a megoldás, ezzel a módszerrel:
output=$(clear; do_a_lot_of_output_here)Arra kellett még figyelnem, hogy kiírás közben a kurzort el kell rejtenem egy escape szekvencia kiírásával, így már minden olyan, mint a watch parancsra, csak ki lehet lépni q billentyű lenyomására. A script végül így alakult:
#!/bin/bash
while true; do
output=$(clear; cat /proc/cpuinfo | grep MHz; echo -e; sensors | grep -e '°C' -e 'RPM'; echo -e; free -wm; echo -e; uname -rom; echo -e; df -h | grep /dev/sd )
echo -e "$output \n\e[?25l"
read -n 1 -t 1.9 input
if [[ $input = "q" ]] || [[ $input = "Q" ]]; then break; fi
done@s1999xx: én is ezt a megoldást találtam meg végül. De nem baj, hogy betettem, mert kiegészítettem ezzel az \e[?25l szekvenciás kurzorelrejtéssel. Így már teljesen olyan, mint a watch parancs, aminek ezt alapból kéne tudnia, hogy a paraméterben beállított billentyű figyelésére is lépjen ki.
-
Frawly
veterán
válasz
Frawly
#28055
üzenetére
Na, mire megírtam a hozzászólást, meg is találtam a megoldást: a read parancsot kell a -n 1 és -t kapcsolókkal ellátni. Az -n 1 paramétert ismertem, az csak egyetlen karaktert kér be egy egész sor helyett. De a t kapcsoló új, amögé be lehet írni másodpercben megadva, hogy meddig várjon, és ez egyben a sleep parancsot is kiváltja.
Így meg is szakad a script egy gombnyomásra, de észrevettem egy másik gondot vele. Így a kiírt tartalom a clear (képernyőtörlés) miatt villódzik, míg a watch parancsnál nem villog. Erre valami megoldás? Próbáltam printf "\033c"-t is, az is letörli a képernyőt, de azzal is villódzás van.
Több egymás után lefutott parancs kimenetét írom ki, minden 1-2 másodpercben. Viszont mivel az egyes parancsok lefutása igénybe vesz pár ms-ot, így villog a képernyő. Esetleg lehetne, hogy a kimenetet először valami fájlba vagy bufferbe irányítani, majd mikor lefutott az összes parancs, akkor egy nekifutásra kiírni a tartalmát?
-
Frawly
veterán
Sciptelési kérdés: a watch parancsot szeretném kiváltani. Olyan megoldást keresek, amiből egyetlen tetszőleges vagy előre beállított billentyű lenyomásával ki lehet lépni. A watch paranccsal az a bajom, hogy csak Crtl+C-vel szakítható meg, ami kényelmetlen.
Ki tudom váltani while do kijelzett_parancs sleep n done bash-es megoldással, de arra nem jövök rá, hogy mit kéne ebbe a ciklusba beletenni, hogy egy gombnyomásra meg lehessen szakítani, ne csak Ctrl+C-vel. Valami ötlet a megoldásra?
-
#28053
Frawly
veterán
Plasticbomb
#28047
Frawly
veterán
válasz
Plasticbomb
#28047
üzenetére
Rakj fel helyette Archot, vagy Manjaro-t. Azokon is frissek a csomagok, nem kell tárolókat felvenni, meg nonfree dolgokkal szívni, a pacman csomagkezelő sem kényszerít csomagdowngrade-re, mivel abban tényleg van skip-funkció. Full rolling, sose kell kiadást frissítened, Steam is normálisan megy rajta mindenféle verziótrükközés meg külső tárolózás nélkül.
Bár lehet Fedora alatt is skipelhetőek ezek valahogy, ilyen mélyen nem értek hozzá. Rég használtam Fedorát, akkor is csak felszínesen próbáltam be, akkoriban ráadásul még yum-mal, dnf-et nem ismerem.
-
Frawly
veterán
válasz
bambano
#28041
üzenetére
Ja, így is ki lehet deríteni, weboldalakon meg archív kiadási megjegyzések alapján. Csak a rák akar állandóan nyomozgatni, bőven jó lenne, ha a verziószámból meg lehetne azonnal állapítani. Most komolyan, te utánanézés nélkül fejből tudod, hogy a 3.5-ös kernel mikor jött ki?
Ez a 20 ujja van Linusnak csak humor volt. Igazából csak nem szerette volna, ha 4.5345634454.34532459321432984732 lenne a verziószám. Idejét látta, hogy ha már valami 4 millió kódsor változott, meg 2-3 év alatt kijött 20 alverzió, akkor az újabb kernel új főverzióval jöjjön ki.
De már számozták mindenféle szisztéma szerint a kerneleket. Nem is olyan régen, pár éve még az ment, hogy a páros alverziók voltak a stabilak, a páratlanok a dev ágak. Ez még a 2.4 és 2.6 korszakban volt.
De a legjobban azt a verziószámozást utálom, amit Knuth csinál, hogy a π-t és az e-t közelíti egyre jobban a verziószám. Na az aztán teljesen átláthatatlan, hogy hányadik verzió, melyiknél újabb, mikor jött ki. Meg az is nagyon láma, mikor ilyen 10 éve fejlesztett szoftvernél 0.0.0.9.8 pre-alfa-gamma-teta-test-dev verziónál tartanak (pl. Double Commander), mert sose tekintik a szoftvert késznek (1.0 stable). Vagy a másik véglet, amit a Google csinál, hogy 2008-ban indult a Chrome, és már kint van a 94534543243432. verzió belőle, mert minden 6 hétben kijön egy, ha kell, ha nem, csak azért, hogy növeljék a verziószámot és úgy látszódjon, hogy milyen nagy történeti múlt van mögötte, annak sincs egy deka értelme sem.
-
Frawly
veterán
válasz
Siriusb
#28011
üzenetére
Szerintem az verziószámozást meg kéne változtatni a kernelnél.
Át kéne térni az év.hónap.alverzió, vagy év.hét.alverzió verziószámra. Persze ez már utólag zavaró lenne, de ha minden kiadásnál így csinálták volna, akkor most tartanánk a 1.9.3.1 kernelnél (2019. március, 1. patchel ellátott verzió, azaz a mostani 5.0.1). Persze ehhez a legelső kernelnek is 0.1.9.0-nak kellett volna, hogy legyen (1991. szeptember, nem patch-elt verzió).
De az is igaz, hogy a múltban is mindenféle eltérő koncepció mentén számozták.
Ez az év.hónap azért is jó, mert amikor valaki benyögi sok év után, hogy X.Y.Z verziót használ, akkor lehetne azonnal tudni, hogy milyen régi. Ahogy a 6.06-os Ubinál is látni, hogy 2006 júniusában jött ki, a 14.04 meg 2014 áprilisában.
-
#28034
Frawly
veterán
Plasticbomb
#28028
Frawly
veterán
válasz
Plasticbomb
#28028
üzenetére
Nem a skip-brokenről, hanem a skip-missing-ről beszélek. De legrosszabb esetben megengeded neki, hogy leszedje a Steamet. Tudom, bosszúság, mert törlődik a sok giga játék is. Én egyébként ezért nem szeretem a Fedorát, idióta tárolókiosztás, csak félrolling, és a csomagkezelője sem a legjobb. Archon, Ubi-Debi-vonalon a csomagkezelők simán tudják, hogy nem foglalkoznak a függőséggel és nem kényszerítenek downgrade-re.
Egyébként ezért népszerűek az Arch alapú disztrók:
1) frissek (ezen a ponton már az Ubi és társai nem tudnak versenyezni)
2) nincs velük az a mizéria, mint a többi disztróval, mivel a csomagolók nem adnak hozzá semmihez semmi extrát, nincs semmi saját szájíz szerint bonyolítva, nonfree-sítve, saját disztrópatchekkel hackelve, különösen igaz ez a pure Archra. Csak felteszed, megy, friss, nem ütközik teljesíthetetlen verziófüggőségekbe semmi, nem kell külső tárolózni, stb.. -
Frawly
veterán
válasz
s1999xx
#28015
üzenetére
Valóban furcsa, hogy egy ilyen bepróbálkozik, de annyira azért nem gáz. Nyilván nem Jézus Krisztus futtatta az inxi-t, meg nem magától futott le cronból vagy systemd szervizből, hanem valaki kíváncsi volt valamire, és elindította. Na, ő a felelős, meg aki az inxi csomagot telepítette.
-
#28025
Frawly
veterán
Plasticbomb
#28014
Frawly
veterán
válasz
Plasticbomb
#28014
üzenetére
A Steamet, Lutrist tárolókból telepíted? Mert egyébként a dnf-nek van --skip-missing kapcsolója, amivel figyelmen kívül hagyja a függőségeket, szerintem ennek hatására a downgrade-et sem erőlteti.
Vagy ha sehogy nem megy, megengeded neki a downgrade-et, majd mikor feltelepítetted ezt a kettőt, újra upgrade-eled ezeket a csomagokat manuálisan.
Az OpenCL-hez sajna nem értek, nem tudom mi kell hozzá, hogy a legújabb verzió menjen.
-
Frawly
veterán
válasz
vargalex
#28009
üzenetére
Wow, akkor nagyon gyorsak voltak. 1-2 nap szokott kelleni, mire a Testing vagy Staging tárolóban megjelenik az új stable kernel, és ezután általában 1-2 hét, mire a Core tárolóban is megjelenik. Szerintem nem kerneltől vagy felfedezett bugoktól függ, hanem inkább akkor, hogy mikor érnek rá a kerneles csomagfenntartók.
(#28008) Frawly: sudo chown felhasználód /hdd/csatolási/pontja -R
Lemaradt a hozzászólásból az -R kapcsoló.
-
Frawly
veterán
válasz
Victoryus
#28003
üzenetére
A transmissiont el lehet indítani daemon módban, akkor a grafikus felület kilövése nem érinti:
transmission-daemonEzt külön kell feltenni, nem a transmission csomaggal, hanem a transmission-cli csomaggal.
A jogosultságokat úgy kell megoldani, hogy saját tulajdonba veszed a HDD-n a fájlrendszereket (egész partíció). pl.:
sudo chown felhasználód /hdd/csatolási/pontja(#28007) Lenry: már be is röffentettem Arch Testingből. Semmi változást nem tapasztalok a 4.20-hoz képest, se javulás, se bug nem jelentkezett eddig. Nem is csoda, mert az 5.0 egy átszámozott 4.21. Emiatt kár is volt átnevezni. Új főverziót akkor kéne kezdeniük, ha komoly, koncepcionális változás van, vagy az egészet újraírják.
-
Frawly
veterán
válasz
s1999xx
#27993
üzenetére
De, neki az kell, hogy kivágja a grafikus felületről. Arra teljesen jó a systemctl stop lightdm. Visszadobja konzolba, ott bejelentkezik és futtathatja is a szerveres dolgait, grafikus felület nélkül. Ha meg szükség van újra grafikus felületre, startx-szel elindítja vagy esetleg systemctl start lightdm-mel.
Annyit még megjegyeznék, hogy csak Xubuntun van LightDM, Ubuntun GDM van, ha jól emlékszek. De utóbbit is ugyanúgy kell leállítani: systemctl stop gdm.
(#27992) Victoryus: géptől, DP porttól, átalakítótól függ, hogy átmegy-e DP csatin a hang. Én alapból arra tippelnék 99%-os eséllyel, hogy nem fog hang átmenni, de próbáld ki. Hátha megy. Ha nem megy, akkor analóg jacken vidd át a hangot, bár az meg a kijelzőn lehet probléma, mert ha HDMI bemenetre van állítva, akkor figyelmen kívül hagyja az analóg audiójelet.
-
Frawly
veterán
válasz
Anakin007
#27985
üzenetére
De, pedig kernel bug, úgy emlékszek, Ubuntun 18-on is előjött nemrég valakinek vagy itt a PH-n vagy a HUP-on. Úgy emlékszek, hogy nála vagy kernelfrissítés vagy NV GPU driver volt a ludas, azt downgradelte, és onnantól megszűnt. De már nem találom a topikot, pedig nemrég volt.
Archon még sose volt ilyen problémám, de az úgyis túl instabil disztró, hogy ilyenek előjöjjenek rajta
Próbáltam ezt systemctl disable módszerrel letiltani, de hasztalan, minden bootkor elindul csakazért is.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
- ÁRGARANCIA!Épített KomPhone Ryzen 7 9800X3D 64GB RAM RTX 5080 16GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! AMD FX-8320 8 mag 8 szál processzor garanciával hibátlan működéssel
- MikroTik CCR1009-7G-1C-1S+ Cloud Router
- Apple iPhone 14 128GB, Kártyafüggetlen, 1 Év Garanciával
- BESZÁMÍTÁS! VALVE Steam Deck LCD 1TB SSD kézikonzol garanciával hibátlan működéssel
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged