[MEGOLDVA] Rosszalkodik az mc

Segédprogramok

A legutóbbi frissítés óta csak a baj van az mc-vel.
GNU Midnight Commander 4.8.32
Built with GLib 2.80.4
Built with S-Lang 2.3.3 with terminfo database
Folyamatosan akadozik a megjelenítése, elfelejti frissíteni a képernyőt, fekete blokkok jelennek meg, ilyenek (CTRL+O esetén nem, inkább akkor, amikor view vagy edit és a fájllista között váltok). Nem tudom, hogy ez az mc sara-e, vagy az slang-é (egyszerre frissültek, a terminfo nem változott), de nagyon bosszantó. Kipróbáltam többféle terminál emulátorral is (uxterm, urxvt, st), bár máshogy, de mindnél jelentkeznek valamilyen szinten ezek a problémák. A frissítés előtt sose tapasztaltam ilyesmit.

Messze nem ez az első bajom az mc-vel, az utóbbi tíz évben rohamosan romlott a minősége, de ez az első, ami vizuálisan is kifejezetten bosszantó és idegesítő. A többit nyűgjét vagy megtanultam megpatkolni minden frissítés után, vagy együttélni vele (de pl. az, hogy a fájllista és a shell munkakönyvtár meg a command history szinkronja néha elcsúszik a francba, soha nem fogom megszokni).

Másnál is előjött ez az újrarajzolási probléma? Ha igen, talált esetleg valaki már megoldást rá (azon túl, hogy lekoptatom a CTRL és L gombokat a billentyűzetemről).

ps: itt egy képernyő a hibáról. Ez még istenes, itt most épp "csak" a felső sáv meg az Fn menü mászott el, szokott ez rosszabb is lenni (az tök random, hogy mi nem frissül, legalábbis én nem találtam benne rációt még).

MEGOLDÁS: nem slang bug, nem is mc bug, hanem glib bug, beleböfög az stderr-ba egy hibaüzenetet az F4 leütésekor, emiatt esik szét az, hogy mit hisz az mc mi van a képernyőn, és mi van valójában, ez okozza.
"mc 2>/dev/null"-lal indítva a hibajelenség megszűnik.

  • 2549 megtekintés

( locsemege v | 2024. 12. 17., k – 19:17 )

Szerkesztve: 2024. 12. 17., k – 19:18

Szerintem nem mc bug, inkább valamelyik library lesz a ludas. Fedora 41-en nem jelentkezik a probléma.

mc --version
GNU Midnight Commander 4.8.32
Built with GLib 2.82.2
Built with S-Lang 2.3.3 with terminfo database
With builtin editor
With subshell support as default
With support for background operations
With mouse support on xterm and Linux console
With internationalization support
With multiple codepages support
With ext2fs attributes support
Virtual File Systems:
 cpiofs, tarfs, sfs, extfs, ftpfs, shell
Data types:
 char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64;

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

inkább valamelyik library lesz a ludas

Csak az slang jöhet szóba, de az ugyanaz a verzió nálad is.

A beállításoknál nálam az "Options" > "Configuration" > "Use internal view" és "Use internal edit" be van kapcsolva, máskülönben nem adódnak át a cuccok és szopás használni (pl. ha keresek valamire, akkor listában F4-et ütve az mcedit már nem tudja, hogy mire is kerestem). Ha ez nincs bekapcsolva, akkor független processzként fut az mcedit, és ilyenkor megfelelően frissül is a képernyő, de ez nekem az előbbiek miatt nem jó.

(ps. nálam van még egy "Built with libssh2" sor és van egy "sftpfs" vfs plugin is, de ezeknek ugye semmi köze a frissítéshez, minden más pontosan ugyanaz, csak a glibc verzió más.)

( arpi_esp v | 2024. 12. 17., k – 19:28 )

Szerkesztve: 2024. 12. 17., k – 19:29

Options / Display bits-el erdemes jatszani ilyenkor

nekem screenben szokott hasonlot prodkalni, de ott mar evek ota.

illetve azt is erdemes megnezni a TERM env erteke mi, foleg linuxon szeretik varialni a disztrok, es nem biztos hogy a terminfo/termcap megfelelo hozza.

Kössz a tippet, sajnos nem.
Input / display codepage: [ UTF-8 ]
[x] Full 8 bits input
Más nincs ebben a "Display bits" ablakban (a terminál egyébként 8 bit inputra van konfolva és UTF-8 aware, és LANG="en_US.UTF-8").

Nem hiszem egyébként, hogy ez lenne a gond, sokkal inkább úgy tűnik, hogy optimalizálni próbálja a CSI szekvenciákat az mc, hogy csökkentse a terminálforgalmat, csak hát rosszul. Olyan, mintha teljes egészében kimaradnának bizonyos CSI blokkok, és nem olyan, mintha hibásak lennének (meg egyébként is CTRL+L-re jól megjelenik, szóval nem hiszem, hogy itt kódolási probléma lenne).

Nem. (Mármint igen, elvileg lehetne, de itt most tutira nem ez a baj, mert sem a TERM értéke, sem a terminfo nem változott a frissítésnél, ráadásul termináltól függetlenül is előjön).

Egyébként TERM="rxvt-unicode-256color", TERM="st-256color", TERM="xterm-256color" és TERM="xterm" esetén is előjön a probléma, szóval másfele kell keresgélni.

( arpi_esp v | 2024. 12. 17., k – 19:35 )

> az utóbbi tíz évben rohamosan romlott a minősége

s/10/20/

mondjuk mindig idiotak fejlesztettek, egy ideig a miguel icuaza, aki mindent szetbasz amihez hozzanyul, szerencsere mostanaban a microsoftnal rombol mar. a mostani dev (Pavel) is egy idiota, anno bekuldtem vagy 20 patchet ami kulonbozo bugokat javitott (tobbek kozt a path szinkront is) vegul csak egyet rakott be, ami a kereseskori kifagyast fixalta (szarul hasznalta a select()-et).

tavaly meg egyszercsak gondolt egyet es atcserelte a hotkey-eket, en meg pislogtam hogy miert nem azt csinalja amit nyomok. kovetkezo verzioba meg sikeurlt ezt tovabb rontania, aztan a nepharag lesujtott es 3. frissitesre visszaallt az eredetire.

Húsz éve használom, de csak az utóbbi 5-10 évben kezdett el bosszantani. Korábban is voltak hülyeségei, de munkamenetet akadályozó bugjai nem. Most már vannak.

Legutóbb az volt, hogy van két zip fájlom, az egyikre Enter-t ütve megnyitja, mint egy könyvtárat, a másikra Enter-t ütve meg behozza a Firefox-ot, ami persze meg nem tud mit kezdeni vele, csak megkérdezi, hogy letöltse-e, de közben meg már másolja is a háttérben és már be is telt a tmp...

( NevemTeve | 2024. 12. 17., k – 20:16 )

Szerkesztve: 2024. 12. 17., k – 20:53

Off: régóta szeretném tudni, hogy a fraktál az a 'check' nevű komponens, amit a mc-fordítás hiányol. Van egy homályos emlékem, hogy valami multiplatformosító dolog lehet, csak nem működik Linuxtól különböző platformokon.

No package 'check' found

Aztán van ez az okosság, ez is ismerős:

   55 | if (sizeof ((sighandler_t)))

Itt ugye a túl sok zárójel b@ssza fel a gcc agyát. [Szerk: most látom, hogy ez nem lekváros, hanem szándékos: így ellenőrzi, hogy a sighandler_t az változó-e vagy típus: ha változó, akkor nem baj, akárhány zárójelben is van.]

No mindegy, ha PKG_CONFIG_PATH jól áll, akkor azért valamennyire fordul.

Önmagában a mc update nem hozott ki hibát, mgpróbálom a slang-ot frissíteni. Egy fontos részlet:

export CFLAGS="$CFLAGS $CPPFLAGS" ## CPPFLAGS is for the weak, the slang-devs don't use it

( egmont | 2024. 12. 17., k – 21:17 )

A csatolt hibás képet a helyessel összevetve nem sok derül ki, azonban a hibás képet a sima mc (kétpaneles fájlkezelős mód) helyes képernyőjével annál inkább.

Fent, ahol világoskék csík kéne hogy legyen, ott a sima kétpaneles módban is az van, viszont egy sorral lejjebb van a sok vízszintes vonal amit az mcedit valszeg nem is kér hogy legyen. Gyanús hogy az csúszik feljebb eggyel.

Alul pont az látszik csak, ami változott. Pl. "Menu" helyett "Save", "RenMov" helyett "Move(szóköz)(szóköz)".

Tehát minden bizonnyal valami ilyesmi történik:

Amikor meghívod a beépített mcedit-et, az pontosan tudja hogy _elvileg_ mi van a képernyőn (a fő kétpaneles fájlkezelő nézetben), és kioptimalizálja a rajzolást, csak azt rajzolja újra ami változott.

Viszont a képernyőn _gyakorlatilag_ nem az van. Vagy már ott is láttál korruptálódást, ebben az esetben vissza kéne menni egy lépéssel a nyomozásban és az elsőnek fellépő hibára fókuszálni (de akkor is valószínűleg hasonló lesz a konklúzió), vagy pont az mcedit megnyitása kapcsán esik szét. Feltételezve az utóbbit: azok a szkriptek amik kiderítik a fájltípus, kiterjesztés stb. alapján hogy mi a teendő a fájllal, milyen alkalmazás hívandó meg stb., azok valamelyike okád valami hibát vagy figyelmeztetést a kimenetére, azaz a terminálra, ami hazavágja annak a tartalmát, ott innen kezdve nem az van mint amit az mc hisz és így az inkrementális képernyőfrissítés (amit nem közvetlen az mc csinál hanem a slang vagy ncurses, de ez most lényegtelen) is nyilván szar lesz.

Indíts egy `script`-et, abban játszd végig, a végén a kapott `typescript` fájlt nézd át, érzésre megtalálod hogy kábé hol indul az mcedit, arrafelé keress oda nem illő figyelmeztetéseket-hibákat, remélhetőleg a bűnös elárulja magáról hogy melyik progi is ő.

kioptimalizálja a rajzolást, csak azt rajzolja újra ami változott.

Nyilván, a kérdés az, hogy hogyan kell megjavítani, hogy helyesen optimalizáljon.

azok a szkriptek amik kiderítik a fájltípus, kiterjesztés stb. alapján hogy mi a teendő a fájllal, milyen alkalmazás hívandó meg stb.,

Internal edit esetén nem futnak le ilyesmik.

hogy kábé hol indul az mcedit

Internal edit esetén nem indul mcedit (mint külön processz).

Indíts egy `script`-et, abban játszd végig

Szopacs, script-el indítva nem jelentkezik a hiba. Legalábbis eddig egyszer sem jött elő.

EDIT: Viszont amikor F4-et ütök, azon a ponton van egy ilyen sor a typescript fájlban:
(mc:288988): GModule-.[1;35mCRITICAL.[0m **: .[34m23:32:44.818.[0m: g_module_close: assertion 'module != NULL' failed
Ez mondjuk okozhatja, mert újsor karaktert köp a kimenetbe, ami megmagyarázná a hibajelenséget. Eszerint glibc bug okozná a hibás képernyőt? LOL.
Hm, ez lesz az biztosan, mert "mc 2>/dev/null" esetén minden okés...

> Nyilván, a kérdés az, hogy hogyan kell megjavítani, hogy helyesen optimalizáljon.

Mire gondolsz az alatt hogy helyes vs. helytelen optimalizálás? Ha a segge alatt, tudta nélkül megváltozhat a képernyő tartalma, akkor nyilván semmilyen optimalizálás nem tud garantálni helyes végeredményt, az egyetlen esély minden egyes alkalommal a teljes képernyőt újrarajzoltatni. Ezt tudtommal egyetlen library se csinálja (kivéve ha direkt ezt kéred, lásd Ctrl+L). Ha meg számíthat arra, hogy senki más nem piszkít bele az általa rajzoltakba, amire nyilván minden library számít, akkor fair játék békén hagyni bármit ami szándék szerint nem változik. Nem látom, hogy létezhetne bármiféle átmenet.

> Internal edit esetén nem futnak le ilyesmik.

Lehetséges. Internal view esetén vannak ilyenek, innen gondoltam hogy edit esetén is lehet hogy vannak.

> Internal edit esetén nem indul mcedit (mint külön processz).

Nem mint külön processz gondoltam, hanem a belső mcedit komponens.

> g_module_close [...] glibc bug

Ez glib, nem glibc.

Valszeg az mc hibásan használja a glib-et, megérné küldeni nekik egy hibajegyet.

( Raynes v | 2024. 12. 17., k – 21:53 )

Szerkesztve: 2024. 12. 17., k – 23:09

Nálam is ugyanazok a verziók vannak fent mc-ből. slang-ből, stb., mint a topikindítóban. st-ben és xterm-ben hibátlan az mc, nincs vele gond. Az mcedit viszont bugzik, a felső sorában fekete mezők jelennek meg, meg hiányosan írogat dolgokat oda. Nem nagy probléma, mert Vifm-et használok, mc-t csak ritkán, és akkor is neovim-mel és less-szel, így az mceditet, és az mc saját fájlnézőjét nem látom soha.

Az urxvt-t nem ajánlom, az egy bugos fos. Az uxterm-et nem ismerem. A foot, kitty, alacritty, wezterm, lxterminal, gnome-terminal, konsole az okés.

Ha st-ben gond van, akkor érdemes újrafordítani. Ezzel szívtam nemrég én is, hogy saját st buildet használok, és fagyott miatta a gép. Sokára jöttem rá, hogy ez a baj, újrabuildeltem, és azóta jó. Néha idővel elavul a bináris, ha régi függőségek ellenében volt dinamikusan linkelve fordítva, de azóta drasztikusan léptek verzióban a függőségek.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Az mcedit viszont bugzik, a felső sorában fekete mezők jelennek meg

Akkor nemcsak nálam jelentkezik ez a hiba.

Az uxterm-et nem ismerem.

Ez az etalon. Ha valami nem megy xterm alatt, akkor az programhiba és nem terminal hiba. Manapság a CSI kódokat xterm-hez mérik mindenhol. (Az "u" csak annyit tesz, hogy UNICODE kompatíbilis opcióval fordított.)

A foot, kitty, alacritty, wezterm, lxterminal, gnome-terminal, konsole az okés.

Ezeket próbáltam, mind egy bloated foshalmaz, és nem tudják, ami nekem kell, helyette tudnak 100 dolgot, amire rohadtul nincs is szükségem.
A gnome-terminalt meg különösen senkinek sem ajánlom, és a konsole-t se, mert iszonyat függőségük van (több, mint fél GIGA).

Egyébként elárulok egy titkot, ezek majdnem mindegyike pontosan ugyanarra a libvte függvénykönyvtárra épül, mint az urxvt, tehát ha az urxvt bugos fos, akkor ezek is (és tényleg).

Ha st-ben gond van, akkor érdemes újrafordítani.

Eleve én fordítottam, de nem st bug van, hanem mc bug.

Na az st az nem libvte-s, az egyetlen bajom vele, hogy nem tudja rendesen az ablakátméretezést, egyébként mindenben megfelelne az elvárásaimnak. Néztem a kódját, hogy hozzáadom, de iszonyat csapnivaló a belső terminálábrázolása, az egészet refaktorálni kellene hozzá.

> Egyébként elárulok egy titkot, ezek majdnem mindegyike pontosan ugyanarra a libvte függvénykönyvtárra épül, mint az urxvt, tehát ha az urxvt bugos fos, akkor ezek is (és tényleg).

A korábbi felsorolásból az lxterminal és a gnome-terminal épül a libvte-re, a többi nem. Az urxvt sem.

A szubjektív részére ("bugos fos") nem reagálnék, rád hagyom, de az objektív tényeket legalább rakjuk a helyükre, köszönöm.

Igen, némelyik felsorolt terminál bloat, de akkor meg nyújt pluszt cserébe (GPU gyorsítás, képkezelés, ligatúrák, fülek, stb.), és legalább bugmentesek. Csak 1-2 épül VTE-re, nem az összes. Régen én Termite-ot használtam, de annak abbamaradt a fejlesztése. Az urxvt-vel személyesen is van rossz tapasztalatom, hogy nem jeleníti meg az összes Unicode karaktert, amit a font támogat, meg ANSI kódokat nem kezel le korrekten.

st-nél nem az a lényeg, hogy te fordítottad-e, hanem hogy mikor. Mert ha nagyon sok hónapja, és azóta rendszeresen frissült a rendszered, libek frissültek, akkor én a helyedben még egyszer újraforgatnám az st-t, változatlan kóddal, de új bináris jön létre, a mostani libekhez lesz dinamikusan linkelve, ez meg tud szüntetni fennálló bugokat. Rollingon ez nekem rendszeresen előjön, nem csak st-vel. Én st-t használok.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Persze, hogy nem csak nálad. Szerintem mindenkinél, aki újabb verziót használ. Maximum csak azokat nem érinti, akik ilyen dinoszauruszok korabeli disztrón vagy kiadáson vannak, és el vannak maradva a komponensei 2-3 verzióval.

A 2>/dev/null formátumú átirányítás nálam is megszüntetni mcedit-ben a hibajelenséget. Jó tudni, figyelni fogok erre a jövőben, be is teszem az sxhkd konfigba, hogy ezzel indítsa az mc-t.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Igen. Pontosan. Jelen esetben szerencséd volt vele. Az mc amúgy is egy old-school szoftver, nem fejlődik sokat, így nem probléma, ha le van maradva a verzióval. Egyébként sem szopatott volna meg nagyon, látod, lett rá egy soros /dev/null-os workaround, amíg nem javítják, de az is lehet, hogy ha kézileg fordítanád a mc-git-et, abban máris javítva van, csak még a legújabb kiadásba még nem került bele a javítás.

Van viszont, ahol a verziók frissessége jobban számít, pl. ha újabb szoftvereket akarsz lefordítani (pl. home brew fájlkezelők, népszerű szoftverek Rust-ban újraírt változatai), amik igénylik az újabb fordítókat, vagy libverziókat, a github, gitlab, stb. tele van ilyenekkel. Vagy pl. játékok nagyon igénylik a legújabb kernel, legújabb GPU driver/mesa, legújabb Proton, stb. csomagokat, néha ezen múlik, hogy elindulnak-e, vagy játszhatóak-e. Illetve aki nagy waylandes, és valami nagyon modern waylandes felületet akar használni, pl. KDE6 vagy Hyperland, náluk is elég fontos, verzióról verzióra kerülnek bele a feautre-ök, bugjavítások. A negyedik esetkör, amikor valaki nagyon új gépet, hardvert vesz, pl. pár hete, hónapja kijött legújabb GPU, CPU, chipset, stb..

Másik részről ami megmenti a dinoszauruszos disztrókat mostanában, az a Snap, Flatpak, Appimage, abban elérhetők általában az újabb verziókk és nem gond, ha régi rendszer van alatta, mert úgyis a saját függőségeivel együtt konténerizálva jönnek ezek.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( bzt | 2024. 12. 17., k – 23:58 )

Köszönöm mindenkinek a segítséget!

A megoldás nem slang bug, nem is mc bug, hanem glibc bug, beleokád az stderr-ba egy hibaüzenetet, emiatt esik szét az, hogy mit hisz az mc a képernyőn és mi van valójában.

Ez biztos, hogy nem mc bug? Az stderr legálisan hibaüzenetek kiíratására van fenntartva, tehát ha a vezérlőkódokat stdout-ra írogatja az mc, akkor neki kell arról gondoskodnia, hogy az stderr-t elnyelje, azaz a /dev/null-ba küldje, ahogyan csináltad is. Workaround lehet egy alias.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Azért ne túlozzunk: `glib` probléma. Ami persze fakadhat `mc` hibából.

Szerk: glib-éknél is elgurult a gyógyszer diadalmas előrelépés történt, `meson` kellene a fordításhoz. Aminek, ha találgatnom szabad, nyilván további három függősége lesz, köztük egy újabb Python3 verzió.

Szerk: a meson maga is meg van könnyítve, tehát korrekt INSTALL.TXT helyett random szamárságok vannak hozzá, a hasznos információ itt van: https://www.linuxfromscratch.org/lfs/view/development/chapter08/meson.h…

Szerk: glib meglátása:

meson.build:2214:0: ERROR: Subproject exists but has no meson.build file.

   2213 # Import the gvdb sources as a subproject to avoid having the copylib in-tree
   2214 subproject('gvdb')
   2215 gvdb_dep = dependency('gvdb')

Én, ha ilyen subproject lennék, most elszégyellném magam, és rögtön generálnék egy ilyen meson.build fájlt.

https://gitlab.gnome.org/GNOME/glib/-/issues/2716

Azért elbírnám, ha nem vérpistikék és pötteringek kezében lenne az ipar sorsa. No mindegy, már itt az éjjájj, az majd megoldja ezt is.

Szerk: szóval ahol azt írja, hogy Gitlab/releases, onnan egycsapásra ne töltsünk le félig összecsomagolt használhatatlan fájlokat, hanem innen: https://download.gnome.org/sources/glib/

Persze így is megpusztul a fordítás, de van itt pár json formátumú logfile(!), elvileg lehetséges, hogy valamelyikben van hasznos információ.

Szerk: további jóság: a disztróból jött slang-nak van /usr/include/slang könyvtára is, a forrásból jöttnek nincs. A `mc` fordítása során ezért az előbbi nyer.

find /usr/include /usr/local/include -name 'slang*' -o -name slcurses.h
/usr/include/slcurses.h
/usr/include/slang
/usr/include/slang/slcurses.h
/usr/include/slang/slang.h
/usr/include/slang.h
/usr/local/include/slcurses.h
/usr/local/include/slang.h

( bzt | 2024. 12. 18., sze – 08:02 )

Szerkesztve: 2024. 12. 18., sze – 08:06

Ez biztos, hogy nem mc bug?

Azért ne túlozzunk: `glib` probléma.

Gyerekek, ez akkora glibc bug, hogy a holdról is látszik: "CRITICAL: g_module_close: assertion 'module != NULL' failed".
Nyilván illene az mc-nek tisztességesen kezelnie az stderr-ját, szó se róla, na de az, hogy egy ilyen glibc hiba egyáltalán előidézhető applikációs oldalról és ez összebassza a kimenetet az csakis a glibc sara.

Jobb lett volna, ha eleve kezeli az stderr-t, de nehéz hibáztatni az mc-t azért, mert feltételezte, hogy a libc nem okád az stderr-jára.

Ebben az iparban egyetlen betűnek is lehet jelentősége, pl. `identd` vs `inetd` vs `rinetd`. Ugyanígy a `glib` sem azonos a `glibc`-vel.

Namostan a `glib`-nek megvan az a rossz szokása, hogy amikor hibás paraméterrel hívják, akkor a stderr-re logol (assert.h:assert) bár az igaz, hogy az end-user nemigen tud mit kezdeni ezekkel.

Szerk: a Java stacktrace-ei végtelenül idegesítőek ugyan, amikor rendes hibakezelés helyett írja őket a program a logba, de a mostani esethez jól jönne egy ilyen.

Ebben az iparban egyetlen betűnek is lehet jelentősége, pl. `identd` vs `inetd` vs `rinetd`. Ugyanígy a `glib` sem azonos a `glibc`-vel.

Valóban, nem'tom miért néztem folyamatosan glibc-nek... talán mert nem is lenne másra szüksége?

a Java stacktrace-ei végtelenül idegesítőek ugyan, amikor rendes hibakezelés helyett írja őket a program a logba, de a mostani esethez jól jönne egy ilyen.

És újfent, valóban!

( egmont | 2024. 12. 18., sze – 19:57 )

Közvetlenül a 4.8.32 tag utáni commit:

commit 876555035a0ba61167180c0a59890e66d2d66902
Author: Yury V. Zaytsev <yury@shurup.com>
Date:   Sun Aug 25 13:21:00 2024 +0200

    Ticket #4576: fix visual glitches by avoiding `g_module_close` on `NULL` while loading `libaspell`
    
    Signed-off-by: Yury V. Zaytsev <yury@shurup.com>

A ticket szerint a korábbi verziók nem érintettek, és nyilván a következők sem lesznek.

Ebben nincs meglepő, az oroszok, ukránok benne vannak szinte az összes ilyen két paneles commandernek a fejlesztésében, nem csak mc, Double Commander, Vifm, stb.. Egyedül a Total Commander kivétel, mert az nem FOSS, meg ott a svájci fejlesztő egyedül nyomja. Ez se csoda, az oroszok után a német nyelvterület még az, hol ezek a commander-klónok mindig is népszerűbbek voltak.

Szerk.: sokszor meg is lep, hogy ezek a commanderek a németektől nyugatabbra mennyire népszerűtlenek. Retró videókon is látom, hogy az amerikai retrósok gépelgetnek a command.com-ba, mint a hülye, ezt annak idején senki nem csinálta. Eleve a Norton Commander is amerikai volt, ezért nem értem, hogy miért nem lett arrafelé népszerűbb. Mi itt Európában sose gépelgettünk a parancssorba, akkor se, mikor a DOS uralkodott. Szinte mindenkinél futott valami fájlkelező, Norton Commander (ennek a klónja az mc), DOS Navigator (klónja a dn2l), Volkov Commander, XTree (klónja az YTree), DOS Shell, Windows alatt nc95, FAR, Windows Commander, ami később Total Commander lett, de van még egy csomó a mai napig, FreeCommander, Double Commander, német fejlesztés az EF Commander, linuxos vonalon Krudasader, Tux Commander, mucommander, stb.. Egyedül az amigások még azok, akik hűek maradtak a kedvenc fájlkezelőjükhöz, az Opus-hoz, annak van modern windowsos változata.

Még a linuxos power usesek, akik terminálguruk, azoknál is ma már inkább olyan fájlkezelőt futnak, ami a Mac-es Finder működését utánozza, Ranger, lf, nnn, és nem favorizálják a commander típusúakat, pedig azok továbbra is léteznek, nem csak mc, de Vifm, sfm. Ez még a GUI-ra is igaz, minden disztró, DE alapvetően Mac Finder / Windows Explorer stílusú fájlkezelőt szállít (Nautilus, Dolphin, Thunar, Caja, PCmanFM, stb.).

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Off: eccer az találtam mondani a mc tudós fejlesztőinek, hogy a free(talannull); talannull= NULL; helyett jobb lenne az if (talannull) { free(talannull); talannull= NULL; }, de meggyőztek, hogy a felesleges free(NULL) egyáltalán nem gond.

https://midnight-commander.org/ticket/3585

A hozzáállásról van szó (mondta Gerald Strickland igazgató Marty McFly-nak): hagyományos észjárással gondolkodva azt tesszük szabállyá, hogy "semmilyen destruktort nem hívunk NULL-pointerre, sem free-t, sem fclose-t, sem g_module_close-t"; nem pedig azt, hogy "hát a free-nél lehet lazázni, a fclose-t korretül kell csinálni (legalábbis egy bizonyos glibc verzió óta), a g_module_close pedig határset."

A g_free() számára a bemenet lehet null, ahogy a free() számára is.

https://docs.gtk.org/glib/func.free.html

mem

Type: gpointer

The memory to free.

The argument can be NULL.
The data is owned by the caller of the function.

Szóval teljesen felesleges, amit írtál.

( FeriX v | 2024. 12. 18., sze – 20:58 )

Ha már MC, akkor csak úgy

DOS-on Norton Commander-el éltem, ezért egy ideje MC-ről erre váltottam:

https://github.com/elfmz/far2l?tab=readme-ov-file#far2l-

Fut mindenen (is):

https://github.com/elfmz/far2l?tab=readme-ov-file#community-packages--binaries

Van portable ha hirtelen bármilyen architektúrán vagy OS szükséges:

https://github.com/spvkgn/far2l-portable/releases

Ubuntu stabil csomag amit én használok:

https://launchpad.net/~far2l-team/+archive/ubuntu/stable

Van ebben is far2l és far2ledit. Eleinte létrehoztam alias-t mert úgy ráállt a kezem az mc-re hogy szívás volt.

Egyre bővül a plugin készlete:

NetRocks (SFTP/SCP/FTP/FTPS/SMB/NFS/WebDAV), colorer, multiarc, tmppanel, align, autowrap, drawline, editcase, SimpleIndent, Calculator, Python (optional scripting support)

Ez ilyen. Érdekességnek próbáltam be, retró nosztalgiából, annyira nem volt fontos, hogy elkezdjek jelentgetni, pedig valóban lehet hasznos lett volna. Anno, mikor néztem, elég halott projektnek tűnt mindkettő, most nem néztem, hátha van újabb commit, hétvégén lehet újra megnézem. Ennek semmi köze nincs ahhoz, hogy melyik disztró, konzolt, meg nem használok, azt már mondtam. Ne keverjük a konzolt és a terminált, mert baromira nem ugyanaz. Konzolt senki nem használ, max. hibaelhárítás, meg minimál telepítés esetén, mikor nincs más.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Azért írom, hogy a minimál telepítés során. Ebbe az Arch is beletartozik, meg a Gentoo, Debian minimal netinstall, Alpine, de a Fedorát is lehet opcionálisan ilyen módszerrel telepíteni. Ezeknél nyilván szükségszerűség. Sok alap BSD-nél (Free, Open, Dragonfly, NetBSD) is szintén ez van (kivétel az eleve grafikusak, Midnight, Nomad, helloSystem, stb.), bár előbbieknek van telepítőjük, de azok is konzolosak, és nagyon kevés mindent tesznek fel, telepítés utáni rebootot követően azoknál sincs semmilyen grafikus felület, tty-ból kell felokoskodni dolgokat.

Bár lehet kicsit csalni, és másik gépről csinálni, terminálból, SSH-n keresztül, az játszik, de felesleges. Arra a pár percre, fél órára ki lehet bírni a tty-t, de mindennapos felhasználásnál agyrém, se Unicode támogatás, se 16-nál több szín, se GPU gyorsítás/vsync, se billentyűzetes sebességállítás, se semmi nincs benne, így az még nekem is önkínzás lenne. Tényleg én is csak akkor használok tty-t, ha minimál telepítés van, vagy pl. valami bug miatt nem fut se az X, se a Wayland, és valahogy debugolni kell (pl. GPU drivert), akkor pár percig ehhez a szükségmegoldáshoz nyúlok. Szökőévente egyszer van ilyenre szükség. Egyébként terminál, de modern formában, modern betűtípus, UTF-8, rendes Unicode támogatású font, szép, 24 bites színtémák egyes programok alá, felgyorsított billentyűzet (alapból minden OS alatt a billentyűzet lomhára van állítva, lassan ismétel, de állítható), régen még transzparenciát és/vagy elmosást (kvázi Areo-effekt) is tettem a terminál alá, de arról leszoktam, mert a terminálos tartalom olvasását, áttekinthetőségét megnehezíti, meg ellene hat néhány színtémának. Amiket nem használok, azok a ligatúrák, képrajzolás (Sixel, Kitty-protokoll, uberzug, stb.), utóbbi szerintem felesleges grafikus felületen, arra nyílik új tiling ablak a terminál mellé, abba is ugyanolyan jók a képek. Esetleg tmux-szal lehet még vegyíteni a terminálos élvezeteket, de azt szintén nagyrészt kiváltja nálam a tiling WM, a csempéket nem a terminálban nyitom, hanem az ablakkezelőben, kb. ugyanazt a hatást éri el.

Egyébként tty alatt is bekapcsolhatók extrák, pl. használható magyar vagy más nemzeti kiosztás, állítható felbontás, beizzítható kicsit modernebb betűtípus (pl. Terminus), nagyon korlátozottan, de a billentyűzet sebessége is állítható valamennyire, de a grafikus terminált sose fogja utolérni kényelemben, fapados marad.

Amire még megérheti tty-t használni, azok a kritikus rendszerműveletek. Pl. ha valaki egy nagy rendszerfrissítést tol le, és pl. nem akarja, hogy véletlenül bezárja azt a terminált, amiben fut, vagy az X crashelése elvigye, és ne fusson le teljesen a művelet, akkor tty-ból biztonságosabb indítani, de ez pótolható megint, ha terminálban tmux, screen, hasonló megoldással session-ben futtatják, akkor se szakad meg.

Egyébként el sem hinnétek, hogy terminálból szinte minden megcsinálható, még grafikus kimenetű feladatok is. Pl. képmegjelenítés (sxiv, nsxiv, imv, feh), videólejátszás (mpv, mplayer, ffplay), audiólejátszás (mpv, cmus, mpd kliensek, még kvázi grafikus Unicode vizualizáció is lehetséges, stb), grafikus doksiszerkesztés (plain text forráskód alapján, TeX, LaTeX, groff, markdown + pandoc, PostScript-kódolás, közben egy élő frissítésre képes pdf-nézőt be lehet állítani, ami megjeleníti grafikusan az eredményt), még a LibreOffice-nak is van CLI backendje, kottaszerkesztés (Lilypond, a fent említett pdf-es módszerrel), OpenSCAD (itt is látszik a lerenderelt grafikus kimenet), képmanipulálás ImageMagick-kel. Audió/videó felvételrögzítés is megoldható (pl. ffmpeg), e-mail-ezés (mutt, neomutt, alpine, aerc, mailx), alkalmazások indítására menü, feladatkezelés (htop, btop++, glances, stb.), RSS olvasás (newsboat), táblázatkezelés (sc, scim, R, diagrammok, ábrák GNU plottal), fájlkezelés, tömörítés, konvertálás fájlformátumok között, Androidos teló kezelése (adb, MTP mount + bármelyik terminális fájlkezelő), optikai lemez olvasása, lejátszása, grabbelése, kiírása, miegymás. Számológépnek se kell GUI, calc, python, bc, octave, dc ugyanolyan szépen számol terminálban, még jobb is, mert nem egérrel kell nyomkodni a gombokat, hanem közvetlenül, és könnyeben is javítható az elgépelés, van normális history-kezelés, végtelen precízió (orbitálisan nagy számokat, meg a kicsiket is kezelik, akárhánymillió tizedes jegyig, ezt a szintet számológépek nem bírják). Az mpv, Zathura (mupdf, xpdf), OpenSCAD, stb. se grafikus, mert van ugyan grafikus kimenetük, de nem hagyományos GUI alkalmazások, nincs grafikus toolkit ablakuk, menüjük, hanem egyfajta framebufferként használnak egy ablakot (amit értelem szerűen ki lehet nagyítani teljes képernyőre is). A legtöbb játék se GUI-s, hanem egy grafikus bufferbe nyomják bele a grafikus képet. Rendszeradminisztrációhoz sem kell feltétlen VNC, RDP, spéci távfelügyeleti alkalmazás, desktop sharing, stb., kiváló rá terminálból az SSH, ha kulturált rendszerről van szó (nem szutyok Windows például).

Amihez tényleg kell GUI, és az átlag felhasználó se ússza meg, az a böngészés, azt sajnos megoldották a soy/webdevek, hogy ne menjen se tty-ból, se terminálból, hanem kelljen egy full JS bloat, mainstream GUI böngésző. A másik, hogy sok játékhoz kell a grafikus launcher sajnos Steam, Epic, stb., ez is egy buzi trend lett. Sok zeneszoftver/DAW is úgy van megírva, hogy kell neki sajnos a GUI, abból is általában valami bloatabb toolkit (tipikusan Qt, de sokszor még Jack-et is igényelnek). A másik ahol kell a GUI, az random pixelre pontos grafikus munka (digitális rajzolás, retusálás, precíz videóvágás, effektezés, vektoros grafika finomhangolása, stb.), de ez utóbbi feladatokat nem nagyon végeznek átlagosabb felhasználók.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

@FeriX :

felraktam repóból a far managert (amikor win-eztem 2000 előtt használtam én ezt)

negyedórás keresgetés után pár dolgot nem tudok megoldani (plugint nem keresgettem):

- el lehet alul a parancssort tüntetni? - ezt az mc-n mindig megcsinálom hogy a könyvtárban a fájlnevet gépelve "ráugorjon".

parancsot csak ctr+o utan adok ki.

- az egyik panel-beli dir-t megnyitni a másik panelben (alt+i az mc ben)

- szimbolikus linket létrehozni az aktuális file/dir-re a másik panelben azonos névvel (ctr+x+s az mc ben)

- (nincs julia syntax-highlight alapban)

rengeteg opciója van aminek a tizedét sem értem/használom, az mcedit-hez képest a működő ctr+C/V kopipaszt az tetszik...

ncs

( NevemTeve | 2025. 01. 14., k – 20:09 )

Szerkesztve: 2025. 01. 14., k – 20:35

No most reprodukáltam valami hasonlót, Right / Shell Link / hibáshostnév

GLib-CRITICAL **: 20:06:59.322: g_string_free: assertion 'string != NULL' failed

mc-4.8.32

-    g_string_free (shell_super->scr_env, TRUE);
+    if (shell_super->scr_env) {
+        g_string_free (shell_super->scr_env, TRUE);
+        shell_super->scr_env= NULL;
+    }

Ahogy már fentebb említettem, ez a hiba nem jött volna létre, ha nem lennének olyan cukipofa függvények, amik nem csapnak a kezünkre, ha NULL-t adunk paraméterként: ebből fakadt az a hibás intuíció, hogy ellenőrizetlenül hívhatjuk meg a g_string_free-t is.

( transitive | 2025. 01. 15., sze – 07:30 )

Szeretem az mc-t, állandóan használom is, de azért van baja. Ami legjobban zavar, hogy induláskor csinál vmi gethostbyname-et vagy hasonlót (anno strace-eltem, de már elfelejtettem), azaz ha nincs hálózat, vagy épp lerohadóban van, akkor 5-10mp-re blokkol. Namost nekem gyorsbillentyűn van a MATE Terminal + mc, és baromira zavar, hogy 5-10mp-cet kell várni, hogy egyáltalán elinduljon.

Nem tudom, más is megfigyelte-e ezt? Nem jártam annyira utána, mert napi munka után már nem nagyon van kedvem az mc kódot túrni... lehet, hogy ha kézzel újrafordítanám megfelelő configure paraméterekkel, akkor kikerülne belőle ez a feature...

Ezt konkrétan nem, de olyant igen, hogyha rosszalkodik a hálózat, akkor az sftp kapcsolódáskor lefagy, megjelenik egy piros hibaüzenet ablak, és nem lehet semmit sem csinálni. Az egyetlen megoldás az mc-t futtató terminálablak kill-elése.
Egyébként nem ez az egyetlen, máskor is tapasztaltam már, hogy valamilyen piros hibaüzenet ablak felugrása után lefagy, és semmilyen billentyűt nem fogad el, csak a terminál kilövése játszik onnantól (szóval nem tudom, hogy a hálózatkezelésében van-e a hiba vagy a hibaablak kezelésében, mindesetre kiakad).

Én ezt nem tapasztalom Arch-on. Most direkt kipróbáltam, lekapcsolódtam a Wi-Fi-ről, és ugyanolyan gyorsan indult az mc, mint normálisan, pár ms alatt, semmi 5-10 mp-es lag. Milyen disztrón próbáljátok?

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Több oka van, röviden összefoglalva:

  • egyszerűen nem érdekel: amíg munkára (C fejlesztés) tudom használni, és nem kotlik meg a rendszer, addig nem piszkálom;
  • munkaidőben nincs időm az upgrade-del szarakodni, szabadidőmet meg sajnálom rá;
    • tudom, lehet automatizálni, de én control freak vagyok, és akkor frissüljön, amikor én mondom neki;
      • 1-2 éve rászántam az időmet és frissítettem;
  • idegesít, ha folyton változnak a dolgok, ha összeállt a rendszer, akkor minek piszkáljam? Persze, sérülékenységek stb.
  • az is zavar, hogy az egyre újabb verziók egyre lassabbak, bloatabbak. A gép Fedora 20-szal még szépen ment, 36-tal meg érezhetően döcög, és most nem a webes "élményről" beszélek, hanem az általános bootolásról, működési gyorsaságról, stb;

Légyszi ne kezdjük el, h milyen felelőtlen vagyok és az én gépemen keresztül intézi az összes hacker a botnetjeinek a vezérlését stb... :D

Nem hinném, hogy feltétlen meghekkelnek, de ezzel a lusta hozzáállással később meg fogod magad szivatni, valami hirtelen szükségessé váló csomagnak egyszer csak nem lesz kielégíthető a függősége, stb.. Ilyen szinten gáz csak. Időd arra van, amire szánsz. Főleg egy C fejlesztés nem tűnik annyira bonyolult környezetnek, hogy valaki nem merjen hozzányúlni.

Ja, a Fedora sztenderd, DE-s kiadási egyre bloatabbak, de tudod csak egy ablakkezelővel is használni, meg kigyomlált service-ekkel, vagy egy minimalistább disztrót. Full rollingnál nem kell sok idő az upgrade-re, mert nincs upgrade, sima update-ek vannak, a csomagok egyesével, szép lassan újulnak meg.

Ha nem szeretsz gyakran frissíteni, akkor a Fedora amúgy is egy elég rossz választás. Debian, vagy Ubuntu LTS Pro-ként, aztán elvagy vele több évig, ha nem zavarnak az elavuló verziók. Frissítés ezekhez is jön ki, de nem upgrade-ként, csak néhány csomag frissül itt-ott, főverziót nem váltanak a csomagok.

Az az egy valóban jogos érv, hogy nem szereted a változásokat, de azt el tudod kerülni, ha nem a mainstream-ben mozogsz, ahol a DE-ket meg sok GUI-s dolgot fél-egy évenként átültetnek új toolkitre, meg átdizájnloják a felületét, ez engem is zavar, emiatt kerülöm is ezeket. Anno a Gnome2-Gnome3 meg KDE4-KDE5 váltás is beszivatott, azóta inkább minimalistább eszközöknél maradok, főleg terminálos megoldásoknál, azokat sose tervezik át.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

de ezzel a lusta hozzáállással később meg fogod magad szivatni, valami hirtelen szükségessé váló csomagnak egyszer csak nem lesz kielégíthető a függősége

Inkább úgy jártam, hogy kellett volna valami csomag, és vagy nem volt, vagy túl régi volt. Amúgy nem feltétlen vagyok rest magamnak fordítani :) bár az is jó nagy szívás tud lenni.

Főleg egy C fejlesztés nem tűnik annyira bonyolult környezetnek, hogy valaki nem merjen hozzányúlni.

Szerencsére nem az, nagyrészt mert magamnak így alakítottam ki. MATE, KATE, make, gcc, mc, toolchainek. Igaz, magán dolgokra is használom a gépet, onnan is jön azért egy  rakat csomag.

Régen Arch-oztam, ott engem beszivatott a rolling release, nem elég, h állandóan szedegette le az újabb csomagokat (ez pl. engem nagyon zavar), össze is omlott és a fél rendszer nem működött. Akkor elhagytam az Arch-ot. Azóta is mindenki mástól csak jót hallottam felőle, de nem akarok ismét kísérletezni vele. Amúgy igen jó wikije van.

Ebben is igazad van, valószínűleg más disztrót kéne használnom a bloatosodás és a "stabilitás" miatt. Debian eszembe jutott, vagy Linux Mint, van még 1-2 jónak tűnő alternatíva. MATE vagy Enlightenment DE. Csak ugye akkor a váltással megy el egy csomó idő, és ezt most még sajnálom rá - szabadidőmben nem a gép előtt akarok ülni, munkaidőben meg annyi dolgom van, h nincs egy üres 0.5-1 napom csak a laptopok abajgatására... talán majd nyáron, szabadság alatt.

Mert mindenki szereti elfelejteni a /etc/hosts fájlt okszerűen kitölteni.

Ha nem szeretnéd a lassulást:

echo "127.0.1.1  $(hostname -f) $(hostname)" | sudo tee -a /etc/hosts >/dev/null

A gethostbyname ilyenkor visszadobja neki, hogy 127.0.1.1 és mindenki boldog.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

A legtöbb mainstream disztró ezt megteszi default, az localhost-hoz meg a $(hostname)-hez hozzárendelik a 127.0.0.1-et meg az IPv6-os párját is. Nem mintha annyira számítana, nálam Arch-on kis sincs töltve, létezik a /etc/hosts, de csak fejléces megjegyzés van benne kikommentelve. Gondolom ezt a systemd megoldja, hogy a hálózatnál más módon is hozzárendeli a localhost-hoz, hostname-hez a helyi loopback címet, ahogy pl. a DNS-t is saját hatáskörben kezeli.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Ja, pont ez a baja, amit mindig írok, de sokan képtelenek megérteni. Félre ne érts, én a régi unixos módszert preferálnám, /etc/host, cron, egyszerű symlink-ekkel működő SysV init, szöveges log (nem ez a journalctl-es bináris baromság), stb.. Viszont másik oldalról megvan az előnye a systemd-nek, pl. sokkal gyorsabb boot, meg ilyen localhost/DNS kérdésekben normiknak meg tudja könnyíteni az életét, hogy automatán lekezel mindent, és nekik nem kell konfigfájlokat szerkeszteni, meg terminálhoz nyúlni, amitől nagyon szoktak félni, teljesen ki tudnak tőle térni a hitükből, ha valami nem GUI-s.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Igen, elvi síkon is baj van vele, hogy át akarja venni az OS és kernel minden funkcióját. Pedig a Unix-filozófia miatt modulárisnak kéne lennie, minden modulnak cserélhetőnek, elhagyhatónak.

Pont ez a legnagyobb baj vele, hogy egy nagy monolitikus valami, ami rá is van kényszerítve mindenkire, mert a sok hülye fejlesztő beemeli függőségnek. Ráadásul évről-évre hízik is, a logind, journald, udevd, meg a localectl, hostnamectl, netctl, DNS kezelés mellé bejött a homed, ooemd, polkitd, bővül tovább a szolgáltatásainak a köre.

Ugyanez igaz a linuxos hangrendszerekre. Eleinte a sndio egész egyszerű unixos, BSD-s megoldás volt, jött rá a bonyolult ALSA, de ez még érthető volt, normálisan le lett kezelve a kernelben, de ez se volt elég, a Red Hat nekiállt bloatosítani, JACK, Pulseaudio, de már tovább léptek a még bloatabb utódára, ami már egy rakás dolgot futtat, Pipewire, Wireplumber, Pipewire-pulse, mindenféle portálokat is kezel, már nem csak hangot, de videót, kamerát, streameket mixel, USB-s LED-es hátvakaró eszközök meghajtásával a hátad vakarja, stb..

Ezek pedig elég sokat bloatosítottak a Linuxon, mikor együtt fut a systemd meg Pipewire sok modulja, szolgáltatása, akkor meg tudna együtt enni 100-200 mega extra memóriát, főleg régi gépeken gond, amelyekben még nem volt elég RAM, meg gyengébb a CPU, nem kicsit be tud tőle térdelni.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

A polkitet tessék békénhagyni, az bőven a SystemD előtt is létezett, és annyira nem is rossz irány a jogosultságkezelésre.

Amúgy a Pipewire pont a moduláris, lecserélhető dolgok példája, a PipeWire-Pulse segítségével képes leváltani a PulseAudio-t úgy, hogy kompatiiblis marad a pulse-only appokkal.

És őszintén szólva, az ALSA-nak pont az volt a baja, hogy (mai szemmel nézve) kicsi és egyszerű volt, eljött a pont, amikor már nem lehetett tovább bonyolítani, mert akkor nem lett volna kicsi és egyszerű. Szophatsz ugyan most is pulseaudio/pipewire nélkül mondjuk egy bluetooth füles beállításával, csak épp nem éri meg a szopást.

Régebbi gépen meg régebbi Linuxot kell futtatni, vagy olyan disztrót kell keresni, ahol opcionális a SytemD meg a pulseaudio. Például a Gentoo-ban ezeket mind elég jól testre tudod szabni, más kérdés,  hogy mekkora szopáshalommal fogsz szembesülni, ha valami olyan dolgot szeretnél, ami a "régi gép" korában még nem is létező technológia volt.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Ja, pont ez a baja, amit mindig írok, de sokan képtelenek megérteni.

+1. Letért az egy igaz UNIX útról: "egy program egy dolgot csináljon, de azt jól". Helyette lett belőle ez a böszme förmedvény, amivel még EFI rootkit is gyönnyedén terjeszthető.

megvan az előnye a systemd-nek, pl. sokkal gyorsabb boot

Ezt ellenben erősen megkérdőjelezném.

Normál, tipikus működés mellett a SysV (pár symlink) nagyságrendekkel gyorsabb. Nyilván előfordulhat olyan elcseszett konfiguráció, ahol kismillió egymástól függő service-t kell indítani, de nem ez a jellemző, és azért büntetni a felhasználók 99%-át, mert 1%-nak speciális konfigja van, hát, enyhén szólva is faszság a köbön.

Azt azért be kell látni, hogy egy tipikus asztali gépen vagy szerveren max. ha 10 szolgáltatás indul bootkor a háttérben, ehhez meg bőven elég a sorszámozott symlink, sőt, még jóval gyorsabb is, mint bármi más. Őszintén, tegye fel a kezét, aki valaha is nem tudta megoldani az asztali gépén vagy szerverén a rendszerindulást SySV-vel! Nekem 20 év használat alatt sem volt soha gondom vele (talán egyszer, 2000-es évek elején, amikor még én is, meg a debian is fiatalok voltunk, egyszer át kellett sorszámoznom egy symlinket, hogy ne párhuzamosan induljon, hanem csak miután egy másik lefutott).

Én annak idején üzemeltettem elég bonyolult rendszereket is SysV alapú init rendszerekkel, OpenRC-vel és Upstart-tal is, soha nem éreztem a szükségét egy akkora mocskos nagy bloatnak, mint ami ma a SystemD. Pedig volt, hogy jó pár egymásra épülő szolgáltatás függőségi fáját kellett kirakni - de ki lehetett, és nem is volt olyan sok szopás. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Hát, ezt most nem tudtam reprodukálni, nem látom a 'strace'-vel, hogy hozzányúlna a /etc/hosts-hoz.

Ugyanakkor igaz, hogy emlékezni vélek lassulási anomáliákra, például volt, amikor a gpm-mel vívott nemes harcot a mc... https://hup.hu/node/132732

strace mutatná azért, de csak ilyet vélek látni:

connect(7, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3

És van pár gethostname (alias uname) ez igaz.

( Celtic v | 2025. 01. 16., cs – 16:33 )

Igen, ha nem volt hálózat, nálam meg bent volt a bash_profile-ban az mc, tudtam káromkodni.

http://www.micros~1
Rekurzió: lásd rekurzió.

( Raynes v | 2025. 01. 27., h – 14:21 )

A témánál maradva jelezném, hogy kb. egy hete frissült az mc, a 4.8.33-as verzióban már nincs meg ez a bug, gondolom ebbe már integrálva lett az a javítás, amit ez a hozzászólás említ.

“The world runs on Excel spreadsheets.” (Dylan Beattie)