Hirdetés
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- gban: Ingyen kellene, de tegnapra
- Magga: PLEX: multimédia az egész lakásban
- Meggyi001: Kuponok....
- Gurulunk, WAZE?!
- bambano: Bambanő háza tája
- Luck Dragon: Asszociációs játék. :)
- Rap, Hip-hop 90'
- Brogyi: CTEK akkumulátor töltő és másolatai
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
-
LOGOUT
Linux kezdőknek - érdemes beleolvasni, mielőtt kérdezel
Új hozzászólás Aktív témák
-
A Gnome Szoftver sose volt a helyzet magaslatán, akárhányszor próbáltam használni, mindig volt vele valami gond, úgyhogy szépen lassan le is szoktam a használatáról.
A másik ilyen program a Gnome Weather volt. Ezt a 40-es verziónál tették tönkre, mert korábbi verziókban bármilyen települést be lehetett állítani, onnantól felfelé viszont csak azokat, amik szerepelnek az adatbázisában, és az nem túl sok. Én egy ~60 ezres városban élek, és ez pl. nincs benne, így nekem gyakorlatilag használhatatlan.Amúgy azon szoktam gondolkodni, hogy a weboldalán a képeken csak azért szerepel Budapest, mert érzékeli, hogy MO-ról vagyok, vagy mindenki ezt mutatja-e?
-
-
válasz
moleculez
#99589
üzenetére
Most olvasom, hogy Notably for command-line users, we’ve changed the default terminal to Ptyxis.
Kíváncsi vagy, hányszor fogom elgépelni (sehányszor, mert első dolgom lesz feldobni helyette a Gnome terminált).Az új dnf mennyivel gyorsabb, mint a 4-es? RPMFusion frissült már?
-
válasz
Rimuru
#99033
üzenetére
A csomagkezelő oda rakja a binárist, ahova a készítője akarja. Megcsinálhatná a Firefox is azt, hogy a csomag nem a végleges helyére rakja a binárist, hanem másik mappába, vagy ugyanabba a mappába, csak másik névvel, és amikor indítod a Firefoxot, akkor egy script kicseréli a régi binárist a régire.
Nem csak engem zavar ez a dolog,, és látom a kommentek közt más is írta már ugyanazt a megoldást, amire én gondolok. -
-
-
válasz
Petya XT
#98778
üzenetére
Én is próbáltam már erre rákeresni, túl konkrét dolgokat nem találtam. De szerintem "fertőzött" kifejezés nem olyan jó, inkább "szennyezettnek" kellene fordítani, bár az sem fedi le teljesen a dolog jelentését.
Hogy miért lehet "fertőzött" egy kernel, több oka lehet:
- pl. valamilyen nem GPL-es, hanem propitetary licencű betöltött modul (pl. NVidia vagy AMD GPU driver)
- live patchelt kernel
- valamilyen hiba vagy bug folytán korábban leálló kernel
- force-olva betöltött kernel modul, ilyenek...Szóval úgy kb. azt jelenti, hogy nem a gyári eredeti kernel fut, hanem lett betöltve valami, vagy egy bug vagy valamilyen hiba folytán esetleg módosulhatott. Ez igazából egy ilyen utalás arra, hogy ha hibát keresne az ember, elképzelhető, hogy a kernelben van hiba.
https://docs.kernel.org/admin-guide/tainted-kernels.html
https://support.hpe.com/hpesc/public/docDisplay?docId=c02905321&docLocale=en_US
https://unix.stackexchange.com/questions/118116/what-is-a-tainted-linux-kernel
-
Ha megcsinálod a méretvonalakat úgy, ahogy leírtam, akkor ugyanúgy a rajz részei lesznek, mint bármilyen más objektum, úgyhogy elméletileg ugyanúgy ki is kell nyomtatódniuk. Ha máshogy nem megy, akkor mentsd el először PDF-be, és nyomtasd ki azt.
Ha erősen műszaki jellegű rajzot szeretnél készíteni, akkor viszont Inkscape helyett valami CAD programmal lenne célszerű csinálnod, pl. FreeCAD-ben.
-
#98706
urandom0
senior tag
tordaitibi
#98702
válasz
tordaitibi
#98702
üzenetére
Hú, igazad van, bocsi, összekevertem a hibernálást a hybrid sleeppel
-
-
Amúgy a powercfg /H off parancs a hibernalást kapcsolja ki (ezért nem lesz fast startup sem).
![;]](//cdn.rios.hu/dl/s/v1.gif)
Igen, mert a kettő gyakorlatilag ugyanazt a technológiát használja a háttérben. Nem tudod egyiket kikapcsolni a másik nélkül.
Ubynak ezt kell kikapcsolni, mert ez zárolja a meghajtó, nem a BIOS-os fast boot. A BIOS-os fast boot az olyan, hogy nem végez annyi hardverellenőrzést, ilyesmik.
-
-
válasz
Synaptic
#98578
üzenetére
Ha félsz, hogy valamit hazavág, tedd fel flatpakból: https://flathub.org/apps/com.github.wwmm.easyeffects
Ez kevéssé valószínű, hogy bármit is tönkretesz. -
#98581
urandom0
senior tag
tordaitibi
#98577
válasz
tordaitibi
#98577
üzenetére
Újabban EasyEffects néven fut: [link]
Disztrótól függően vagy ilyen, vagy olyan néven lehet megtalálni a repóban. De ez a Pipewire-hez igazított verzió, szóval ha Pipewire van a disztróban, akkor ezt érdemes feltenni, a PulseEffects-s pedig hanyagolni (mert az a PulseAudio-hoz készült, régebbi változat). -
Ez a Rhino Linux már majdnem olyan szép, mint a Hannah Montana Linux
-
válasz
RaZroX
#98504
üzenetére
A flatpak, a snap és az appimage is nagyon hasonlít a Mac-féle app bundle-re, a legnagyobb különbség ezek között, hogy a flatpak és a snap csomagok között függőségek definiálhatók, tehát pl. egy flatpak csomag függhet egy másik csomagtól. Ha pl. két flatpak csomagnak kell a Gnome 44 runtime, akkor elég egyszer feltelepíteni, mindkét csomag tudja használni.
Illetve a flatpakhoz és a snaphoz beépített támogatás van majdnem minden disztróban (legfeljebb alapértelmezetten nem települ fel), de az appimage-hez nincs ilyesmi. A flatpak/snap csomagok nagyon könnyen telepíthetők, frissíthetők, törölhetők parancssorból vagy grafikus programból, appimage-hez nincs ilyen jellegű támogatás (harmadik féltől származó program van rá). -
#98507
urandom0
senior tag
tordaitibi
#98500
válasz
tordaitibi
#98500
üzenetére
Az a baj, hogy egy disztró karbantartása sokkal nagyobb feladat, mint amennyire elsőre annak tűnik, és ezt sokan nem látják az elején. Mert nem csak arról szól, hogy fogok egy alap disztrót, hozzácsapom a saját csomagjaimat és kész. Minden apró hülyeséggel foglalkozni kell, ami nagyon el tudja vinni az időt.
Én a múltkor a Guefihez deb és rpm csomagokat. Ez egy pici, egyszerű program, ráadásul még ritkán is frissül, de mivel alapból Slackware-hez készült, így meg kellett patchelnem, hogy más rendszerek alatt is menjen (és még egy patchet csináltam hozzá, hogy a parancsikonok is rendben legyenek).
Ha most lenne 3-4 olyan csomagom, amihez mondjuk hetente-kéthetente jönnek frissítések, és folyamatosan karban szeretném tartani őket, már az heti több óra elfoglaltságot jelentene nekem, és azt kéne beillesztenem a napi dolgaim közé... -
-
válasz
moleculez
#98462
üzenetére
Ezek addig működnek jól amíg az egyes (szubkúltúrák) szakterületek a saját kis ökoszisztémájukat karbantartják, és/vagy találnak hozzá szponzort mert elég fontos (vagy annak eladható).
Hát igen, amikor pénzérdek van a dolgok mögött, akkor működnek, hobby fejlesztésnél viszont sokszor sajnos nem. Megunja a fejleszti, elveszti a motivációt, vagy történik valami, aztán úgy járunk, mint a left-padnál. Kihúznak egy téglát, aztán dől össze a kártyavár.
Én mostanában Javazok, és itt hatalmas nagy előny, hogy fixen ott van a JRE, amiben az alapvető függvények és azon kívül sok-sok hasznos függvény ott van. De ha komolyabb dolgot akar az ember, akkor ahhoz is kénytelen lehúzni a netről a függőségeket.
-
válasz
RaZroX
#98471
üzenetére
Mi történik ha nem váltok azonnal amikor kijön az új, hanem várok pár hónapot amíg az is stabil lesz?
Fedoránál ez úgy van, hogy évente két főverziót adnak ki, általában áprilisban és októberben egy-egyet, és minden főverzió körülbelül 13 hónapig van támogatva. Ez azt jelenti, hogy amikor kijön az új verzió, az eggyel korábbi verzió akkor van kb. az életciklusa közepén, azaz onnantól még fél évig támogatott, az azelőtti verziónak pedig hamarosan, pár héten belül lejár a támogatása.
Itt egy kép, ha jobbra görgetsz, ott vannak a jelenlegi kiadások:
https://en.wikipedia.org/wiki/Template
edora_Linux_release_timelineItt látszik, hogy a 40-es verzió megjelenésekor a 39-es verziónak még kb. fél éve volt hátra a támogatás megszűnéséig, ez hamarosan lejár. A 38-as verzió támogatása pedig kb. egy hónappal a 40-es verzió megjelenése után járt le.
Konkrétan így néz ki a dolog: https://endoflife.date/fedora
Szóval akár két verzióval is lemaradhatsz, vagy ha egy verzióval vagy lemaradva, akkor van fél éved az átállásra. Én sem szoktam elkapkodni egyébként, mindig kivárok pár hónapot.
-
válasz
#63718632
#98467
üzenetére
A Fedora telepítőbe be van "drótozva", hogy kell egy /boot partíció 1GB méretben és ext4 fájlrendszerrel.
Nincs bedrótozva, csak alapértelmezett felállás az, hogy készít magának boot partíciót. Azért a Fedora telepítője nem akkora rakétatudomány, mint ahogy itt egyesek beállítják.
Haladó módban bárhogy lehet partícionálgatni. Az "über expert" mód a Blivet GUI, de átlagos otthoni felhasználásnál soha nincs rá szükség, én is csak egyetlen egyszer használtam, mert kíváncsi voltam rá.Fel kell rakni párhuzamosan egy "susét" és egy "fedórát" és megnézni a különbségeket. Vagy nagyon mélyen doksikat olvasni.
Itt egy Suse telepítés:
[root@Fujitsu-Suse /home/balazs]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 119,2G 0 disk
├─sda1 8:1 0 487M 0 part /boot/efi
├─sda2 8:2 0 114,9G 0 part /var
│ /usr/local
│ /tmp
│ /srv
│ /opt
│ /root
│ /boot/grub2/x86_64-efi
│ /home
│ /boot/grub2/i386-pc
│ /.snapshots
│ /
└─sda3 8:3 0 2G 0 part [SWAP]
sdb 8:16 0 931,5G 0 disk
└─sdb1 8:17 0 931,5G 0 part /mnt/sdb1
sr0 11:0 1 1024M 0 romVan még két másik Suse-s gépem, mindkettőnél van egy ~500 MB-os EFI boot partíció, ez nyilván az UEFI boot miatt kell.
---
Kicsit szerintem túl van lihegve ez a partícionálósdi. A disztrók által felkínált default partíciós sémák az otthoni felhasználók 99%-nak teljesen jók.
A BTRFS pedig teljesen jó, teljesen használható, kb. 5 éve csak azt használok, semmi gond nincs vele. -
Félig-meddig elolvastam a levelet, meg a szálat is, ami vicces, hogy épp a Pythont hozzák fel példának. Én is úgy vagyok, mint az egyik hozzászóló, hogy ha valami úgy kezdődik, hogy pip install..., akkor hagyom a francba, mert tudom, hogy jó eséllyel úgysem fog működni.
Semmit nem ér, hogy lehet egymás mellé telepíteni eltérő verziójú Pythonokat, ha egyszer szinte minden Pythonos cucc a netről szedi a függőségeit - olyan függőségeket, amiket ezer éve nem tart karban a kutya sem, sok közülük nem is létezik már.És ez a történet valóban nem a Rustról szól, nagyjából minden nyelv és környezet ilyen manapság. NodeJS-ből is addig jó a 16-os, amíg nem akarsz olyan projektet fordítani, amihez legalább 18-as kell, és akkor nincs mit tenni, ha mondjuk Debianban csak 16-os van, akkor be kell szerezned valahonnan frissebbet. De mondhatnám a Go-t is, ugyanez a szitu. Vagy XY random nyelvet/frameworköt, az is ugyanez. Nem véletlenül mentek rá manapság annyira a snap/flatpak/appimage/docker cuccokra, mert azok az oprendszertől függetlenül tudnak frissülni (vagy épp verziót lockolni).
Egyszerűen el kell fogadni, hogy manapság a világ kurva gyorsan változik, és ami egy éve még friss volt, az ma már elavultnak számít, és sok esetben lehetetlen fenntartani a függőségi rendszert. Már én rászoktam a dockerre, pedig az elején utáltam.
Amikor elkezdtem Java fejlesztéssel foglalkozni, akkor is úgy voltam vele, hogy jó lesz nekem a Java 8 is, amíg támogatott, aztán majd átállok 11-re. Aztán már én is Java 21-nél tartok, mert a 8-as verzióval egy rakat cucc nem megy, a 11-es nincs normális GraalVM támogatás, és így tovább...A Rusttal kapcsolatban meg el kell fogadni, hogy egy új dolog, és sok minden messze nem eléggé kiforrott még körülötte. De amit írnak vele kapcsolatban, hogy a borrow checker nem ér semmit, az egy orbitális baromság. Lehet persze körkörös referenciákkal memleaket csinálni Rustban is, de a mostani toolok többsége az ilyet kiszűri, és egyébként meg oda kell figyelni.
-
#98455
urandom0
senior tag
tordaitibi
#98449
válasz
tordaitibi
#98449
üzenetére
Ez nem Linuxos probléma, ez egy általános tendencia, hogy a fejlesztő cégek vagy kirakják a félkész szoftvert nyílt forráskódba, hogy a többit majd tegye hozzá a közösség, és onnantól fogva a fejlesztő cég csak annyi felelősséget vállal, hogy befogad-e egy adott commitot vagy sem. És bumm, így születnek a szar szoftverek.
Ez persze baromi jó a cégnek, mert nagyon alacsony erőforrásokkal tudja fejleszteni és tesztelni a szoftverét, mert ezt meg teszi helyette a közösség. Csak hát amíg a munkahelyen kivágnak, ha nem dolgozol, addig egy nyílt forráskódú fejlesztőt semmilyen retorzió nem ér, ha hetekre vagy hónapokra eltűnik.
Én írtam mobilappot Fluterrel és Darttal, ott ugyanez ment. Nincs semmilyen csomag a bluetooth kezelésére? Majd a közösség megoldja... meg hát, csak ha az egyik fejlesztő elmegy nyaralni 2 hétre, és bug van a csomagban, te meg nem tudod lefordítani az appod, az nagyon jó érzés.
-
válasz
moleculez
#98392
üzenetére
A .desktop fájloknak alapvetően nem kell x jogosultság, mert nem futtatható fájlok, hanem inkább konfigurációs fájlok, amik az asztali környezetnek szólnak. Gyakorlatilag viszont korábban volt már olyan, hogy az x nélküli .desktop fájlokat nem jelenítette meg a rendszer.
Olyanba is belefutottam már, hogy ha nem a $PATH-ban lévő könyvtárba települt a program indítófájlja, akkor a .desktop fájlban meg kellett adni azt az útvonalat, ahova települt, másként nem volt hajlandó megjelenni az indítóban. -
válasz
totron
#98323
üzenetére
Nem zavar, mert én nem a Windowsra készült tízbillió szoftvert akarom használni, hanem azt a tucatnyit, amire szükségem van, és az mind elérhető Linuxra is.
A kis Raspberry-met napi szinten használom, ezen van a webszerverem, ezt használom fájlszervernek, elég fura lenne mondjuk ezen Windowst futtatni, már csak azért is, mert Windowsra nincs tmux (és semmilyen terminal multiplexer). És ez engem sokkal jobban zavar(na, ha használnék Windowst).
Minden egyéb platformon nagyobb a kínálat.
Amennyiben egyéb alatt a Windowst és a MacOS-t értjük, akkor igen.
-
válasz
moleculez
#98278
üzenetére
Egyes Windowsokon a SysMain (régebbi nevén Prefetch) szolgáltatás memóriaszivárgást okoz. Én eddig két gépen találkoztam ezzel, egy asztali gépen és egy laptopon, ami egyébként azért is érdekes, mert van 4-5 ugyanolyan laptopunk, és azok közül egyiken sem jött elő...
Nade ez a dolog úgy néz ki, hogy bekapcsolod a géped, a memória kb. 30%-a foglalt. Aztán ahogy telik az idő, egyre feljebb megy, végül megáll olyan 99%-os memóriahasználatnál, és kegyetlenül belassul tőle a gép, és nem tudsz vele mit csinálni. Le kell tiltani a szolgáltatást, és onnantól oké a dolog.
Nem lehet, hogy ebbe futottál bele te is?Én meg úgy jártam a minap Windows 11-gyel, hogy egy nem engedte lefrissíteni a Windows 10-et egy i7-7700-as gépet, ami nem is annyira meglepő, mert a Windows 11 CPU kompatibilitási listájában nincs benn ez a proci.
Viszont letöltöttem az ISO-t egy pendrive-ra MCT-vel, és onnan meg szó nélkül felment
Szóval vannak vicces dolgai ennek a Windowsnak. -
válasz
szbalogh
#98259
üzenetére
Szia.
Szerintem ez nem nagyon fog menni máshogy, mint forrásból fordítással.
Esetleg megpróbálhatod hozzáadni az elrepót:
https://elrepo.org/wiki/doku.php?id=startEzen belül van három repó, az elrepo-extras, elrepo-testing és elrepo-kernel. Ez utóbbiban van a kernel-lt, ami long term, azaz hosszú támogatású jelent, és a kernel-ml, ami pedig a mainline-t jelenti. Megpróbálhatod lecserélni a jelenlegi kerneled, mert a mostani elég régi, viszont a 6-os verzióban már alapból bent van a 8188eu driver, ami kell a TP-Linkhez.
Vagy marad a forrásból fordítás innen: https://github.com/lwfinger/rtl8188eu
Végső esetben megpróbálhatod innen lekapni az rpm-et (kmod-8188eu-*), de nagyon meglepődnék, ha ez jól működne.
De én elsősorban a rendszerfrissítést javasolnám, próbálj meg áttérni 9-re. Én Rocky 9.4-et használok egy RPi-n, ebben 6.1.31-es kernel van, a TP-Link szerintem ezzel a verzióval már megy.
-
válasz
vizcsap
#98250
üzenetére
Feltételezem ha belső meghajtóra telepíteném a rendszert, akkor nem lenne ilyen probléma
Igen. Valószínűleg a külső házad nem inicializálja a lemezt időben, ezért a rendszer nem találta meg magát. Külső házas történeteknél ilyenek előfordulnak.
@mindenkinek
A Fedora és a Fedora alapú rendszerek alapértelmezetten btrfs-t használnak. A /var, /var/home stb. mappákat külön subvolume-ok alá csatolják fel. A subvolume-ok olyanok, mint egy "fájlrendszer a fájlrendszeren belül", saját gyökérrel, saját inode táblázattal, stb.
Az a partíciófelosztás, a vizcsap ezen screenshotján van, teljesen normális, fizikailag egy partíción vannak azok a mappák, csak más subvolume alá vannak felcsatolva. -
-
válasz
ubyegon2
#98206
üzenetére
*ez szerintem nem is Linuxos appimage
$ file viber.AppImage
viber.AppImage: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=30e06184968532b6a9aa36f44ada39e4af0bda56, for GNU/Linux 2.6.32, strippedDe az!
Én vagy két hete próbálgattam végig a deb-es, az rpm-es, az appimage-es és a flathub-os Vibert. Az ikonjukon kívül nem észleltem köztük különbséget.
-
válasz
szuszinho
#98181
üzenetére
Akkor viszont meg kéne nézni, hogy cron alatt a $PATH-ban benne van-e a zip, a find, a date, esetleg a teljes env-et is kiírathatod.
És valami ilyesmű jellegű logolást tehetnél a scriptbe:
#!/bin/bash
d=$(date +%Y_%m_%d)
echo "date: $(date +%Y_%m_%d), d: $d" >> log.txt
zip -r /ide/file_$d.zip /ezt >> log.txt 2>&1
echo "/ide/file_$d.zip" >> log.txt
find /ide -type f -mtime +15 >> log.txt
find /ide -type f -mtime +15 -exec rm {} \; >> log.txt 2>&1Nem próbáltam ki, lehet, hogy van benne hiba. De a lényeg, hogy logolj el mindent, hátha csak valami banális hiba van.
-
Hát kérlek szépen, ez egy segmentation fault, vagy más néven access violation. A Gnome Commander olyan memóterületet akart elérni, ami nem hozzá tartozik, valószínűleg egy lefoglalatlan memóriaterületre akart írni, vagy el van indexelve benne egy tömb, stb.
Ezzel nem tudsz mit kezdeni, a fejlesztőnek kell kijavítania.
Ha terminálból indítod, lehet, hogy ír még mást is. -
válasz
paolinho
#98147
üzenetére
Az mit jelent (vagyis honnan tudhatom), hogy sima szkriptfájl a fájl?
Általában a script fájloknak .sh kiterjesztésük van. De ettől még nem lesz futtatható, Linux alatt csak akkor válik valami futtathatóvá, ha futtatási jogot adsz neki. Erre való a
chmod +xparancs (vagy ha a fájlkezelődben van rá lehetőség, akkor ott).Illetve a felső kép a kicsomagolt rom maga. Akkor ott nyitok egy Terminál-t és írom be konkrétan a ./linux_fastboot_update_rom.sh parancsot?
Szerintem azon a képen az látszik, ahogy a tömörítő programban megnyitottad, hiszen ott van a "Kibontás" menüpont.
Ha ki van bontva, akkor nyitsz egy terminált abban a mappában, ahova kibontottad, és kiadod a ./linux_fastboot_update_rom.sh parancsot.Ha az sh-ra rákattintok, akkor kapom a második képet.
Akkor viszont olyan fájlkezelőd van, ami duplaklikkre nem lefuttatja, hanem megnyitja a fájlt. Ennek biztonsági okai vannak, hogy ne tudj véletlenül elindítani egy scriptet.
Ilyen jobbklikkelj a fájlra, és biztos van ott valami futtatás menüpont. -
válasz
paolinho
#98143
üzenetére
Az sh sima szkriptfájl. Futtatási jogot kell neki adni, vagy terminálból úgy, hogy
chmod +x fájlneve.sh, futtatni pedig úgy lehet, hogy./fájlneve.sh, vagy fájlkezelőben a tulajdonságainál, és utána vagy duplaklikkel indul, vagy jobb klikkes menüben van futtatás parancs.
Csak először csomagold ki valahova. -
lsusb -t nálam ezt adja az eszközömre:
Port 5: Dev 11, If 0, Class=Mass Storage, Driver=usb-storage, 480Mdmesg -w és udevadm monitor parancsok mit adnak vissza, miközben kihúzod és visszadugod? A dmesg usb-storage-ként kell, hogy mutassa, az udevadm pedig scsi block eszközként.
Egyébként ha rákeresek a modulok között, nálam is mutatja az uas-t:
# lsmod | grep -i uas
uas 36864 0 -
Nem hiszem, hogy ehhez bármilyen driver kellene. Nekem van 3 külső házam, az egyik Axagon (nem pont ez a típus, ami neked van), és egyikhez sem kellett soha semmilyen driver. Az egyik jelenleg egy RPi-re dugva üzemel, még úgy is tökéletes. Ott valami más gond lesz szerintem. Ha tudod, próbáld ki másik HDD-vel.
-
válasz
tvamos
#98120
üzenetére
Bocs, de ez a Grubos hozzáállásod hülyeség. Milyen installer okoskodik bele és milyen beállításaidba? Ha azt tapasztalod, hogy a Grub elront valamilyen beállításod, akkor valószínűleg olyan config fájlokat módosítottál, amiket nem kellett volna, mert azok a Grubhoz tartoznak, és a Grub a következő frissítésnél felül fogja írni őket.
A legjobb megoldás, hogy hagyod frissülni a Grubot. De ha valami nyomós indokod van rá, hogy ne frissüljön, akkor az apt-mark hold csomag parancssal meg tudod akadályozni, hogy frissüljön az adott csomag.
-
válasz
totron
#98037
üzenetére
Az X a maga idejében egy nagyon fejlett cucc volt, csak azóta megváltoztak az elvárások és a lehetőségek is, és az X, ahogy van, nagyon elavultnak számít már.
A multiplatformmal mi a gond? Most azon kívül, hogy nyilván minden supportált platformon le kell tesztelni, adott esetben itt-ott kicsit alakítani kell rajta...
moleculeznek is:
Üzemeltetői szempontból nyilván egyszerűbb az élet az ilyen böngészős cuccokkal, de én fejlesztői szempontból azt látom, hogy olyan problémákkal küzdenek, amiket egy normális multiplatform nyelv/keretrendszer már rég maga mögött hagyott. Gondolok pl. az erőforrásproblémákra, amikkel szinte minden komolyabb böngészős szoftver küzd. A mai gépeken persze nem annyira látványos, hogy egy DOM művelet mondjuk 0,002s helyett 0,2s alatt megy végbe. De ha azt vesszük, hogy egy asztali GUI framework ugyanazt a műveletet 20 évvel ezelőtt meg tudta csinálni 0,002s idő alatt, akkor azért na.
Meg gondolok arra, hogy a böngésző (vagy ha szerveroldalról beszélünk, akkor NodeJS), mint framework, jócskán elmarad mondjuk egy JRE vagy .NET mögött. A böngészők az elmúlt években kezdtek el olyan osztályokat nyújtani a fejlesztő számára, amik JRE-ben 20 éve ott vannak. A class mint kulcsszó, a WeakMap, WeakSet, vagy pl. a temporal, stb. Az összes olyan nyelv, ami valamikor scriptnyelvként indult, az elmúlt években elkezdett elmenni ilyen Java-s/.NET-es irányba. A JavaScript is azóta lett használható nyelv, mióta TypeScriptnek hívják
De a PHP is ezen az úton halad, szigorúbb típusosság, interface-ek, type hinting, stb.Most én is fejlesztek egy programot, egy elég egyszerű kis adatmegjelenítőt. Az egyik egyetemen fog futni, Neptunból exportált órarendi adatokat, eseménynaptárból exportált rendezvényeket, és rövidebb infókat fog megjeleníteni. Az elején vacilláltam rajta, hogy hogyan csináljam meg, legyen böngészős app, legyen Electronos, vagy natív, ha igen, akkor milyen nyelven... a Java mellett döntöttem, mert a JRE-vel egyben egy olyan frameworköt kapok, amiben rengeteg hasznos metódus van, és nem nekem kell minden egyes apróságot megírni nulláról. És mert a Java egy jó programozási nyelv, a JavaScript meg egy ócska tákolmány
-
Igen, manapság ebbe az irányba haladunk, és szerintem jó ez az irány. Régen, a '70-es/'80-as években a nagyobb intézményeknél már működött az, hogy volt egy vagy több központi szerver clusterben, futott rajta valamilyen rendszer (általában UNIX), a dolgozóknál pedig volt egy terminál gép, és a szerverre belépve dolgoztak. Ehhez képest hatalmas visszalépés az, hogy minden dolgozónál van egy teljes értékű munkaállomás, és helyben fut. És ez a DOS ill. a Windows 9x sara, mert azok csak minimális mértékben voltak felkészítve a hálózati működésre.
A másik megoldás, hogy a programot valamilyen multiplatform nyelven írják, helyben fut, de az adatokat a szerverről veszi. Csak ez megint problémásabb olyan szempontból, hogy a fejlesztőre hárul a többféle operációs rendszer supportálása (tesztelés a különféle rendszereken, stb.), míg webes cuccnál nem. És a webes cuccot könnyebb deployolni, mert pl. frissítésnél csak élesíteni kell a szerveren a friss verziót és kész, míg helyileg futó programnál ki kell tolni a user gépére a friss binárist.
-
#98020
urandom0
senior tag
tordaitibi
#97996
válasz
tordaitibi
#97996
üzenetére
Fogadom nagy összegbe hogy a 3%-ról megugrana a részesedése. Bár.. megint mindjárt megkapom hogy nem, dehogyis kell a szélesebb felhasználói tábor, neeem, ááá, szenvedjen meg érte aki akarja használni, és egyáltalán, dehogy is kell elterjednie, a hülyék maradjanak Winen.
Mintha féltenék. Mitől...?Nem félelemről van szó, de szerintem a Linux elterjedtsége csak akkor fog növekedni, ha a Windowst annyira elszarják, hogy tényleg használhatatlan lesz. Jövőre, ha véget ér a Windows 10 támogatása, valamelyest növekedni fog a Linux elterjedtsége, már most is látszódik ez a trend (a bűvös 4%).
De egyébként az a folyamat épp a snap/flatpak csomagokkal indult el, amiről te beszélsz. Egységesítés, verzióváltás (vagy nem váltás) az operációs rendszer verziójától függetlenül.... a cégek már sok éve használják, az otthoni userekhez még nem annyira csorgott le.
Az Appimage írásaddal maximálisan egyetértek.
Az nem én voltam
-
#97991
urandom0
senior tag
tordaitibi
#97988
válasz
tordaitibi
#97988
üzenetére
Lényeg, felpakolsz valamit aminek kell a libakarmi1.1, az legyalulja a libakarmi1.0 -t, és a csomagkezelő legyalulja azt a 5-10 programodat aminek a ez a függősége. Ez így brilliáns.
Ez csak akkor igaz, ha a csomagkészítőnek szándékosan ez volt a célja. Minden további nélkül fent lehet egy csomag több különböző verziója, szépen megférnek egymás mellett. Ilyen pl. a python, amiből van 3.11, 3.12, stb., és mind telepítve lehet párhuzamosan. Vagy a GTK, amiből most nekem is telepítve van libgtk-2_0-0, a libgtk-3-0 és a libgtk-4-1.
Meg lehetne csinálni azt, hogy mondjuk az Ubuntu 24.04-ben bent legyen az összes addigi Ubuntu verzió összes csomagja. A probléma az, hogy nincs, aki a régi csomagokat karba tartsa.
A Windowsban is rengeteg régi kód van, ezért is tud a korábbi verziókkal kompatibilis maradni. De ott a Microsoft megoldja házon belül, nagyon ügyelnek a visszafelé kompatibilitásra. Linuxnál ezt így nem lehet eljátszani. -
Azt ne kapcsold ki, hanem tekerj lejjebb az ablakban, a jobb alsó sarokban ott a jelszókezelő elindítása gomb. Arra klikk rá, az ablakban lesz olyan, hogy jelszó megváltoztatása. Arra klikk, és itt van a trükk: nem szabad jelszót megadni, akkor sem, ha hápog, hogy túl gyenge a jelszó. Csak okézd le az üres ablakot.
-
válasz
galaxy55
#97724
üzenetére
Az apt tudtommal egy frontend a többihez, legalábbis úgy indult.
Igen, az, az apt-get-et, az apt-cache-t és az apt-rdepends-et tudja helyettesíteni. De igazából lényegtelen, ki kinek a kicsodája, csak megjegyeztem, hogy Fedora és Suse után szokatlan, hogy ezek mind külön kis programocskák. De nincs különösebb jelentősége.
A "leglowlevelebb" része a dolognak a dpkg, ez olyan, mint rpm alapú rendszereknél maga az rpm segédprogram.
-
válasz
galaxy55
#97717
üzenetére
Nem keverem. Az apt-get, az apt-cache és az apt három különböző program. Az igaz, hogy az apt tulajdonképpen az apt-get és az apt-cache összevonásából született meg, úgyhogy végső soron kiváltja mindkettőt (az más kérdés, hogy az apt-cache kimenete alapértelmezetten egész más, sokkal bővebb, és szerintem jobban használható).
De az apt-key, az apt-add-repository, az apt-changelog, stb., mind-mind kis apró programocskák. És néha még az ember használja a dpkg-t is.Az unattended-upgrades más, mint amiről beszélek. Annak a megfelelője a dnf-automatic, zyppernél tudtommal nincs rá kész megoldás.
A zypper és a dnf azt csinálja, hogy X időnként minden csomagművelet előtt frissíti a metadatokat. Ez olyan, mint ha te mondjuk minden második órában lefuttatnál egy apt update-et. -
válasz
#63718632
#97702
üzenetére
Hogy érted, hogy interaktívabb? Nekem az apt-ben egyetlen egy dolog nem tetszik, hogy szét van szabdalva ilyen-olyan frontendekre, mint pl. az apt-cache, apt-key, apt-add-repository... dnf-nél és zyppernél ezek mind egyben vannak. Mondjuk zyppernél még mindig nincs "autoremove".
szerk: én azt is szeretem, hogy a dnf és a zypper is automatikusan updateli a metaadatokat időnként, az apt ezt sem csinálja.
-
De te sosem panaszkodtál a dnf sebességére. Tele van a net olyanokkal, hogy Why is dnf so horribly slow?, Why is dnf so slow?, Extremely slow dnf, de te mindig azt mondtad, hogy szerinted nem lassú a dnf
Szerintem még az új verzió is lassú, gyors majd akkor lesz, ha átállnak dnf5-re, az meg majd csak a 41-ben lesz. -
válasz
paolinho
#97696
üzenetére
KDE-n vagy még mindig? Esetleg nézz rá a Krusaderre, hátha beválik. Szerintem az MX repóiban ott van.
-
válasz
ubyegon2
#97692
üzenetére
Fedorához pl. nincs normális grafikus csomagkezelő. Ha Gnome-ot használ az ember, annak van a saját szoftver áruháza, meg KDE-hez a Discover (tudtommal se a Muon, se az Apper nincs már bent a repóban), de olyan, mint Debian alapú rendszerekhez a Synaptic, csak a Dnfdragora van, de szerintem azt sem használja senki sem, olyan béna. Szóval Fedora alatt nagyjából elkerülhetetlen, hogy terminálozzon az ember, ha a csomagjait akarja menedzselni.
-
válasz
galaxy55
#97694
üzenetére
i3 az egyértelműen ablakkezelő szerintem. A desktop environment inkább az, ahol van panel, vannak minialkalmazások, esetleg widgetek, külön beállító ablak, kis segédprogramok, tehát így minden egyben. A wm pedig tényleg inkább csak egy ablakkezelő, esetleg néhány plusz segédprogram hozzá.
-
A legtöbb mai gép simán bebootol NTFS fájlrendszerű EFI partícióról is, csak akkor kell a FAT-hoz ragaszkodni, ha nem indul NTFS-sel.
Az az UEFI_NTFS partíció pedig FAT (konkrétan FAT12), oda van írva... csak a kötetcímke UEFI_NTFS. Ez a Rufus egyik sajátossága, az UEFI
TFS nevű bootloader. -
válasz
paolinho
#97663
üzenetére
Ha lenyitod az Area (Terület) mezőt, ott van olyan lehetőség, hogy Rectangular Region (Téglalap alakú terület), ha azt választod ki, és rányomsz a Take a new screenshot-ra, akkor új képernyőképet fog készíteni, de úgy, hogy te adod azt a területet, amiről készüljön a kép. De van ott olyan lehetőség is, hogy csak az aktív ablakról készüljön kép, vagy a kurzor alatti ablakról, így nem is kell vagdosni semmit.
A Gwenview-s megoldás inkább akkor jó, ha nagyon pontosan akarsz körbevágni valamit, mert ott ránagyítva is ki lehet jelölni a vágandó területet.
-
Nem szokat számít szerintem (ha csak nem Gnome). Most pl. erről a gépről vagyok:
OS: openSUSE Leap 15.6 x86_64
Host: ESPRIMO P400
Kernel: 6.4.0-150600.23.17-default
Uptime: 10 hours, 36 mins
Packages: 2932 (rpm), 8 (flatpak)
Shell: bash 4.4.23
Resolution: 1920x1080
DE: Plasma 5.27.11
WM: KWin
Theme: [Plasma], Breeze [GTK2/3]
Icons: [Plasma], breeze [GTK2/3]
Terminal: konsole
CPU: Intel i5-2320 (4) @ 3.300GHz
GPU: Intel 2nd Generation Core Processor Family
Memory: 1759MiB / 7829MiBAnnyi, hogy SSD van benne a gyári HDD helyett, és KDE-vel is gyors, mint a villám.
Egy hasonló gépet használok a cégnél is, az is valami tizenpár éves HP valami. A Gnome volt a leglassabb rajta, de KDE és Xfce között én már nem vettem észre igazából különbséget, max ilyen fél másodperceket. Kb. annyi különbség van, mint egy Systemd-es disztró és egy Slackware között, nagyon minimális. -
válasz
paolinho
#97648
üzenetére
Milyen ablak jön be, ha PrtScr-t nyomsz? Nincs rajta olyan gomb, amivel téglalap alakú területet lehet kivágni?
Ilyen
vagy ilyen ablakot kell, hogy kapj, amikor nyomsz PrtScr-t.
Attól függően, mennyire vagy régi a rendszeredben a KDE. Mindenesetre akármelyik ablakot is kapod, van benne Exportálás gomb. Ha ezt megnyomod, ki tudod választani a Gwenview nevű programot, ami a KDE képnézegetője, de van benne Levágás funkció, lásd itt. Ezzel méretre tudod vágni a képet, és utána csak el kell mentened.
-
#97520
urandom0
senior tag
tordaitibi
#97518
válasz
tordaitibi
#97518
üzenetére
Megmondom őszintén, sosem szerettem ezt az ablakváltó dobozt és a csodalámpa effektet. Nekem a Plasma alap ablakváltója teljesen jó.
-
#97516
urandom0
senior tag
tordaitibi
#97511
válasz
tordaitibi
#97511
üzenetére
Írták, hogy a Linux Mint + KDE nem annyira jó barátok, így nem is akartam ráerőltetni. Mondjuk én pont azt a megoldást nem szeretem, amit te használsz.
-
válasz
ubyegon2
#97509
üzenetére
Pedig amúgy a kernelek között túl nagy eltérés szerintem nincs, legalábbis ami azt indokolná, hogy egyik disztró tök jól fut egy adott hardveren, másik disztró meg olyan bugokat csinál, hogy az ember csak les...
Na, még egy dolog így estére
Ha valamelyik virtuális konzolról indítom újra a rendszert, kapok jó pár sor, szép narancssárgás hibaüzit, meg betűk helyett négyzeteketVideó >> https://streamable.com/6sje1n
-
válasz
ubyegon2
#97507
üzenetére
Sima full HD-s monitorom van, de ha sok ablak van megnyitva, kicsit összetömöríti, hogy kiférjenek a gombok:
Azt az elrendezést, amit mutatsz, én nem szeretem. Én azt szeretem, ha lehetőleg mindig látom, hogy melyik ablakban mi fut. Minden oprendszeren az első dolgom kikapcsolni ezt az csoportosítósdit.
Fedora-n működött Cinnamonnal ez a szövegkiírás?
Nem, ott is pont ezt csinálta.
De egyébként sem szeret engem az a Mint
Most azzal szórakoztat, hogy itt, Firefoxban fel akarok tölteni egy képet, rákattintott a fájl kiválasztására, a fájlválasztó ablakban a képek mappára, és néha nem tölti be a tartalmát. Ha kilépek-visszalépek, akkor jó. Nemoban közben mindvégig jó. -
-
válasz
ubyegon2
#97499
üzenetére
Ja, valószínűleg dolgozott valamit a cache-n...
De most megint van egy nyűgöm
Mondjuk ez csak apróság, és csak nagyon ritkán jön elő. A panelen néha összeugrik egy-egy ablak gombja:
Ha bemegyek a kisalkalmazás beállításaiba, és átállítom, hogy ne legyenek ablakcímkék, és visszaállítom, akkor megint jó.
-
válasz
ubyegon2
#97475
üzenetére
A
csd-housekeepinkérlek szépen a Cinnamon Settings Daemon Housekeepin modulja, ami arra jó, hogy "Handles the thumbnail cache and keeps an eye on the space available on the disk". Én nem raktam fel semmilyen plugint, ez gyárilag jött a Minttel. Igazából alig telepítettem fel eddig csomagot, az apt logom lényegében ennyi:Commandline: apt-get remove --purge -f -q -y ubuntu-pro-client ubuntu-pro-client-l10n ubuntu-pro-auto-attach
Commandline: /usr/bin/apt upgrade
Commandline: /usr/bin/apt install sshfs
Commandline: /usr/bin/apt install openssh-server
Commandline: /usr/bin/apt install tmux
Commandline: /usr/bin/apt install ffmpeg
Commandline: /usr/bin/apt install ubuntu-restricted-extras
Commandline: /usr/bin/apt install virt-manager
Commandline: /usr/bin/apt install vlc
Commandline: /usr/bin/apt install numlockx
Commandline: /usr/bin/apt install ./rustdesk-1.2.7-x86_64.deb
Commandline: /usr/bin/apt install gpaste-2
Commandline: apt-get remove orca speech-dispatcher
Commandline: /usr/bin/apt install nala
Commandline: /usr/sbin/synaptic
Commandline: /usr/bin/apt install kdeconnect
Commandline: apt-get install --assume-yes --option Dpkg:
ptions::=--force-confnew libssl3t64 openssl python3.12 libpython3.12-minimal libpython3.12t64 python3.12-minimal libpython3.12-stdlib
Commandline: apt-get install --assume-yes --option Dpkg:ptions::=--force-confnew librados2 librbd1 dracut-install
Commandline: /usr/bin/apt install testdisk
Commandline: /usr/bin/apt install mcKisalkalmazásokból is csak azt a hármat telepítettem, de a Gnotes-t el is távolítottam.
A tegnapi eset óta amúgy nem volt gond az altatással. -
Jaja...
Megnéztem, hogy a Debian-os ttf-mscorefonts-installer honnan húzza le a fontokat. Ezek az URL vannak megadva a scriptben:https://downloads.sourceforge.net/corefonts/
https://jaist.dl.sourceforge.net/sourceforge/corefonts/
https://nchc.dl.sourceforge.net/sourceforge/corefonts/
https://ufpr.dl.sourceforge.net/sourceforge/corefonts/
https://internode.dl.sourceforge.net/sourceforge/corefonts/
https://netcologne.dl.sourceforge.net/sourceforge/corefonts/
https://vorboss.dl.sourceforge.net/sourceforge/corefonts/
https://netix.dl.sourceforge.net/sourceforge/corefonts/Ezeken belül a the fonts/final/ mappában vannak az .exe-k, amik valójában cab formátumú önkicsomagoló exe-k. A cabextract programmal ki tudod csomagolni őket, akkor megleled a .ttf fájlokat, amiket be tudsz másolgatni a megfelelő mappába. Tulajdonképpen a ttf-mscorefonts-installer is pontosan ezt csinálja.
-
A Szorszfordzs a legnagyobb nyílt forráskódú megosztó oldal volt azokban az időkben, amikor a Github még nem létezett, és mindenki SVN-t meg Mercury-t használt. Egy csomó ismert program ott kezdte a pályafutását, FileZilla, Audacity, Inkscape, stb.Egyébként ha innen letöltöd a tar.gz-t, abban csak a fontok vannak, amiket csak be kell másolni, nem kell telepíteni semmit.
-
Há 'isze itt van e:
https://mscorefonts2.sourceforge.net -
Más... a Mintem nem volt hajlandó elmenni alvó állapotba. Háromszor is megpróbáltam, egyszer sem akarta.
A logban ennyi releváns infó van:aug 02 17:38:04 Fujitsu-Mint systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.
aug 02 17:38:04 Fujitsu-Mint rtkit-daemon[1226]: Demoted 11 threads.
aug 02 17:38:04 Fujitsu-Mint rtkit-daemon[1226]: Successfully demoted thread 1525 of process 1525.
aug 02 17:38:04 Fujitsu-Mint rtkit-daemon[1226]: Successfully demoted thread 1543 of process 1525.
aug 02 17:38:04 Fujitsu-Mint rtkit-daemon[1226]: Successfully demoted thread 1540 of process 1526.
aug 02 17:38:04 Fujitsu-Mint rtkit-daemon[1226]: Successfully demoted thread 1528 of process 1528.
aug 02 17:38:04 Fujitsu-Mint rtkit-daemon[1226]: Successfully demoted thread 1541 of process 1528.
aug 02 17:38:04 Fujitsu-Mint rtkit-daemon[1226]: Successfully demoted thread 1529 of process 1529.
aug 02 17:38:04 Fujitsu-Mint rtkit-daemon[1226]: Successfully demoted thread 1544 of process 1529.
aug 02 17:38:04 Fujitsu-Mint rtkit-daemon[1226]: Successfully demoted thread 6212 of process 6111.
aug 02 17:38:04 Fujitsu-Mint rtkit-daemon[1226]: Successfully demoted thread 6526 of process 6296.
aug 02 17:38:04 Fujitsu-Mint rtkit-daemon[1226]: Successfully demoted thread 6698 of process 6416.
aug 02 17:38:04 Fujitsu-Mint rtkit-daemon[1226]: Successfully demoted thread 9155 of process 8643.
aug 02 17:38:04 Fujitsu-Mint rtkit-daemon[1226]: Demoting known real-time threads.
aug 02 17:38:04 Fujitsu-Mint systemd[1]: zfs-zed.service: Deactivated successfully.
aug 02 17:38:04 Fujitsu-Mint rtkit-daemon[1226]: The canary thread is apparently starving. Taking action.
aug 02 17:38:04 Fujitsu-Mint zed[68740]: Exiting
aug 02 17:38:04 Fujitsu-Mint kernel: PM: suspend entry (s2idle)
aug 02 17:38:04 Fujitsu-Mint kernel: PM: suspend exit
aug 02 17:38:04 Fujitsu-Mint kernel: random: crng reseeded on system resumption
aug 02 17:38:04 Fujitsu-Mint kernel: Restarting tasks ... done.
aug 02 17:38:04 Fujitsu-Mint kernel: OOM killer enabled.
aug 02 17:38:04 Fujitsu-Mint kernel: </TASK>
aug 02 17:38:04 Fujitsu-Mint kernel: R13: 00005772121bee50 R14: 00005772124392c0 R15: 00005772117de420
aug 02 17:38:04 Fujitsu-Mint kernel: R10: 00007fd0271a76f0 R11: 0000000000000246 R12: 00007ffdeabbda00
aug 02 17:38:04 Fujitsu-Mint kernel: RBP: 00007ffdeabbda90 R08: 000000000000ffff R09: 0000000000000000
aug 02 17:38:04 Fujitsu-Mint kernel: RDX: 0000000000000000 RSI: 00007ffdeabbda00 RDI: 00005772124392c0
aug 02 17:38:04 Fujitsu-Mint kernel: RAX: ffffffffffffffda RBX: 00005772121cd258 RCX: 00007fd02711bbeb
aug 02 17:38:04 Fujitsu-Mint kernel: RSP: 002b:00007ffdeabbd9f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000089
aug 02 17:38:04 Fujitsu-Mint kernel: RIP: 0033:0x7fd02711bbeb
aug 02 17:38:04 Fujitsu-Mint kernel: entry_SYSCALL_64_after_hwframe+0x78/0x80
aug 02 17:38:04 Fujitsu-Mint kernel: ? irqentry_exit+0x43/0x50
aug 02 17:38:04 Fujitsu-Mint kernel: ? do_syscall_64+0x8c/0x180
aug 02 17:38:04 Fujitsu-Mint kernel: do_syscall_64+0x7f/0x180
aug 02 17:38:04 Fujitsu-Mint kernel: x64_sys_call+0x2cd/0x25c0
aug 02 17:38:04 Fujitsu-Mint kernel: __x64_sys_statfs+0x16/0x20
aug 02 17:38:04 Fujitsu-Mint kernel: __do_sys_statfs+0x3d/0x80
aug 02 17:38:04 Fujitsu-Mint kernel: user_statfs+0x6a/0xe0
aug 02 17:38:04 Fujitsu-Mint kernel: statfs_by_dentry+0x6d/0xb0
aug 02 17:38:04 Fujitsu-Mint kernel: fuse_statfs+0xfa/0x170
aug 02 17:38:04 Fujitsu-Mint kernel: fuse_simple_request+0x18d/0x2f0
aug 02 17:38:04 Fujitsu-Mint kernel: ? __pfx_autoremove_wake_function+0x10/0x10
aug 02 17:38:04 Fujitsu-Mint kernel: request_wait_answer+0xda/0x2a0
aug 02 17:38:04 Fujitsu-Mint kernel: schedule+0x33/0x110
aug 02 17:38:04 Fujitsu-Mint kernel: ? __schedule+0x284/0x6b0
aug 02 17:38:04 Fujitsu-Mint kernel: __schedule+0x27c/0x6b0
aug 02 17:38:04 Fujitsu-Mint kernel: <TASK>
aug 02 17:38:04 Fujitsu-Mint kernel: Call Trace:
aug 02 17:38:04 Fujitsu-Mint kernel: task:csd-housekeepin state stack:0 pid:1788 tgid:1788 ppid:1552 flags:0x00004006
aug 02 17:38:04 Fujitsu-Mint kernel: Freezing user space processes failed after 20.002 seconds (1 tasks refusing to freeze, wq_busy=0):
aug 02 17:38:04 Fujitsu-Mint kernel: Freezing user space processes
aug 02 17:38:04 Fujitsu-Mint kernel: Filesystems sync: 0.022 seconds -
-
És a Lynis-t innen töltötted le?
https://cisofy.com/downloads/lynis/
3.1.1-es verzió van fent neked is?szerk: azt hiszem, megvan a hiba oka!
Letöltöttem zypperrel a repóban lévő verziót, az nekem is dobál ki ilyeneket:
De ez figyelmeztet is az elején, hogy elavult verzió:
-
válasz
CPT.Pirk
#97449
üzenetére
Én ezt a verziót használtam, ami itt a Download gomb alatt van: https://cisofy.com/downloads/lynis/
De elméletileg ez is a 3.1.1-es verzió, és a legújabb release git-en is 3.1.1
Biztos Arch alapú rendszereken alapból bekapcsol két plugint. -
Nem tudom, mert ha megnézed, itt a Leap kapott 93 pontot: Lynis security score on openSUSE Leap 15.2
Lehet, hogy csak azért, mert ez régebbi lynis verzió? Mert ott pl. csak 214 tesztet futtatott le, nálad TW alatt 258-at, az összes többinél 256-ot.
A részletes logból derülne ki igazából, hogy mi mennyit nyom a latba. -
#97440
urandom0
senior tag
tordaitibi
#97433
válasz
tordaitibi
#97433
üzenetére
dir helyett az ll-t szokták használni, ugyanaz a kimenete. szerk: bocsi, nem, nálam is csak OpenSuse-n ugyanaz a kimenet (ahol ugye a aliasolva van a dir az ls -l-re), a többi gépemen a dir kimente ugyanaz, min a sima ls-é.
Ilyenkor én nem tudom mi történne de logikusan a tiédnek kéne lefutnia nem a lsusb parancs a pathból.
És oké, pontper.
Mit ér ha úgyis eléteszem hogy ./lsusb? akkor az fut le amit tőled kaptam, nemmindegy hisz egy kis csavarral de lefuttatható a tiéd. Ami csavart ezekszerint minden felhasználó ismer.Mindegy igazából, mi fut le, az eszmefuttatásom úgyis csak elméleti. De ha úgy lenne, ahogy írtam, akkor ha beírnád, hogy lsusb, akkor az én parancsom futna le, ha pedig azt írnád, hogy ./lsusb, akkor a PATH-ban lévő.
-
-
Na igen, így már egy fokkal érhetőbb az a 94-95-ös pontszám, amit Redditen mutogatnak. Ha a TW alapból 88-at hoz, azt már nem olyan nehéz feltornázni.
Mondjuk azt nem teljesen értem, miért ekkora a különbség a közte, és a Leap között. Talán csak annyi, hogy TW-ben frissebb a kernel? -
#97431
urandom0
senior tag
tordaitibi
#97426
válasz
tordaitibi
#97426
üzenetére
dir az micsoda? Valami szőlőbetegség? Az én rendszereim csak ls-t ismernek
Fogd fel úgy ezt a ./ dolgot, mint valami biztonsági intézkedést. Ha én küldök neked egy tar.gz-t, amiben van egy dir nevű futtatható fájl, te kicsomagolod, terminálban belépsz a mappájába, és gyanútlanul kiadod a dir parancsot, akkor ha nem kellene elé pontpert írni, akkor az általam küldött dir futna le. És ha én történetesen egy velejéig romlott ember volnék, és olyan dir programot küldenék neked, ami törli mind a kétezer partíciódat, akkor jól megszívnád. Ezért jó, hogy pontpert kell írni elé.
-
#97425
urandom0
senior tag
tordaitibi
#97421
válasz
tordaitibi
#97421
üzenetére
Én csak simán letöltöttem innen a tar.gz-t: https://cisofy.com/downloads/lynis/
Kicsomagoltam, aztán terminálban./lynis audit system
Annyi, hogy első futtatásnál szólt, hogy a root tulajdonában kell lennie a fájloknak, úgyhogy átadtam mindent a rootnak (find * -exec chown root:root {} \;), de ha eleve rootként töltöd le, talán az is jó lesz. -
Az igen, én két nappal ezelőtt találtam meg ugyanezt
A céges OpenSuse-n 68 pontom lett, aztán néhány opciót átállítottam az sshd_configban úgy, ahogy ő javasolta, így 73 pontom lett.
A frissen telepített Minten 61 pont lett, a laptopomon lévő OpenSuse-n 70.
Redditen olvastam, hogy egyesek ilyen 94-95 pontot értek el, és hogy az sem mindegy, hogy fizikai vason vagy virtuális gépben futtatod, mert úgy kevesebb pontod lesz.
Olyan apróságokat is néz, hogy pl. mi az /etc/issue tartalma, meg hogy be van-e állítva az ntpd...
-
válasz
galaxy55
#97393
üzenetére
Ezt akartam írni én is. Az OpenSuse-s gépemen még Plasma 5 van, a Fedoráson Plasma 6, de különösebben nagy újdonságot nem vettem észre a 6-ban. Mondjuk ez nem is baj, inkább fejlődjön lassan és legyen minél stabilabb, mint hogy egyszerre jöjjön egy nagy adag új funkció, meg kétezer bug.
Szerintem igazából csak a Qt5 -> Qt6 váltás indokolta az új Plasma verziót.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
edora_Linux_release_timeline
TFS nevű bootloader
ptions::=--force-confnew libssl3t64 openssl python3.12 libpython3.12-minimal libpython3.12t64 python3.12-minimal libpython3.12-stdlib
Új hozzászólás Aktív témák
A topik célja: Segítségnyújtás a Linux disztribúciókkal még csak ismerkedők számára. A szerveres kérdések nem ebbe a topicba tartoznak.
Kérdés előtt olvasd el a topik összefoglalóját!
Haladó Linuxos kérdések topikja.
Linux felhasználók OFF topikja
Milyen program ami... [link]
Shell script kérdésekkel látogassatok el a topikjába
- Teszt Már csak két hónap van hátra a Windows 10 nyugdíjazásáig, ideje előrelépni
- Teszt [Linux] Vanilla OS, egy Debian alapú immutable operációs rendszer
- Teszt [Linux] Aeon Desktop, egy immutable operációs rendszer az OpenSUSE-tól
- Teszt [Linux] A Flatpak
- Bejegyzés MS Office365 Linuxon
- Bejegyzés [Linux] Futtassunk bármely disztrót a terminálunkban
- Bejegyzés Alpine Linux telepítés mindenféle low-end dologra
- Hír Zöld utat adott a nyílt forráskódú Linux meghajtóknak az NVIDIA
- Kerékpárosok, bringások ide!
- Hivatalos a OnePlus 13 startdátuma
- Battlefield 6
- Autós topik
- Mibe tegyem a megtakarításaimat?
- Budapest és környéke adok-veszek-beszélgetek
- Fotók, videók mobillal
- Xiaomi 15T - reakció nélkül nincs egyensúly
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Kormányok / autós szimulátorok topikja
- További aktív témák...
- Bomba ár! Lenovo ThinkPad L520 - i3-2GEN I 4GB I 160GB I DVDRW I 15,6" HD I Cam I W10 I Garancia!
- HIBÁTLAN iPhone XR 128GB Black -1 ÉV GARANCIA - Kártyafüggetlen, MS3267, 96% Akkumulátor
- DXRACER Prince L gamer szék
- Bomba ár! Dell Latitude 5495 - Ryzen 5 I 8GB I 256SSD I 14" FHD I HDMI I Radeon I Cam I W10 I Gari
- REFURBISHED - Lenovo ThinkPad 40AF Dock (DisplayLink)
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: NetGo.hu Kft.
Város: Gödöllő