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...

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

a gond az, hogy mikor hogy idézed a parancsot, egyszer van aposztróf az idézetben, máskor nincs.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Á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...

Azért ez sokkal normálisabban is meg lehetne oldani:

Megírod scriptbe amit akarsz egy gépre, normális hibakezeléssel.

Vagy szerzel valami normálist toolt ami lefuttatja neked, vagy elforkolsz mindig és úgy futtatod.

"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.

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?

Dokkoló: Itech

Milyen disztrót rakjak fel most szervernek?

Buliban hasznos! =]

amelyik tudod hogy müködik.

Csak azért kérdeztem, mert nekem mindegy melyik, hátha tanulok valami újat. De szerintem felmegy most egy Ubuntu aztán kész. Meguntam ezt a systemd ellenességet. Egyáltalán nem gyakorlatias.

Buliban hasznos! =]

Debiant.

https://www.coreinfinity.tech

Hat ez ennél bonyolultabb; kerdes, h mire lesz használva. Ha pl. csak konténerekben futnak majd dolgok, akkor valami minimal, stb.

while (!sleep) sheep++;

Annyi igényem van, hogy a telepítő tudjon ZFS-t kezelni, hogy ne kelljen nekem kézzel szórakozni vele.

Buliban hasznos! =]

Nem lesz container.

Buliban hasznos! =]

nixos?

while (!sleep) sheep++;

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 :)

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 :)

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!

Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!

Ilyesmit én is tapasztaltam anno igaz nem archnál. Esetleg ezt a leírást nézd meg, vannak benne hasznos infók.

A másodikra nincs tippem sry.

Hello darkness, my old friend...

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.

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.

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 -=-

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.

"Normális distrón"
Megmondanád, hogy melyik az a "normális" distro ahol nincs kernel frissítve verzión belül?

a Debian úgy rémlik nem frissít kernelt, ha nem apt-get dist-upgrade-el frissítesz

Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

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ó.

mi az, hogy kernel frissítés?
a kernel patchleveljének a frissítése az kernel frissítés?

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

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.

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

a gépre SSH-n léptél be? mert akkor másolhatsz scp-vel is.

Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

ahogy Lenry mondta, ha van SSH akkor scp vagy sftp.

A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

É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.

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.

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.

Csinálj ppa-t.

https://www.coreinfinity.tech

És mivel "hostoljam"?
Saját weblap vagy valami más?

Remélem itt elfér - https://sites.google.com/site/geriprojekt/ - https://github.com/kgregoryan - Az ember téved,a gép hibázik.

például.

A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

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 :)

launchpad teljesen fedi a PPA minden részét, szerintem.

[ Szerkesztve ]

Tegnap még működött...