- A Colorful "fagyosan kompakt" alkatrészekkel megy elébe a nyárnak
- A Keychron ismét egy űr betöltését vállalta magára az egerek szegmensében
- Az átlagnál vaskosabb ventilátorok kandikáltak ki a Corsair vitorlája mögül
- Csatába küldte Magyarországon idei csúcs hangprojektoros szettjét a Samsung
- Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
Hirdetés
-
A legtöbb amerikai szerint a TikTok egy őket befolyásoló eszköz
it Egy felmérés szerint a legtöbb amerikai osztja azon véleményt, hogy a TikTok egy őket befolyásoló eszköz.
-
AMD Radeon undervolt/overclock
lo Minden egy hideg, téli estén kezdődött, mikor rájöttem, hogy már kicsit kevés az RTX2060...
-
VR játék lesz az Batman: Arkham Shadow (Meta Quest 3)
gp Egyelőre csak egy teaser trailert kaptunk a teljes leleplezésre a Summer Game Festen kerül sor.
-
PROHARDVER!
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
-
őstag
válasz Netszemete #31849 üzenetére
Erre amúgy miért kell dokumentáció? Syntax errort mikor szoktak részletesen dokumentálni?
Mint parancs szeparátor értelmetlen, ha nincs parancs előtte. Egyetlen ; vagy & a bashba írva is hibára fut, független a for-tól, done-tól, akármitől.
@bambano-re ráerősítve, a script, amiről szó van, lokálban értelmeztet minden parancsot. Ha pl leszakad az SSH útközben, akkor előbb eljő az idő...
Ha remoteban futtatná az ssh-ban a teljes parancsot, akkor így értelmezett lenne: ssh "parancs &"; mivel két külön kontextusban szerepelnek.[ Szerkesztve ]
Tegnap még működött...
-
Fecogame
veterán
válasz Fecogame #31832 üzenetére
Eszembe jutott két megoldás is, egyik jobb, mint a másik
1., Letörlöm az ebből a repoból lehúzott csomagokat, majd újra felteszem őket a már elfogadott repoból. A kérdés ekkor, hogy a konfog fájlok ekkor elvesznek, vagy megmaradnak? Az egyik csomag pl. a httpd
2., Átírom, hogy honnan származnak a csomagok Melyik fájlban tárolja le, hogy honnan lettek letöltve?
[ Szerkesztve ]
Lassú a mobilinterneted? 4G/LTE antennák, közvetlenül raktárról ---> http://bit.ly/LTE_Antennak
-
őstag
válasz Netszemete #31854 üzenetére
Áhá, értem. Akkor irány a man bash:
DEFINITIONS
The following definitions are used throughout the rest of this document.
blank A space or tab.
word A sequence of characters considered as a single unit by the shell. Also known as a token.
name A word consisting only of alphanumeric characters and underscores, and beginning with an alphabetic character or an underscore. Also referred to as an identifier.
metacharacter
A character that, when unquoted, separates words. One of the following:
| & ; ( ) < > space tab newline
control operator
A token that performs a control function. It is one of the following symbols:
|| & && ; ;; ;& ;;& ( ) | |& <newline>Tegnap még működött...
-
sto1911
veterán
"Azért ez sokkal normálisabban is meg lehetne oldani:" - ez nem is kerdes, de valoszinuleg keves vagyok hozza, illetve az idom is az. Meg hat azert is irtam be ide
Egyebkent probaltam azt, hogy minden gepre letrehoztam egy scriptet, majd ssh-n probaltam elinditani, de valamiert nem ment. Elegge keso volt mar, meg faradt is voltam, igy nem melyedtem bele mi baja lehetett.
-
_Dumber_
őstag
Sziasztok
Adott egy Lenovo Thinkbook 15 G2 laptop, melynek felbontása 1920x1080
Van 2 külső monitorom (Philips 223V7QDSB_00) szintén 1920x1080 ajánlott felbontással szeretnek futni.Ha az egyik monitort rákötöm a HDMI portra akkor mind TTY mind KDE alatt mindkét megjelenítő 1920x1080 felbontásban fut.
Xrandr ezt adja vissza:HDMI-1 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 476mm x 268mm
1920x1080 60.00*+ 74.97 50.00 59.94
1920x1080i 60.00 50.00 59.94
1680x1050 59.88
1280x1024 75.02 60.02
1440x900 59.90
1280x960 60.00
1280x720 60.00 50.00 59.94
1024x768 75.03 70.07 60.00
832x624 74.55
800x600 72.19 75.00 60.32 56.25
720x576 50.00
720x480 60.00 59.94
640x480 75.00 72.81 66.67 60.00 59.94
720x400 70.08
Látszik, hogy a “+” jel a helyes felbontás mellett található, tehát a monitor rendesen közli a preferált felbontást.
Ha ugyanert a monitort és ennek az ikertestvérét már egy USB-C itech 2DP -> DP to HDMI kábellel csatlakoztatom akkor már az xrandr ezt adja vissza:
DP-2-2 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 530mm x 290mm
1920x1080 60.00*+
1024x768 60.00 + 75.03
1280x1024 75.02 60.02
800x600 75.00 60.32
640x480 75.00 59.94
720x400 70.08
DP-2-3 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 530mm x 290mm
1920x1080 60.00*+
1024x768 60.00 + 75.03
1280x1024 75.02 60.02
800x600 75.00 60.32
640x480 75.00 59.94
720x400 70.08
Mivel az xrandr-ot meg tudom erőszakolni, ezért KDE alatt már ki tudom használni a 1920x1080 felbontást, de alapértéknek a “ 1024x768 60.00 +”-t tekinti.
Az SDDM alatt is csak beavatkozással képes hozni a FHD felbontást.“xrandr –auto” mindig a 1024x768-ra állítja be, valamint képtelen vagyok TTY-n rendesen konfigurálni.
TTY-n a virtuális screen 1920x1080, de csak 1024x768 rész látszik a külső monitorokon és azzal tölti ki a képet (rossz felbontás mellett).Ahogy látom az a gond, hogy a dokkoló rosszul ismeri fel a monitorokat. Lehet ezen valahogy javítani?
-
inf3rno
nagyúr
Milyen disztrót rakjak fel most szervernek?
Buliban hasznos! =]
-
-
fatpingvin
őstag
válasz sto1911 #31834 üzenetére
parancskuldes(){ssh parancs1 & sleep 600; kill $!} && for i in {gepek}; do parancskuldes & done
tudom hogy thread necromancy de szerintem így a legkézenfekvőbb, ugyanis egy szekvenciát nem kézenfekvő leválasztani, viszont egy függvényként meghívott cuccot már sima.A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)
-
fatpingvin
őstag
válasz lionhearted #31852 üzenetére
pontosítanék, a & önmagában redundánssá teszi a szeparátort.
A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)
-
fatpingvin
őstag
válasz sto1911 #31859 üzenetére
nem akarok bunkó lenni de szerintem valami banális hiba lesz.
létrehoztad a scriptet, oké. ssh-zó júzer path-jében benne van, vagy absolute pathből hívtad meg? futtatási jogosultságok rendben? script manuálisan indítva működik?A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)
-
Üdv!
Nemrég tértem át Arch Linuxra a laptopomon is, eddig Fedorát használtam. Kb a teljesen szűz telepítés óta tapasztalom, hogy néha a leállítás nagyon sok időt vesz ígénybe. Látszólag a KDE Plasma azonnal kilövődik és megáll a kijelző egy ^@ áradatot mutató kijelzőn, illetve egy villogó kurzoron. Mást nem ír ki, de a ^@ száma látszólag véletlenszerű. Van, hogy percekig áll ebben az állapotban és csak utána áll le. tty-t a megszokott ctrl+alt+fX kombinációkkal már nem tudok ilyen állapotban váltani, hogy megnézzem, mi is történik.
Ami érdekes, hogy van, hogy kb 20 program van nyitva és így állítom le a gépet, ami azonnal le is áll, van, hogy a bekapcsolt állapot kb 5 percig tart, megnézem a leveleimet és kikapcsolom a gépet és 5 percig áll le...
I/O-ra gyanakodtam, de egy friss NVMe SSD van a laposban, nehezen hinném el, hogy ez a bottleneck. Esetleg az xfs fájlrendszer lehet a gond? A rootfs és a /home is XFS.
Melyik logot érdemes nézegetni, hogy mi történhet ilyenkor pontosan? journalctl-t a jelenség utáni első boot során?
Illetve a másik gondom, hogy a laptopban csak USB 3.0 portok vannak, ezt látszólag fel is ismeri a rendszer, illetve nyilván maguk a fizikai portok is kékre vannak festve, jelezve, hogy tényleg 3-as USB-ről van szó. Van egy USB-s ethernet adapterem, amit gigabites hálóra kötve a max letöltés 340 Mbit/s, míg a feltöltés 285 Mbit/s mindig. Telefonról/pendriveról/külső HDD-ről másolva is olyan 30-31 MB/s-sel tudok olvasni és 27-28 MB/s-sel írni. Gondolnám, hogy ez hardver limit, de nem tűnik annak. Windows-szal ugyanezzel a setuppal simán jön a gigabites net az adapterrel.
Az adapter egy noname valami, lehetne feltételezni, hogy az ő linux támogatásával van a gond, de gyanús, hogy minden más eszköz is kb ugyanazon a sebességen hasal el. Még nem próbáltam a pendrive/HDD sebességtesztet windowson, de ha kell, megcsinálom azt is.
Elvileg van USB 3.0 támogatás a kernelben és ez látszik is:
$ zcat /proc/config.gz | grep XHCI_HCD
CONFIG_USB_XHCI_HCD=y
Mi hiányozhat? dmesgben nincsen semmi error ezzel kapcsolatban.
Köszi!
Hogy hívják az éhes horgászt? Gyere Pista, kész a kaja!
-
#68216320
törölt tag
válasz Mr Dini #31878 üzenetére
Ezt én is megfigyeltem. Nálam is teljesen véletlenszerűnek tűnő módon "gondolkodik" leállításnál. (xorg, gnome, sata-ext4, nvme-ntfs)
Azt viszont megfigyeltem, hogy amikor nem a DE-t használom a leállításhoz, hanem konzolon a "shutdown"-t, akkor mintha nem lenne ilyen gondja.
Nem értem az okát csak megfigyelés alapján tűnik így. -
gregory91
senior tag
Nem tudom valaki tud-e válaszolni erre a (talán) szokatlan kérdésre, de azért megpróbálom:
Tudja valaki hogy amire a nyíl mutat arról van-e bővebb információja?
Debian súgó nem volt kielégítő....
Amit én tudok:ha valaki ír csomagnev[a]debian.org-ra akkor []-be írt címzett kapja az üzenetet.De egyébként hogyan lehetne a csomagot "karbantartani"? Újabb verziót feltölteni vagy törölni az egész csomagot?[ Szerkesztve ]
Remélem itt elfér - https://sites.google.com/site/geriprojekt/ - https://github.com/kgregoryan - Az ember téved,a gép hibázik.
-
kovaax
őstag
válasz Mr Dini #31878 üzenetére
Olyat már láttam, hogy a systemd tököl sokat valami júzer processz leállításával, de azt ki szokta írni a konzolra (ott láttam). Nagyon nagy méretű xfs fájlrendszereken az indulásnál szokott eltimeoutolni a mount (redhat alatt ismert bug).
-=- There's no place like /home -=-
-
ivana
Ármester
válasz gregory91 #31881 üzenetére
De egyébként hogyan lehetne a csomagot "karbantartani"? Újabb verziót feltölteni vagy törölni az egész csomagot?
Normális distrón amikor egyszer ki lett adva utána nincs verzió upgrade, csak security és bug fix. Kivéve kivételes esetben, nem úgy mint az ubuntunál ahol képesek kernelt upgradelni. Ezeket a karbantartó backportolja. Illetve nyilván új release esetén lehet utána kell húzni a buildelő scriptet.
-
ivana
Ármester
Nem minden distro rolling. Se a Red Hat-en és származékain (fedora, meg a centos) kernel upgrade egy verzió alatt, se openSUSE Leap-en, vagy fizetős SUSE-n. (Nyilván thumbleweeden van, de az full rolling, ott release sincs.) Debianon sincs. Az ubuntu LTS egyik legnagyobb hibája a kernel upgradelgetése szvsz. Vagy legyen rolling vagy legyen fix a verzió.
-
vicze
félisten
válasz bambano #31887 üzenetére
Igen az is frissítés mivel az adott LTS kernelbe is backportolják az új dolgokat, csak megmarad a biztos kompatibilitása és ki nem vesznek semmit, ritkán de frissítve vannak rendszeresen, minden bugfix security fix, driverek mind backportolva vannak.
De egy 6évig támogatott kernel muszáj frissíteni más csak az új HW-k támogatása miatt is, de ott vannak a biztonsági problémák is. Főleg a jelenlegi Kernel frissítési tempó mellett lehelten lenne bármilyen régi verzión maradni backport nélkül. Egy nevében 5.10-es kernel viszonylag friss is lehet.@ivana: Lást amit írtam.
"ubuntu LTS egyik legnagyobb hibája a kernel upgradelgetése szvsz"
Ha nem ezt csinálnák konkrétan nem használnák desktopon attól a pillanattól, mivel 5éves HW-kon futna csak kb. Mondjuk csak 20.04-gyel változott most sűrűbbre(főverziókhoz illesztés), de a kernel fejlesztési tempója jelenleg olyan, hogy meg is értem."fedora, meg a centos"
Gyakorlatban mind a kettő rolling(CentOS teljesen, Fedoránál 6 hónapod van, de lehet már rosszabb ott is), csak némileg késeltetve, pont az a feladatuk, hogy teszteljék az RH-hoz a stabilitást. RH pont úgy frissül mint bármilyen más LTS kernel(azaz nem mert 10év+ a support), de ott még külön bakportcolnak elég sok mindent ha kell. Amúgy kínkeserves dolog néha a kernel patch RH-ban."openSUSE Leap"
Adott verzió support ideje 6 hónap és csá, ez elég messze van az LTS-től, csak a kernel ősrégi benne.SUSE EL deto RH.
Szóval nincs olyan, hogy a kernel nem frissül, max. olyan van hogy ritkábban frissül és nincs benne nagyobb újítás.
-
Edorn
aktív tag
Hogy tudok linuxról (centOs) terminállal (puty) átmásolni egy mappát és annak minden elemét ftp-vel?
ftp, majd azon belül mput-al próbálkoztam, de az csak fájlokat másol, a másolandó mappára azt mondja, hogy "not a plain file."...AMD Ryzen 5 5600 3.50GHz AM4, SAPPHIRE RX580 4GB, EX2220 (1920x1080), crucial MX500 SSD, CRUCIAL 16GB Ballistix DDR4 3200MHz, MSI B450 GAMING PLUS | Tárhely, domain: https://nokturn.hu
-
gregory91
senior tag
És mint esetleges karbantartó hogyan backportol...öhm...
Rákerestem a fogalomra de csak a kernelel kapcsolatos információt tartalmaz,nem áll szándékomban a kernellel "így" foglalkozni.Van egy projektem amit szerepeltetni szeretnék a szoftverkezelő/apt-ban. De addig nem merek bele menni amíg nincs egy megbízható információ ezzel kapcsolatban. Ez már nem olyan hogy összeírok egy control fájlt és egy dpkg-deb futtatást csinálok rajta.Remélem itt elfér - https://sites.google.com/site/geriprojekt/ - https://github.com/kgregoryan - Az ember téved,a gép hibázik.
-
ivana
Ármester
De miért kéne új kernel? Amíg van security patch, meg bugfix addig tökéletes a dolog.
5.10-es kernel viszonylag friss
is lehet. A legrégebbi még támogatott LTS kernel a 4.4.Adott verzió support ideje 6 hónap és csá, ez elég messze van az LTS-től, csak a kernel ősrégi benne. Ott van normális upgrade path, meg pont a kernelt annyira nem szokták csesztetni. Nekik full saját águk van. Nagyon veszélyesnek tartom a kernel erőltetett frissítgetését.
Szóval nincs olyan, hogy a kernel nem frissül, max. olyan van hogy ritkábban frissül és nincs benne nagyobb újítás. Az eredeti postban direkt nem használtam a frissítés szót. A patchlevel frissítés nem upgrade.
-
vicze
félisten
Legyen akkor nincs "upgrade" csak folyamatosan frissül szünet nélkül.
Mellesleg továbbra is ahogy írtam ez Deksptop OS-eken leheleten, mert különben új HW nem lenne támogatva és már így is probléma hogy a Linux nagyon lassan adoptál új HW-t. Az Ubuntu LTS valahol egy járható középút szerintem, ezért is HWE (Hardware Enablement) kernel frissítések vannak 6 havonta.4.4 még 2 hétig támogatott pontosan. 6 év minden LTS-nek jelölt kernel, minding 6 éves lesz a legöregebb.
-
-
gregory91
senior tag
válasz fatpingvin #31897 üzenetére
Mármint?
Remélem itt elfér - https://sites.google.com/site/geriprojekt/ - https://github.com/kgregoryan - Az ember téved,a gép hibázik.
-
fatpingvin
őstag
válasz gregory91 #31898 üzenetére
bérelj egy pici VPS-t és dobd fel oda . PPA-k létrahozására van fejlesztői doku. nézd a statisztikákat egy-két hónapig hogy mennyi a letöltés aztán mérlegelj hogy érdemes-e.
alternatív javaslat, vesd fel a fórumokon hogy hostol-e valaki olyan PPA-t ahol elférne.A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)
-
őstag
válasz fatpingvin #31899 üzenetére
launchpad teljesen fedi a PPA minden részét, szerintem.
[ Szerkesztve ]
Tegnap még működött...
Új hozzászólás Aktív témák
- Kínai cégek segítik ezentúl a Teslát, a Renault-t, a Hyundait és a Toyotát
- Házimozi, és Hifi kábelezés!
- LEGO klub
- Apple AirPods Pro (2. generáció) - csiszolt almaságok
- NVIDIA GeForce RTX 3080 / 3090 / Ti (GA102)
- Kerékpárosok, bringások ide!
- Hálózati / IP kamera
- Mindenki AI-t akar, már 2025-re is eladták a HBM chipeket
- exHWSW - Értünk mindenhez IS
- Vallás
- További aktív témák...