Azt kötve hiszem, hogy a TC64 Wine-nal kevesebbet fogyaszt, mint a DC. Bár ez nem a TC meg a Wine hibája külön, hanem abból adódik, hogy egy natív és egy nem natív programot vetünk össze, almát a körtével.
Egyszer majd nézd meg magadnak. ? Hinni a templomban kell.
Egyébként látszik nem vagy otthon Linuxban, mert tudnád, hogy TC-t semmiképp nem érdemes Linux alatt használni, pedig jól fut, de sok unixos-linuxos sajátosságot nem tud lekezelni, pl. linuxos ACL-ek, UGO adatok, linkek, pipe-ok, fifo-k, eszközfájlok, stb..
Double Commander ezeket hogyan kezeli le, a végtelenciklusos lefagyásain kívül? Tudok vele /dev/sda alól olvasni? Nem tudok. Van bármi olyan funkcionalitása, amivel a TC-hez képest ki tudnám használni a linkekhez, fifo-khoz, eszközfájlokhoz való hozzáférést? WINE láthatóvá tudja tenni a symlinkeket az alkalmazások felé, a TC pedig képes ezeket látni, értelmezni. A fájlattribútumokra benyomsz valami attribútum editort, ami Alt+Enter-re képes megnyílni. Látszik, nem vagy otthon a Windows-os alkalmazások Linux-on való futtatásában (sem).
Egyébként nem engem kell meggyőznöd, hogy nem érdemes, mert XP-n használom a Total Commandert. Neked kell mp3DirectCut-ot futtatnod Linuxon, mert a szuboptimálisnál szuboptimálisabb bloat szutykaiddal nem vagy képes egy egyszerű feladatot megoldani (framecopy). ?
1) Windows only
Cserébe WINE-nal gyorsabban és kevesebb erőforrásból fut, mint más, azonos funkcionalitással bíró natív™ megoldások (egyetlen ilyen van, a Double Commander).
2) x86/x86_64 only (igen van ARM/androidos verzió, de az egy vicc, csak a nevében TC, már pedig ez fontos, mert egyre többen használnak ARM-es és RISC-V-s gépet)
Egyre többen használnak Windows-os ARM és RISC-V gépet, azon a Windows-on pedig fut az x86 verzió, ha nem is natívan, de jóval hatékonyabban, mint bármelyik bloated framework-ös fájlkezelő.
3) zárt kódú
4) egyetlen fejlesztő fejleszti saját maga, ha véletlen elüti a busz, vagy szívinfarktust kap, magával viszi a kódot a sírba, ha meg megunja a fejlesztést, nyugdíjba megy vagy elhal a projekt, vagy megveszi valami nagyobb cég, aki lezülleszti, így a jövője nem biztosítható
Eddig még nem unta meg és egyébként semmi baj nem történik, ha nem fejlesztik tovább, mert igazából már kész van. Apróbb feature-öket szokott kapni, meg javításokat és ez jól is van így. Továbbá, lehet, hogy benne van a végrendeletében, hogy open-source lesz, ha meghal.
5) elmaradott nyelven, elmaradott toolsettel (Delphi) van fejlesztve, de ez sajnos a legtöbb commander-típusú GUI fájlkezelőre igaz
Ezek nem elmaradott nyelvek, sőt bizonyos szempontból sokkal szélesebb körben értelmezett kompatíbilitást tesznek lehetővé out-of-the-box, mint a Rust, az Electron-bloat és a többi divatszutyok. A Total Commander 32-bites változata Windows 95 és Windows 10 között (inkluzíve) bármelyik rendszeren ugyanúgy elindul és működik. Ezt egy builddel el lehet érni. A 64-bites változat pedig XP64 és Windows 11 között. Kíváncsi vagyok mondjuk egy Krusader képes lenne-e egy 90-es vagy 2000-es években kiadott Linux rendszeren elindulni. Lófaszt lenne képes. A fél világot újra kéne forgatni, meg backportolni kéne hozzá.
nem is értem miért ragaszkodnak a Pascal-hoz, Delphihez
Mert nem fejlődésmániás, agymosott babzsákfejlesztők, akik ötévente újraírnak mindent az aktuális divatnyelven.
kb. 2-3 évtizede leáldozott azoknak
Nincs olyan, hogy "leáldozott" egy programnyelvnek, fogalmilag értelmezhetetlen. Amíg készülnek benne programok és van hozzá működő compiler, addig van létjogosultsága. Mindkettő igaz jelenleg, a Lazarusra és a Delphire is, ráadásul mindkettőt fejlesztik is.
6) nem tud vi/vim gyorsbillentyűket
Látszik, hogy nem vagy otthon a Total Commanderben. Bármilyen gyorsbillentyűt bekonfigolhatsz magadnak a "Misc." alatt.
7) bonyás hozzá plugint írni.
Nem az, csak ehhez sem értesz. Plugin SDK: https://github.com/ghisler
Szépen le van doksizva minden (docs mappa) és ha ez nem lenne elég, akkor https://totalcmd.net/directory/developer.html
1) C-ben van, nincs kötve architektúrához, OS-hez, ezért minden létező OS-re létezik, lefordítható
Mármint amire van compiler és minden lib, include stb. portolva van rá, amit használ.
2) tud vi/vim gyorsbillentyűket, ami meggyorsítja a műveleteket, fájlok, mappák között mozgást, beleintegrálható fzf, saját scriptek
Total Commanderbe is integrálhatsz bármi ilyesmit. Az, hogy nem tudod, hogy kell, nem jelenti azt, hogy nem tudja.
3) plugint írni rém egyszerű, csak egy shell scriptet vagy egy egy soros parancsot be lehet neki drótozni gyorsbillentyűre a konfigban, némi %i, %f, változóval, és annyi
Kevered a pluginokat és a shell scripteket. Total Commanderbe is olyan scriptet rendelsz a billentyűparancsod mellé, amilyet akarsz.
4) nem kell neki GUI sem, megy Windows Parancssorban, Windows Terminal-ban, Powershellben, *nix POSIX shellekben, ssh/soros/debug-konzolon, tty-on, stb..
Ezt én nem tekintem előnynek. Egy GUI, ha jól össze van rakva, rugalmasabb és kompaktabb tud lenni, mint egy TUI.
5) egyszerűbb, nincs telepakolva felesleges extrákkal, FTP kezelés, viewer, editor, meg ilyenek, arra van külön megoldás, vagy bedrótozható scripttel, mounttal.
Ezek nem felesleges extrák, hanem alapdolgok egy kétpaneles fájlkezelőben, lásd Norton Commander, ami az elődje volt mindegyiknek.