-
Fototrend
Linux kezdőknek - érdemes beleolvasni, mielőtt kérdezel
Új hozzászólás Aktív témák
-
válasz
webzyus
#101157
üzenetére
Az ikonok szerintem a rendszer saját ikonjai. A langpack és a locale külön csomag szokott lenni (thunderbird-locale-* néven), azt is távolítsd el. Felülről a második szerintem az Orca saját mappája. Egyedül a /lib gyanús, abban lehetnek ilyen maradvány fájlok, de nem értem, a Thunderbird mit matat ott.
-
válasz
Petya XT
#101101
üzenetére
Sok helyen olvastam, hogy olyan mintha nem is lenne, nem sokat ér a router tűzfala.
El tudom képzelni, hogy ilyen is van, de azért egy normálisabb, márkásabb routere tűzfala szerintem nem ilyen. Oké, ha nem frissül, az más kérdés, akkor valóban gáz lehet (de még akkor sem biztos).
Mondjuk én OpenWRT-s routereket használok, ebből indulok ki. Ezek mellé halál felesleges tűzfal a gépre, főleg úgy, hogy szinte semmi sem hallgatózik. -
-
-
válasz
fatpingvin
#100967
üzenetére
Compton helyett a Picomt ajánlják újabban.
-
válasz
csixy
#100940
üzenetére
Hát, én most végignéztem mindkét programot, még a beállításaik is tökéletesen azonosak. Kb. mintha frissen forkolták volna a gThumbot. Amúgy Tumbleweed alatt repóból telepíthető a Pix is, és a gThumb pedig elérhető Flathubról. És mindkét program telepíthető distrobox konténerbe, ha kellene valakinek, én is onnan futtatom a Pixet.
-
-
válasz
tordaitibi
#100928
üzenetére
Legnagyobb meglepetésem egy snap app volt amiről kiderült hogy tulajdonképpen Wines exe.
Nem az Irfanview-ra gondolsz? Az is ilyen.
-
válasz
szbalogh
#100914
üzenetére
A Samba a legszívatósabb rész az egész Linuxos világban. Olyat én még nem láttam, hogy ami nálam működött, az másnál is működött volna, vagy fordítva.
Az /etc/samba/smb.conf-ot kell szerkeszteni (rootként), és valami ilyesmit kell összeraknod benne:[myshare]
path = /path/to/share
writeable = yes
browseable = yes
guest ok = yes
read only = no
public = yes
create mask = 0644
directory mask = 0755Ahol myshare a megosztás neve, path pedig a megosztott mappa elérés útja (ennek a jogosultsága legyen 777). Utána indítsd újra a szolgáltatást:
systemctl restart smb nmb
vagysystemctl restart smbd nmbdDisztrófüggő, hogy hogyan hívják a Samba szolgáltatásait. Ubuntunál azt hiszem smbd és nmbd lesz.
Ha esetleg nem működik (szinte biztos, hogy nem fog), akkor az smb.conf [global] szekciójába írd be ezt:
map to guest = Bad User
guest account = nobodyA [myshare] szekciójába pedig ezt:
force user = nobodyÉs vedd ki a guest ok = yes sort. Utána megint indítsd újra a szolgáltatásokat, és próbáld ki, működik-e (megeszem a kalapom, ha működni fog
)...Én évek nem használok Sambát, ssh-n keresztül érek el mindent. Sokkal egyszerűbb, a hátránya annyi, hogy Windows alól csak plusz programmal tudod használni, és sajnos elég lassú.
Távoli asztal helyett helyi hálózaton NoMachine-t használok, távoli hálózaton RustDesket. -
-
válasz
Petya XT
#100873
üzenetére
EFI-s géphez mindig érdemes GPT-re formázni mindent, BIOS-os géphez pedig MBR-re. Ezzel én is megszívtam már, volt, hogy sikerült úgy klónoznom egy EFI-s gépben lévő HDD-t, hogy a másik gépen legacy boot volt beállítva. Nem is nagyon akart elindulni a Windows... aztán valahogy helyretettem, és kb. 2 hét múlva jöttem rá, mekkora hülyeséget csináltam

EFI-s gépben legacy (BIOS) bootos Windows GPT-s partíciókiosztással úgy, hogy ott az EFI partíció (teljesen feleslegesen), miközben valójában MBR-es volt a lemez...És igazából csak azt rontottam el, hogy MBR-re volt formázva az a HDD, amire klónoztam, ha GPT lett volna, semmi gond nem lett volna.
-
válasz
Rowon
#100871
üzenetére
Én általában azt használom, ami azon a gépen van, ami előtt épp ülök

Windows ISO-t nem is tudom, mikor írtam ki utoljára itthon, talán évekkel ezelőtt. Azt tudom, hogy általában WoeUSB-vel szoktam csinálni.
Céges gépen szoktam Windows-t kiírni, ott Rufus van, és speciálisan összeállított Windows ISO-t használunk.
Céges Linuxos gépemen pedig általában dd-t vagy Impressiont használok. Ha Impression-ben benne van az a disztró, amit ki akarok írni, akkor inkább azt választom.De ha gépet javítani megyek, akkor Ventoyyal szoktam kiírni egy Windows ISO-t, egy Hiren's Boot CD-t, egy memtest-et, és régebbi gépekhez egy Bunsenlabs-ot, újabbakhoz pedig egy OpenSuse-t.
-
Fájlok neve előtt a ~ a home mappádat jelenti. Nem tudom, mi a felhasználóneved a gépeden, de ha pl. kisi, akkor a home mappád a /home/kisi lesz, így a ~ is erre fog mutatni.
A .-tal kezdődő fájlnevek pedig rejtett fájlok, be kell kapcsolnod a fájlkezelődben a rejtett fájlok mutatását, különben nem fogod látni őket.Shelltől és disztrótól is függ, hogy a leírásban szereplő fájlok közül melyik létezik nálad, lehet, hogy egyik sem. Én világ életben a ~/.bashrc-be szoktam rakni az ilyen dolgokat, de használhatod a ~/.profile-t is, az elég egységes (de ezt az interactive shell nem olvassa be, csak a login shell).
Ezeken kívül egyébként létezik még ~/.bash_profile és ~/.bash_login is, bár ezek elég ritkák manapság. -
válasz
Petya XT
#100862
üzenetére
A Windows képfájlokat szoktam csak Ventoyal készíteni, mert az valamiért nem jön össze soha vele.
A Windows ISO-k elég speciálisak, azokat se dd-vel, se Gnome Diskssel, se hasonló programokkal nem lehet csinálni. Ventoyyal, Etcherrel és WoeUSB-vel ki lehet írni őket, de ha EFI-s gépről van szó, akkor csak simán rá kell másolni a pendrive-ra az ISO tartalmát és kész: https://logout.hu/bejegyzes/doky586_windows_telepito_pendrive_elkeszitese_linux_alol.html
-
-
Szerintem a .net visszafelé van annyira kompatibilis, hogy a 7-es verzió helyettesíthető a 8-as verzióval. Próbáld meg telepíteni a 8-ast, és azzal elindítani a játékot.
Ha máshogy nem megy, próbáld meg a flatpak csomagot: https://flathub.org/apps/at.vintagestory.VintageStoryKipróbáltam, nálam megy.
-
válasz
Rowon
#100836
üzenetére
Van, amire én is a Gnome Disks-et használom, de azokat az opciókat beírni fstabba, amiket fejből tudok, semmivel sem tart tovább, mint elindítani a Disks-et, és oda beírni

Új meghajtó esetén az esetek többségében annyi a teendő, hogy /etc/mtab-ból az azt egy sort bemásolni fstabba. -
válasz
Petya XT
#100833
üzenetére
Gondolom úgy érti, hogy saját felhasználóval, sudo-val formázta a meghajtót.
Én egyébként minden ilyesmit úgy csinálok, hogy a csatolási pontot a user tulajdonába veszem, illetve az allow_other és az rw opciókat be szoktam írni a csatolási az fstabba, ha nincs bent. Bár én NTFS-t nem használok.
-
-
válasz
Rowon
#100779
üzenetére
Az sdbootutil nem olyan program

Ezzel a systemd-boot bejegyzéseit lehet menedzselni: https://github.com/openSUSE/sdbootutilCsak arra vagyok kíváncsi, hogy más disztrók is használják-e, vagy teljesen Suse-only.
Horvi: köszi!
-
Az sdbootutil kinél van még telepítve alapból? Archosok, Mintesek, Fedorások...?
-
-
-
Az enyémben "Network controller: Intel Corporation Wireless 7260 (rev 83)" van, ezzel még sosem volt gondom.
-
-
-
-
-
válasz
Rowon
#100668
üzenetére
Én értelmét se nagyon látom ezeket törölgetni. Most ha van egy több éves levelezésed, az indexfájlok akkor is csak ilyen pár száz MB-ot tesznek ki, de ha kitörlöd őket, akkor a Thunderbird indexelheti újra a leveleid, és amíg ez nem történik meg, addig a keresés szét fog esni (nem talál meg leveleket, fals találatokat dob ki, stb.).
És nincs is rendesen megmagyarázva, hogy mik azok az index fájlok, csak annyi van odaírva, hogy "Index: Fájlok törlése".
Szóval oda kell figyelni, ha az ember használni akarja. -
Én nem használok ilyen programot. Nem rosszak amúgy, de tényleg meg kell nézni, hogy mit pipál be az ember. A Bleachbit pl. képes a Thunderbirdben tárolj jelszavakat és index fájlokat kitörölni, szerintem ez inkább káros, mint hasznos.
Ilyen programok leginkább arra jók, hogy pár MB helyet visszanyerjen velük az ember.
-
válasz
Kacsasült
#100641
üzenetére
Milyen csomagok azok, milyen programokhoz tartoznak? Ha te telepítetted őket, akkor biztosan tudod, hogy mik azok, és el tudod dönteni, hogy szükséged van-e rájuk.
Nagyon ritkán előfordulhat olyan, hogy letöltesz egy telepítőt scriptet, és az wget-tel lehúz egy csomagot, feltelepíti, és utána telepíti fel magát. De ilyen én eddig összesen egy vagy kettő ilyen csomaggal találkoztam.
-
válasz
Kacsasült
#100629
üzenetére
Terminálban én így szoktam:
du -h ~ | sort -hEz csak a /home alatt lévő mappákat listázza ki.
Ha a teljes fájlrendszer kell, akkor így:
sudo du -h / | sort -hAztán ha azt látod, hogy valamelyik mappa túl nagy méretű, akkor belépsz abba a mappába, aztán ott megint kiadod a
du -h | sort -hparancsot. -
válasz
Petya XT
#100622
üzenetére
Szerintem 8821 lesz.
Olyan is előfordul időnként, hogy chipet váltanak, az egyik szériába még 8821 van, a másikban már valami más, pl. 8852.
Meg ezek nagyon legacy cuccok, ha megnézitek az install.sh-t abban a Github repóban, amit Kacsasült linkelt, 2010-es dátum van benne. Azért az se tegnap volt
Szerintem 6-os kernelhez nem is készült driver, csak 4-es/5-höz. -
-
-
válasz
funkmester
#100599
üzenetére
Másik könyvtár: cd ~/valami
Mondjuk cd ~/LetöltésekRoot:
sudo git clone https://github.com/brektrou/rtl8821CU.git -
-
-
-
válasz
growler
#100523
üzenetére
Nálunk olyan volt, hogy a feleségem heteken keresztül nem tudott elérni egy olyan oldalt, ami a munkahelyéről simán ment. Digisek vagyunk, úgyhogy írtunk a Diginek, nézzenek már rá, hátha náluk van a hiba.
Egy órán belül visszaírtak, hogy náluk minden oké, nincs semmilyen korlátozás, semmi... ránéztünk az oldalra, valami furcsa oknál fogva akkor már működött
-
Chromium, Ungoogled Chromium, Opera, Brave, Vivaldi, van egy rakat böngésző a Firefoxon kívül is, lehet válogatni
-
válasz
Petya XT
#100436
üzenetére
Nem értem ezt a hirtelen szigort
Ezt úgy hívják, hogy biztonságtudatosság

Most vesd össze ezt azzal, amikor átlagpistike meglátja torrenten, hogy Photoshop.CC.2024.cracked.ISO, és már tölti is le, tökéletesen les*arva, hogy mi van benne vagy mit csinál. És akkor csodálkozik, hogy másnap 25 kriptovírus, 7 adware meg 2 trójai van a gépén
Ehhez képest mi meg azon aggodalmaskodunk, hogy verified vagy unverified...
-
válasz
Petya XT
#100431
üzenetére
De AUR-nél elérhető a PKGBUILD fájl, és abban szépen látszik, hogy a hivatalos .deb csomagból építkezik:
source=("$pkgname-$pkgver.deb::https://download.cdn.viber.com/cdn/desktop/Linux/viber.deb")Sőt, még az is látszik, hogy Nagy Sándor az AUR csomag maintainere

# Maintainer: Sandor Nagy <sandor[dot]nagy[at]kdemail[dot]net>
-
válasz
Petya XT
#100426
üzenetére
Ezt ki ellenőrzi? Minték, vagya Flatpak gárda?Bár akkor feltételezem, hogy a Mint csapat.Nem, a Flathub: https://docs.flathub.org/docs/for-app-authors/verification
Ha megnézed a Viber Flathub oldalát, ott írják is, hogy unverified: https://flathub.org/apps/com.viber.Viber -
-
válasz
Petya XT
#100419
üzenetére
Az új Mintnél bizonyos Flatpak csomagok alapértelemzetten tiltva vannak, biztonsági okokból.
Ez nem rossz ötlet egyébként, jó lenne, ha ezt a verified/unverified dolgot beépítenék az alap Flatpakba, hogy jelezze, ha nem hitelesíthető a csomag kiadója.
Viberből van appimage is, azt a fejlesztő adta közre, én azt próbálnám meg a helyedben.Olyan flatpak csomagot én sem szívesen telepítek, aminek a kiadója nem ugyanaz, mint a fejlesztője.
-
-
válasz
Warton
#100404
üzenetére
Ezért kérdeztem én is

Mindhárom fent van Flathubon, és mindhárom az eredeti fejlesztőtől:
https://flathub.org/apps/com.brave.Browser
https://flathub.org/apps/org.onlyoffice.desktopeditors
https://flathub.org/apps/org.js.nuclear.Nuclear -
-
-
válasz
tordaitibi
#100370
üzenetére
Szívesen.
Ha érdekel valakit, a flatpakról is írtam egy elég hosszú blogbejegyzést, itten van e: https://logout.hu/cikk/linux_a_flatpak/nevtelen_oldal.html
-
válasz
sonar
#100368
üzenetére
FreeCAD-ből van flatpak csomag, szerintem használd azt, ha a flatpak telepítve van nálad. Ha nincs telepítve, de van telepítve snap, akkor használd a snap változatot. Végső esetben az appimage is jó lehet.
A Kicad meg mehet ppa-ból.Én a flatpakot preferálom, egyrészt mert olyan disztrókat használok, ahol a snap nem használatos, másrészt mert a snap a Canonical saját kisvállalkozása, a flatpak pedig univerzális, és teljesen nyílt forráskódú (a snap nem teljesen az). Nameg a flatpak programok gyorsabban indulnak.
-
válasz
Warton
#100366
üzenetére
Snap ügyében nem tudok nyilatkozni, azt annyira nem ismerem.
Flatpak esetén vannak az ún. runtime-ok, ezekben van a programok függőségeinek nagy része. A képeden az összes, ami úgy kezdődik hogy org.freedesktop, az mind egy-egy Freedesktop runtime.
Ha kiadod a flatpak list --columns=app,size parancsot, akkor látni fogod, hogy igazából ezek a nagy méretűek, nem maguk az alkalmazások, mert ezekben vannak a függőségeik. -
válasz
Warton
#100364
üzenetére
Nézegetve a listát így se értem miért flatpak a mesa, illetve miért kellenek a gnome csomagok egy Kubuntura?
A te listádon nem látok Gnome-os flatpakot (csak a GTK3 Breeze-t, de az csak egy téma), csak snapot. Az meg azért kell, mert valamelyik snapos programodnak van Gnome függősége. Azt nem tudom, hogy melyiknek, biztos meg lehet valahogy nézni.
Az én listám meg nem Kubuntun készült.
-
válasz
Warton
#100362
üzenetére
Caprine mennyire működik nálad? Én próbáltam, de áhh, problémásabb volt, mint böngészőből chatelni. Ferdiumot is próbáltam, az se volt sokkal jobb.
Neked nincs is sok flatpak programod

https://streamable.com/0d7qyt -
válasz
tordaitibi
#100358
üzenetére
A konténeres megoldás, amit írtam, az nem flatpak ám. A flatpak teljesen más.
-
válasz
tordaitibi
#100357
üzenetére
Az a python csak egy symlink a python2-re, nem? Ha nagyon kísérletezős kedvemben lennék, én lehet, hogy megpróbálnám kitörölni a python-t (ha tényleg csak egy symlink), és csinálni a helyére ugyanúgy python névvel egy másik symlinket, ami a python3-ra mutat. Csak kíváncsiságból, hogy ekkor mi történne.
Lehet, hogy akkor meg azok a programok nem indulnának el, amiknek python2 kell
-
válasz
tordaitibi
#100354
üzenetére
Gondolom, a csomag készítője arra számított, hogy aki telepíti, annál van Python 3, vagy snapból, vagy úgy, hogy lefordítja magának.
Ha a többi program megy a yt-dlp-vel meg a snapos Pythonnal, akkor szerintem a Media-downloader is menne vele. Bár nálad, a lejárt szavatosságú Ubuntun, két Wine, három snap és nyolc flatpak között,, tonnányi appimage tengerében (és mindez 3 SSD-n és 4 HDD-n) sosem lehet tudni, hogy mi megy és mi nem

Bár ha te tudod, az már bőven elég. -
válasz
sh4d0w
#100347
üzenetére
Igen.
Tulajdonképpen a Wine közelebb áll a VM-hez, mint a konténer, mert a Wine a Windows-os hívásokat fordítja le Linuxosakra. Konténer esetén meg ugye nincs ilyen fordítás, ott natívan fut minden (csak izolált környezetben), közel a host rendszer sebességével megegyezően. -
válasz
sh4d0w
#100342
üzenetére
A Wine tök jó, amikor Windows-os programokat kell futtatni. De Tibi barátunk elég speciális eset, nála van Wine is, Snap is, meg lejárt szavatosságú Ubuntu, és folyamatosan szív miattuk. Ide a Wine már nem elég

Itt írtam a Distroboxról, ha érdekel esetleg valakit: https://logout.hu/bejegyzes/linux_futtassunk_barmely_disztrot_a_terminalunkban.html
-
-
válasz
Warton
#100339
üzenetére
A konténer nem virtuális gép

Amúgy Tibinek nem csak emiatt az egy program miatt kellhet a konténer, sokszor belefut abba, hogy ez meg az nem megy nála, főleg az ilyen Pythonos cuccok. Ezzel a konténerezősdivel ezt meg tudja oldani.Szerintem a Wine sokkal gázabb, az egy fél Windowst magával hoz, és sokszor vannak benne kisebb-nagyobb hibák. Meg azért na, nehogymár egy elméletileg platformfüggetlen programhoz Wine kelljen.
-
-
válasz
tordaitibi
#100331
üzenetére
Jó, itt van még egy megoldás, nézzük meg ezt.
1. Első körben kell hozzá a distrobox, ezt innen tudod leszedni:
https://snapcraft.io/distroboxHa valamiért nem menne, próbáld meg ezt is Githubról ezzel a paranccsal:
curl -s https://raw.githubusercontent.com/89luca89/distrobox/main/install | sudo sh2. Utána Készítünk egy distrobox konténert: distrobox create --name ubuntu --image ubuntu --yes
3. Belépünk a konténerbe (az "Installing basic packages..." résznél egy darabig elszüttyög majd):
distrobox enter ubuntu4. Telepítjük a python-t, a pip-et és a git-et: sudo apt update && sudo apt install python3-full python3-pip git
Ez sok csomagot le fog tölteni (~572MB), de ne foglalkozz vele.5. Lehúzzuk a programot, megcsináljuk neki a virtual environmentet, leszedjük a függőségeit és elindítjuk:
git clone https://github.com/oop7/YTSage.git
cd YTSage
python3 -m venv env
env/bin/pip3 install -r requirements.txt
env/bin/python3 YTSage.pyHa nem megy, másold be a hibaüzenetet, és megnézzük. mi lehet a baj.
A Distrobox-szal konténerbe lehet telepíteni szinte bármelyik disztrót. Ha a fenti módszert megcsináltad, lesz egy konténerizált 24.04.1-es Ubuntud, amibe a distrobox enter ubuntu paranccsal tudsz belépni. Elméletileg egy parancsikont is csinált magának.
Nagyon jó cucc ez a Distrobox, én is használom. Ezen a képen három disztrót futtatok egyszerre három konténerben, egy Debiant, egy Archot és egy Fedorát: [kép]
Mindháromban az Inkscape-et telepítettem, és ilyenkor amikor mindhárom fut: [kép]
Az egyik 1.4-es az Arch konténerből futott, a másik a Fedorából, az 1.2-es pedig a Debianból. Itt látszik, hogy telepítve volt mind a három, és még egy Tumbleweed is: [kép] -
válasz
urandom0
#100328
üzenetére
Egyébként ez a függőségesdi mindenhol probléma, nem csak a Linuxnál. Alább írták, én is tapasztaltam, hogy pl. Python esetében is hamar elévülnek a függőségek. De beszélhetünk szinte bármelyik másik rendszerről is, nekem pl. van olyan PHP-s projektem, amit 2020-ban írtam, de ma már nem tudnám telepíteni (ha csak neki nem állnék updatelni), mert a frameworknek az a verziója, amit használtam, már nem támogatott és nem is érhető el. De NodeJS-nél is belefutottam ugyanebbe, nem is egyszer. Az left-pad incidenst pedig már nem is említem, azt mindenki ismeri...
-
válasz
tordaitibi
#100320
üzenetére
Ez számomra azért érdekes mert ugye portable, elvileg benne vannak a neki szükséges kellékek.
Nincsenek. Itt egy lista azokról a libekről, amiket appimage-be nem raknak bele: https://github.com/AppImageCommunity/pkg2appimage/blob/master/excludelist
Windows-on mindig nagyon ügyeltek a visszafelé kompatibilitásra, Linuxon ezt nem lehet elérni, mert nem írhatod elő az egyes fejlesztőknek, hogy csak akkor fogadod be a programjukat, ha 100%-ban nyújtják a visszafelé kompatibilitást. Ráadásul sok csomag már ki is került a disztróból, azzal sem lehet mit kezdeni, ha egyszer nincs hozzá maintainer.
Eleve a Linux kernel, mivel monolitikus, sokkal több minden van benne, mint az NT kernelben, így sokkal változékonyabb is. A Windows kernel és a rendszerintű részek nem változtak komolyabban a Vista óta, amikor bekerült az új grafikus alrendszer. A Linux meg pár évente init rendszert vált, pár évente audió rendszert vált, pár évente grafikus rendszert vált...
A Windows pl. 2 vagy 3 fájlrendszert támogat összesen, és ebben nem volt változás az 1990-es évek eleje óta (annyi volt, hogy a HPFS támogatás kikerült a rendszerből). A Linux meg annyit támogat kernel szinten, hogy felsorolni is nehéz. Ecryptfx, ext2, ext3, ext4, XFS, JFS, ReiserFS, FAT, ExFAT, Bcachefs, Minix, UFS, stb. És időnként bekerül egy-egy újabb fájlrendszer támogatás, egy másik kikerül... szóval a Linux nagyon evolválódik, és ilyen körülmények között borzasztó nehéz hosszútávon megtartani a visszafelé kompatibilitást. -
-
válasz
sh4d0w
#100316
üzenetére
Normális nyelveknél létezik verziószámozás, ill. fully qualified namekkel vannak megadva a függőségek. Nézd meg pl. Go-nál:
require github.com/diamondburned/gotk4/pkg v0.3.1Vagy pl. NodeJS-nél:
"dependencies": {
"express": "^4.16.4",
"compression": "~1.7.4"
},És innentől fogva nincs kérdés, mert mindenki megtalálja a saját függőségeit. A nagyobb projektek akár be is húzhatják saját névtér alá a függőségeiket, és akkor nem fog törlődni semmi, aminek nem szabadna.
Sőt, a NodeJS alapértelmezetten lokálisan telepíti őket egy alkönyvtárba, külön kérni kell, ha globálisan akarod telepíteni.
Ezzel szemben Pythonnál ez van:PyQt6
yt-dlp
requests
PillowÉs ráadásul a hagyományos viselkedés az, hogy a pip globálisan telepíti a függőségeket, és nincs se verziószámozás, se semmi. Így persze, hogy össze-vissza keverednek.
-
válasz
sh4d0w
#100312
üzenetére
De akkor legyen szíves a pip csinálni egy virtual envet saját magától. Ne hibaüzeneteket dobálgasson.
Vagy ha már ott van a pipx, ami mindezt megcsinálja, akkor legyen szíves kezelni azinstall -r requirements.textjellegű dolgokat.
Vagy legalább a kedves fejlesztő legyen szíves használható telepítési utasításokat adni. -
válasz
Warton
#100307
üzenetére
Amúgy nem jók a telepítési utasítások, amik ott le vannak írva. Egyrészt
git clone https://github.com/yourusername/YTSage.git
helyettgit clone https://github.com/oop7/YTSage.git
a helyes.
Másrészt a függőségek telepítésénél vinnyogni fog, hogy ő nem hajlandó globálisan települni, csak virtual env-be. Mert ő ilyen kis hisztis.Törném el a kezét annak, aki Python használ bármire is...
-
válasz
Petya XT
#100290
üzenetére
Hát ha az kérdés, hogy abszolút ne tudjon semelyik rendszer sem írni arra a lemezre, akkor az ellen nem fog megvédeni gyakorlatilag semmi. Egy titkosított lemezt is simán felülírok dd-vel, de Windows alól a diskparttal vagy a lemezkezelővel is el tudok intézni egy bármilyen fájlrendszerű lemezt.
-
válasz
Crvsh3R
#100289
üzenetére
Azok szimbolikus linkek a kernelre és az initial ram diskre. Ha megnézed, hogy hova mutatnak, valami ilyesmit fogsz látni:
/vmlinuz -> boot/vmlinuz-x.x.x-amd64
/initrd.img -> boot/initrd.img-x.x.x-amd64Ha kitörlöd őket, nem biztos, hogy be fog bootolni a gépet következő indításkor

-
-
-
válasz
ubyegon2
#100275
üzenetére
A múltkor a könyvelőprogramos kolléga is 14-ről vagy 16-ról akart frissíteni 24-re, én akkor utánajártam, többen is írták, hogy lehetséges egy lépésben is, csak nem ajánlott. A doksi is azt írja, hogy nem ajánlott. Én ilyet még nem csináltam, úgyhogy sem megerősíteni, sem cáfolni nem tudom

Nálunk, a cégnél olyan volt, hogy előző kolléga Ubuntu-t használt szervernek, és úgy gondolta, jó ötlet Debiant csinálni belőle úgy, hogy átírja a repókat és dist-upgrade-el. Na, ott lett olyan káosz, hogy sokáig azt sem tudtam, hogy ami előttem van, az most Debian vagy Ubuntu. Kb. 12 órám ment rá, mire helyreraktam, sok csomagot kézzel töltöttem le wgettel, és a függőségek kihagyásával telepítettem, ugyanúgy sokat el is távolítottam. Aztán ezt az egész őskáoszt visszaalakítottam Ubuntuvá, és úgy frissítgettem fel lépésenként a legfrissebb verzióra, mert amúgy Ubuntuból és Debianból is több éve lejárt verzió volt. Mai napig üzemel ez a szerver, és nincsenek már rajta Debian csomagok.
-
-
válasz
Petya XT
#100263
üzenetére
Bármit, ami hibára utalhat. Nem tudom megmondani, mert nagyon kernel- és disztrófüggő.
Nálam OpenSuse alatt ez van a logokban, amikor elmegy aludni és visszatér:nov 28 21:07:38 localhost.localdomain kernel: Freezing remaining freezable tasks completed (elapsed 0.001 seconds)nov 28 21:07:38 localhost.localdomain kernel: Freezing remaining freezable tasksnov 28 21:07:38 localhost.localdomain kernel: OOM killer disabled.nov 28 21:07:38 localhost.localdomain kernel: Freezing user space processes completed (elapsed 0.002 seconds)nov 28 21:07:38 localhost.localdomain kernel: Freezing user space processesnov 28 21:07:38 localhost.localdomain kernel: Filesystems sync: 0.125 secondsnov 28 20:29:31 localhost.localdomain kernel: PM: suspend entry (deep)nov 28 20:29:31 localhost.localdomain systemd-sleep[62922]: Performing sleep operation 'suspend'...nov 28 20:29:31 localhost.localdomain systemd-sleep[62922]: This is a temporary downstream workaround for https://github.com/systemd/>nov 28 20:29:31 localhost.localdomain systemd-sleep[62922]: relying on kernel to perform the freeze.nov 28 20:29:31 localhost.localdomain systemd-sleep[62922]: User sessions remain unfrozen (add $SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=1 >nov 28 20:29:31 localhost.localdomain systemd[1]: Starting System Suspend...Fedora alatt pedig ez:
nov 27 21:07:16 fedora kernel: Freezing remaining freezable tasks completed (elapsed 0.001 seconds)nov 27 21:07:16 fedora kernel: Freezing remaining freezable tasksnov 27 21:07:16 fedora kernel: OOM killer disabled.nov 27 21:07:16 fedora kernel: Freezing user space processes completed (elapsed 0.001 seconds)nov 27 21:07:16 fedora kernel: Freezing user space processesnov 27 19:48:49 fedora kernel: Filesystems sync: 0.073 secondsnov 27 19:48:49 fedora kernel: PM: suspend entry (deep)nov 27 19:48:49 fedora systemd-sleep[10848]: Performing sleep operation 'suspend'...nov 27 19:48:49 fedora systemd-sleep[10848]: Successfully froze unit 'user.slice'.nov 27 19:48:49 fedora systemd[1]: Starting systemd-suspend.service - System Suspend...nov 27 19:48:49 fedora systemd[1]: Reached target sleep.target - Sleep.Ezekben nincs hiba. De ha hibát látsz, akkor általában más színnel írja ki, vagy úgy keződik, hogy WARNING, vagy Failed, vagy ilyesmi.
Esetleg meg lehet próbálni ajournalctl -p errparanccsal megnézni, nincs-e a suspend időpontja körül valami hiba. -
válasz
Remus389
#100262
üzenetére
A fast startup is okoz problémákat egyes gépeken, ill. egyes programok nem is működnek addig, amíg ki nem kapcsolod. A suspendnél szintén ez a helyzet, vannak olyan gépek, amin nem működik.
Ha érdekel ez a hibernálás dolog, akkor tutorial alapjá beállítod a gépeden, és kitapasztalod, hogy nálad megy-e. Ha nem, akkor marad a suspend.
-
válasz
Petya XT
#100259
üzenetére
Én megpróbálnám lehúzni az összes hardvert, kezdve az egérrel és a billentyűzettel, kikapcsolni a rádiós cuccokat, és úgy megpróbálni az a felfüggesztést. Illetve nézném a logokat közvetlenül visszatérés után, sokszor ott van benne, hogy miért nem tudott elaludni.
Dell gépem nincs, Lenovo laptopból van két féle, és egy Fujitsu asztali gép, ezeken mind működik a felfüggesztés. Még évekkel ezelőtt, régebbi Gnome verzióval a laptopon volt hasonló problémám, hogy rögtön fel is ébredt felfüggesztés után.
-
válasz
Remus389
#100258
üzenetére
A suspend az a felfüggesztés, azaz az alvó mód. Én mindig azt használom, kb. 2-3 hetente kapcsolom csak ki a gépeim.
A hibernálás az más, az pontosan úgy működik, hogy leírtam: a lemezre írja a memória tartalmát, és leállítja a gépet. De azt külön be kell állítani, gyárilag nagyon kevés disztróban van beállítva.
-
-
válasz
Remus389
#100250
üzenetére
Félreérted. A gép fizikailag valóban leáll, de a kernel, az illesztőprogramok, és a rendszerközeli részek úgy, ahogy vannak, kiíródnak egy fájlba, és következő indításkor a Windows csak berántja ezt a fájlt a memóriába. Ez majdnem pont olyan, mint a hibernálás, annyi a különbség, hogy hibernáláskor a programok (folyamatok) is kiíródnak, fast startupnál viszont azok nem.
-
-
válasz
Remus389
#100238
üzenetére
Személy szerint nekem a bootidő teljesen huszadrangú dolog. Nem tudom megmondani, hogy melyik gépem bootol be gyorsabban, a céges Windowsos i7 10. gen. 16 GB RAM-mal M.2 SSD-vel, vagy az itthoni Linuxos i5 3. gen., SATA SSD-s 8 GB-os gépem. Én nem igazán érzékelek különbséget
Meg eleve ritkán kapcsolom ki a gépeim, kb. 2-3 hetente.Én csak szeretem, hogy Linuxban sok minden sokkal jobban működik. Ha az ember megismeri a tipikus hibáit és bogarait (mint pl. azt, hogy a jelszót célszerű rootként a passwd paranccsal átállítani), akkor nagyon kezes bárány tud lenni. És szerintem sokkal átláthatóbb, anélkül is, hogy infós mérnök kellene lenni hozzá, ezért javítani is könnyebb. Szinte mindig van legalább egy konzolod, amivel logokat tudsz nézni, parancsokat kiadni, stb. Windowsnál sokszor csak találgatni lehet, hogy éppen mi nyűge van.
Illetve az elmúlt pár évben nagyon ráálltak a Microsoftnál arra, hogy folyamatosan tömik bele az újdonságokat a Windowsba, viszont a hibákat nem annyira szeretik javítani. Most pl. itt van ez az új Felidézés funkció, szerintem a kutya nem kérte, de azért belerakták, miközben egy privacy rémálom az egész. De szerintem pár év múlva ez is majd a levesbe, mint sok más korábbi funkció, mert senki nem fogja használni. Szerencsére csak kevés gépen fut el.
-
válasz
Remus389
#100236
üzenetére
Mert amit a "Passwords and Keys" programban látsz, azok a kulcstartók. A Linux ilyen kulcstartókban tárolja a jelszavakat, a GPG kulcsokat és egyéb, bizalmas adatokat. A "Login" a bejelentkezési kulcstartód, az automatikusan feloldódik, amikor bejelentkezel a rendszerbe (ha csak meg nem adsz neki egy külön jelszót). Ha nem oldódna fel, akkor nagyon sok helyen újra és újra meg kéne adnod a jelszót, mert a rendszer nem tudná kiolvasni a kulcstartóból.
Ott látom, van két Chrome-os jelszavad, meg egy harmadik, azok mind a bejelentkezési kulcstartóban tárolódnak. -
-
válasz
RaZroX
#100223
üzenetére
Elementary-ben szerintem nem mostanában lesz HDR support. Tegnap jelent meg a 8, ma futottam vele egy kört Virtualboxban, még csak most jött meg a Wayland session, és most jutottak el odáig, hogy átírják a core appokat GTK4-re. Szerintem majd valamikor a Gnome után 1-2-3 évvel lesz Elementary-ben HDR, és valószínűleg az mpv lesz az első, amelyik sikeresen kihasználja.
-
-
-
-
-
-
válasz
Warton
#100199
üzenetére
Valószínűleg úgy vannak vele, hogy kapja be a Microsoft... mert amúgy tőle kellene valamilyen licencet vásárolni. A Canonicalnak van licence, az OpenSuse-nak is, és a Red Hatnak is, többiekről nem tudom. A Debian a shim csomaggal oldja meg, az meg valahogy úgy működik, hogy a Microsoft kulcsával van aláírva, de bele van ágyazva a Debian önaláíró certje. Manjarohoz is lehet találni leírást, hogy hogyan lehet beleeszközölni a shim-et, csak alapértelmezetten nincs benne.
-
válasz
wrongduke
#100191
üzenetére
Régebben volt egy Screenlets nevű program, volt a PlexyDesk is, illetve a Cairo dock extras csomagjában is volt naptár. Nézd meg őket, de meglepődnék, ha még működne bármelyik is.
Google naptár szinkronizáció van. Ha az Androidos app is a Google naptárat használja, akkor tudod szinkronizálni a Linux-szal, és vannak asztali programok is, pl. a Gnome Calendar, KDE-hez a Kontact, és vannak asztali környezet függetlenek is.
-
válasz
Normi™
#100171
üzenetére
Csak hogy világos legyen, hogy mi volt itt a gond.
Egyrészt awget(ahelyett ugyeclonekell), de azon kívül az is, hogy amikor így töltesz le valamit, akkor magát a projekt forráskódját töltöd le. Azzal pedig nem sokra mész, ha csak le nem fordítod...
apt-vel viszont .deb kiterjesztésű csomagot tudsz telepíteni. Tehát ahhoz, hogy ezt a projektet apt-vel fel tudd telepíteni, egy .deb csomagot kellene készíteni belőle, azt pedig nem akarod, elhiheted nekem
És igen, ahogy javasolták, a tároló csomagjait használd. Főleg, ha ilyen rendszerközeli dolgot telepítesz, mint firmware-ek, driverek, stb. Ezeknél a kernelverzió is számít, a rendszer csomagjai mindig a rendszerben lévő kernelverzióhoz készülnek, ezt nem is igazán tudod elrontani. Külső firmware vagy driver telepítésénél viszont simán előfordulhat, hogy régebbi/újabb kernelverzióhoz készült csomagot telepítesz, és be sem fog bootolni a rendszered, legfeljebb recovery módban, onnan meg csak kézi munkával tudod helyreállítani. -
-
válasz
Remus389
#100115
üzenetére
A NetworkManager-wait-online szolgáltatás addig várakozik, amíg nincs hálózat. Ez általában hálózati megosztások miatt kell, hogy addig ne próbálja meg felcsatolni őket, amíg nincs hálózat. Ha nincs ilyen megosztásod, akkor letilthatod.
De egyébként így meg tudod nézni, hogy melyik szolgáltatások függnek egy adott szolgáltatástól:systemctl list-dependencies --all --reverse NetworkManager-wait-online.serviceA
systemctl disableés amaskközött az a különbség, hogy a disable csak azt tiltja le, hogy a szolgáltatás automatikusan elinduljon. De ha egy másik szolgáltatás függ tőle, akkor a rendszer elindítja.
A mask viszont úgy tiltja le, hogy akkor sem indul el, ha más szolgáltatás függ tőle, ekkor nyilván a tőle függő szolgáltatás sem fog elindulni. -
válasz
Remus389
#100090
üzenetére
Windowsnál sok mindent be sem tölt addig, amíg be nem lépsz. Régi, HDD-s gépeken volt ez nagyon feltűnő, hogy már rég beléptél, de még mindig töltögetett.
Linuxnál viszont próbál mindent, amit lehet betölteni bootoláskor, hogy utána már ne kelljen mást, csak az asztali környezetet és a felhasználó dolgait. Ráadásul ha van valami olyan szolgáltatás, ami a hálózattól függ (és ilyen nagyjából minden gépen van), akkor a NetworkManager-wait-online service azt is megvárja, amíg a hálózat felépül, a többi ettől függő szolgáltatás pedig csak ezután tud elindulni.Tudsz csinálni egy ilyet:
sudo systemd-analyze plot > $HOME/boot.svgEz generál egy boot.svg nevű fájlt a saját mappádba, amit tudsz nyitni valamilyen képnézegetővel vagy Inkscape-pel, és meg tudod nézni, hogy melyik boot művelet mennyi ideig tartott. Főleg a .service végűeket kell nézni. Ha tudod, hogy melyik mire való, és nincs rá szükséged, akkor le is tilthatsz egy-kettőt.
Ú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
- BLACK FRIDAY! - Jogtiszta Windows - Office & Vírusirtó licencek- Azonnal - Számlával - Garanciával
- Játékkulcsok olcsón: Steam, Uplay, GoG, Origin, Xbox, PS stb.
- MS SQL Server 2016, 2017, 2019
- Eladó Steam kulcsok kedvező áron!
- Kaspersky, BitDefender, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- Apple iPhone 13 128GB, Kártyafüggetlen, 1 Év Garanciával
- SK Hynix 32GB DDR4 2666MHz PC4-21300 laptop RAM
- DELL PowerEdge R730xd 16LFF 160TB+400GB 2U rack - 2xE5-2683v4 (16c/32t),256GB RAM,2x10G NET,HBA330
- GYÖNYÖRŰ iPhone 12 mini 64GB Purple -1 ÉV GARANCIA - Kártyafüggetlen, MS3851, 100% Akksi
- magyar billentyűzet - 172 - Lenovo Legion Pro 7 (16IAX10H) - Intel Core U9 275HX, RTX 5080
Állásajánlatok
Cég: ATW Internet Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
)...


CPT.Pirk
