"console" apps you like

[williwaw]

many apps have been developed to work in console mode. ie with out X running. quite a few are mature apps still being maintained or in ongoing development.

mc (file manager) and mutt (email client) work well as any gui app for me.

what are some of the other favorites out there?

[rockedge]

along with mc I use nano, both are very handy running remotely

[radames]

Hi there!

My all time favorites are the text editor ne, the music player moc, the irc client of Emacs Erc, the download manager axel and the bittorrent client rtorrent.

[MochiMoppel]

top (process viewer)

[01101001b]

ncdu (to check what is "eating" my disk space )
htop (for ram monitoring and process managing)
lynx (text web browser)
moc music player (EDIT: I found it today )

[sarahk99]

many apps have been developed to work in console mode. ie with out X running. quite a few are mature apps still being maintained or in ongoing development and descriptive essay writing help.

mc (file manager) and mutt (email client) work well as any gui app for me.

what are some of the other favorites out there?

nmon - alternative system administrator tool for server tuning!

[JASpup]

htop is better than nothing, but I really like the gui resource monitors

have recently discovered lxtask uses fewer system resources than conky

[user1111]

Not much you can actually run in a console, as that doesn't even have job control (ctrl-z to suspend, bg, fg, jobs, disown), you need a pseudo terminal for that (setsid cttyhack /bin/sh). With a ptty I like vi, htop, mc, tar, ssh/sshfs, tmux. ssh allows me to connect to other systems and run the likes of mutt (email), irrsi/weechat (irc), or cvlc, calcurse (diary), and if its a framebuffer based terminal ... fbvnc (so I can vnc into full gui desktops to run chrome, libreoffice ...etc.). Or if kvm is available, run qemu to boot a iso within kernel space and vnc into that (so no X running in userspace, but having a full gui desktop available locally in kernel space).

Code: Select all

ISO=Fatdog64-811.iso
QEMU_AUDIO_DRV=alsa qemu-system-x86_64 -vnc :0 -cpu host -machine type=pc,accel=kvm -soundhw ac97 -monitor pty -k en-gb -smp 2 -boot d -vga std -enable-kvm -m 1536 -cdrom $ISO &
fbvnc localhost

[sc0ttman]

First, let's start with the terminals themselves:

mlterm terminal emulator:
- renders much faster than Xterm and URxvt (cat a huge UTF-8 file of all kinds of languages.. mlterm is waaaay faster to render)
- GUI config menus built-in (Ctrl-left click ... Ctrl-right-click)
- supports tabs,
- supports horizontal & vertical splits
- works as a daemon/backend (for sharing/resuming sessions, etc)
- great UTF-8 support
- great input support (so it's the preferred terminal for many Chinese, Japanese, etc)
- even supports correct alignment of RTL languages! ..very few others do..
- config files easier than .Xresources and .Xdefaults (used by Xterm, URxvt, etc)
- works in frame buffer - you get all these features even without X

Then Xterm:
- good all rounder, can be setup nice, eventually, no tabs, simple

$HOME/.inputrc - many of your terminal key bindings and TAB completion features can be setup here

w3m - console web browser, with inline images support, can dump websites to plain text (super useful)

lynx - like w3m above, without images, nicer menus, can also dump sites to plain text

micro - modern text editor in the terminal (define whatever key bindings you like, supports tabs, linters, all sorts..)

ranger - powerful file manager, uses 3 "miller columns" as default layout, like Finder on Mac

bash-completions - get it from package manager or github .. makes life so much easier

fzf - command line fuzzy filter/picker.. powerful, customisable, can do file previews of stuff in filterable list

man - man pages!!
---------------

I've setup mlterm to do "splits" and "tabs" using with Mac-like keybindings - very easy to whizz around - especially when combined with JWM hotkeys for moving windows to each side of the screen, like WinKey+left and WinKey+right..

I've used w3m to good effect - to make console-based reddit, github and man page readers (will add them to forum soon)...

I've used fzf to make custom file managers, a Pkg frontend, fast file openers, etc.. In my dotfiles (https://gitlab.com/sc0ttj/dotfiles)

--------

About man pages

I've never had any luck with Puppys custom replacement for the man command, called `pman` - it just open a browser and puts me in a duckduckgo seach page :/

Also, it doesn't display man pages relevant to the version of packages you have installed - lot of the man pages are old.

So, I replaced it in my Puppy with a custom-made w3m manpage downloader script..

Now I really like man pages!!

Stuff like:

man intro.1 # find out about Section 1 (first section)
man intro.8 # find out about Section 8 (last section)

man ffmpeg.1 # get ffmpeg manpage from Section 1
man -H ffmpeg.1 # view it as HTML

Section 3 is good for C library stuff, section 6 for emulators and third-party packages.

[williams2]

Xterm ... no tabs, simple

I disable urxvt tabs by editing .Xdefaults or .Xresources changing this:

Code: Select all

!urxvt.perl-ext-common: default,selection-to-clipboard,tabbed,matcher

to this:

Code: Select all

!urxvt.perl-ext-common: default,selection-to-clipboard,matcher

Actually, I disable most of the perl extensions except selection-to-clipboard (I like that extension)

Code: Select all

urxvt.perl-ext-common: selection-to-clipboard

[williwaw]

Not much you can actually run in a console, as that doesn't even have job control (ctrl-z to suspend, bg, fg, jobs, disown), you need a pseudo terminal for that (setsid cttyhack /bin/sh). With a ptty I like vi, htop, mc, tar, ssh/sshfs, tmux. ssh allows me to connect to other systems and run the likes of mutt (email), irrsi/weechat (irc), or cvlc, calcurse (diary),

ruwoof,
Have you any mouse support in console? It's been a while, but I had it in a *bsd years back in order to utilize an old A-30 w/128mb ram. Groff & links (latest release August 2020) were used in addition to apps mentioned above. That was before I found puppy of course.
How do you install ptty? (I am currently using a debian buster based flavor and do not see it in PPM)

[user1111]

I compile a kernel with framebuffer, and at bootup include vga=ask (or a actual mode once one has been identified) - so init is initially running as a 'console' in framebuffer mode. exec setsid cttyhack transforms that console to ptty (so you have job control, can run ssh, mc ...etc. that otherwise in console mode wont work).

https://git.busybox.net/busybox/tree/shell/cttyhack.c

That alone could be 'good enough', but I comment that out and instead hand PID 1 over to busybox's init (create a sym link in /sbin for init that links to busybox (cd /sbin;ln -s /bin/busybox init). And then have exec /sbin/init as the last line in init. Or something like that.

I have no need for a mouse as at most I'll just ssh into other boxes to run tmux/irssi/mutt/calcurse/mc/htop ...etc. where no mouse is required. When I vnc into a gui desktop system the mouse is automatically activated (managed by fbvnc and the server, or tigervnc/whatever).

One step up from that is to boot a XVesa type desktop such as tinycore, add (firmware for wifi ..etc.), ssh and tigervnc into that, and then boot tinycore, wifi net connect, and then vnc into a Fatdog server/whatever for a full Fatdog desktop. The terminal in the following is my tinycore 'top' as are the window decorations/borders, the rest is Fatdog.

screenshot_1101005615.jpg (167.71 KiB) Viewed 1406 times

So in effect tinycore is providing the boot system, vmlinux, initrd that enables wifi net connection and provides a framebuffer, and then vnc into another box that provides all of the gui desktop/functionality (chrome, libre office ...etc.), but where that 'server' feeds the display to the tinycores framebuffer instead of a directly connected monitor/display (in my case I have it feeding both, i.e. the server is also connected to the TV so the same screen is seen on both, and if I vnc in from my android mobile phone (realvnc) - then the same screen is seen (and can be controlled by) all three).

Remove tinycore from the above, replacing it with a minimal boot system do to perform the same functionality as booting/wifi net connect/ssh/vnc ... and that's pretty much my minimal boot system (just vmlinuz with built in initrd, that's around 5.2MB in size).

[williwaw]

@ruwoof
quite the set-up you have going! As a single user on a single machine, I think using a terminal emulator in X will work for a while longer. fonts are easier that way now that most emulators have a gui for config.

@sc0ttman
first install of mlterm did not include the gui config menu, but mlterm-tools does. thanks.

[user1111]

As a single user on a single machine, I think using a terminal emulator in X will work for a while longer. fonts are easier that way now that most emulators have a gui for config.

I do quite a bit more cli nowadays, finding https just a bit too overwhelming on the intrusive/advertisement front. And yes, a terminal within X is nice for the flexibility. syncterm is a nice alternative to xterm IMO.

syncterm.jpg (124.11 KiB) Viewed 1379 times

Apparently some of the big name individuals making big money out of social media, intentionally bar their kids from using it - due to the depression tendencies that can be induced. Smaller more focused communal groups are much happier places to be, and without all of the tracking, adverts and prostituting oneself as "payment".

[wiak]

I do quite a bit more cli nowadays, finding https just a bit too overwhelming on the intrusive/advertisement front. And yes, a terminal within X is nice for the flexibility. syncterm is a nice alternative to xterm IMO.

It's a very long time since I ever used BBS per se, and don't expect to now. But syncterm looks interesting as a terminal. However, what advantage does it have over something like Lxterminal (when using X) and common openssh client run inside that when you need to access ssh server?

[user1111]

syncterms predominant benefit is its support for viewing BBS content, otherwise I mostly use xterm

Presently booted to a 5.2MB vmlinux with integral initrd on my laptop, I have set my server up to boot a fatdog desktop within which that boots another fatdog within kvm (qemu), which normally blocks accessing its IP from the host - but it can see out (ssh to the host), so a reverse ssh port forward enables me to tunnel vnc to the host, into which I set up a compressed ssh tunnel from the remote laptop to the server host systems reverse ssh port to where the guests desktop is vnc served.

Running surprisingly well.

s.jpg (155.67 KiB) Viewed 1354 times

Watching a youtube, running Libre Calc, and posting this. Laptop top shows less than 1% cpu loading, but the servers host is running quite heavy, guest is relatively light.

For that type of setup, I tend to just load up xterm. If in another terminal (ctrl-alt-F2 for instance) if that is connected to a BBS I tend to go with syncterm. ... Just choices.

In that qemu session, it can not see the hosts HDD, I have it running multi-session saves from a vHDD image, so boots from and saves to a virtual HDD, however that could be a actual iso with no saving possible, a form of container, with just that port being port forwarded so even if cracked the options would be limited (predominately network or router based attacks - so I have it separated on its own LAN segment).

PS cheated with the sound, whilst alsa is forwarded from the guest to the host, I have the host forwarding that to my headphones. Out and about that distance with be prohibitive, so sound would have to be forwarded by other means. Im using fbvnc which is very limited, I believe other choices of vnc do also cater for sound being included in the stream.

Much is semantics - you could say that my laptop is just running framebuffer cli (console) and running very cool, whilst having full gui desktop type functionality. The server host system could also be just cli - firing up the kvm qemu session in kernel space (I have it running X however so that I can also vnc into that, but only locally (LAN)).

[user1111]

BBS are very popular in places where they care about and appreciation their freedom - Russia and suchlike. The West increasingly has the population less caring about living in a open prison, where everything they do is monitored. Always on (always connected) facilitates constant monitoring. I believe here in the UK (London), its one if not the highest density of cameras monitoring. When the state knows where you are, where from you receive (and spend) your money and where all your wealth is stored, its no longer your wealth (or life) but a totally state controlled loan (life). Yet the vast majority have just accepted such loss of freedoms piecemeal.

[user1111]

It's a very long time since I ever used BBS per se, and don't expect to now.

My current project is a 10 line BBS setup - with a twist ... 10 (variable) vnc lines (ports) that directly drop into (the same) gui desktop, so in using vnc - accessible from many different devices/OS's. For the time being I'm using a fixed resolution of 800x600. Fundamentally that will be the chat/shared room, separate to that individual desktops could be made available.

s.jpg (129.08 KiB) Viewed 1332 times

That image is my laptop desktop - with two vnc sessions into the 'BBS' system. With one having had the mouse moved over the show desktop icon resulting in the 'show desktop' popup ... and where the other windows (line) sees the exact same.

Presently the 'BBS' desktop is a full Fatdog iso gui desktop, with the intent that would be refined down to being a more kiosk like desktop and additional functionality added in according to privilege levels (whether a web browser could be loaded/used etc.).

Discovered that with qemu (using kvm) not only can you instruct it to feed out to vnc (so the server can be headless/cli), but you can also multi-cast that to many vnc ports. vnc by default starts at port 5900 so -vnc :10 qemu switch for instance has that feeding port :5910 I've set qemu to serve ports :5900 to 5919 ...

Code: Select all

QEMU_AUDIO_DRV=alsa qemu-system-x86_64 -vnc :10 -vnc :11 -vnc :12 -vnc :13 -vnc :14 -vnc :15 -vnc :16 -vnc :17 -vnc :18 -vnc :19 -usbdevice tablet -cpu host -machine type=pc,accel=kvm -soundhw ac97 -monitor pty -k en-gb -smp 2 -boot d -vga std -enable-kvm -m 1536 -drive format=raw,file=vHDD.img &

The -usbdevice tablet switch is deprecated, but still works at better aligning the local mouse cursor and the remote cursor, such that in practice the integration with the local desktop is good, as good as if the remote desktop was local (seamless mouse control/integration). Swipe the mouse across the local desktop that includes in part swiping over the remote desktop window and there's no obvious misalignment of the cursor, at least not at 800x600 remote desktop resolution level (with high resolutions the copy-block (vnc) lag can reveal some 'two mouse pointers' appearance).

I'm using a raw virtual disk (image) for the time being, but later that could be moved over to use a ro iso with copy on write (and snapshots). With a raw image created using something like qemu-img create -f raw vHDD.img 2G you can mount that for easier modification/tweaking, i.e. once you've booted qemu using a iso and partitioned/formatted that 'disk', after having exited the qemu session you can run losetup -f to find the next free loop device, and if that's say /dev/loop2 then associate that to the vHDD ...
losetup /dev/loop2 vHDD.img
... map the partition to the loop device
kpart -a /dev/loop
... and then mount it
mkdir mp; mount /dev/mapper/loop2p1 mp

Later when done, to release it
umount mp
kpart -d /dev/loop2
losetup -d /dev/loop2

Best not to mount/modify it however when the vHDD.img is being used by qemu.

In my youth many spent time maintaining their own BBS's; Later gen's spent time creating their own desktop layouts (distros); Later still social media - Facebook etc. became the focus; But with centralisation that opened up depression due to too many being able to comment/insult etc. BBS's were much friendlier, more like actually entering into someone else's home. Yes all of the above is nothing new, can already be achieved via other means, but the added benefit IMO is that it doesn't involve having to pre-agree or directly call others, its still a drop in point where you might find others 'online' or not, small more sociable groups and under ones own control and without Big Brother regulating what you can see, say or do.

[wiak]

This isn't a console app per se, but another case of using vnc, but this time with virtualGL so that the graphics seen in my vncviewer (client) window are actually using the graphics acceleration provided by the computer that has vncserver running on it. Without virtualGL the local graphic rendering still gets done by the slow graphics card in the vncviewer (client) computer so everything graphics intensive runs then very slow, but with virtualGL running on the server machine, the hardware accelerated graphics card there does the graphics processing so can run, for example, games like supertuxkart that often require a more modern version of OpenGL than the local slow client machine itself can provide.

https://weedoglinux.rockedge.org/viewto ... p=263#p263

In attached image the running chromium browser and second desktop background is that of the server machine (running tigervncserver on DISPLAY :6 there). (Plus rufwoof's desktop appearing in that browser... gets confusing eh...!) My 8 year old son is also currently sitting using the server machine, but on DISPLAY :0 and logged-in as user weedog there (I'm logged in as root user on DISPLAY :6).

Just for the hell of it the second image shows additional full desktop login but this time to vncserver instance on DISPLAY :1 to which I'm logged in as normal user weedog (my son also still logged in also as user weedog but continuing to use DISPLAY :0)...

I could have posted this under the thread: "Show me your five desktops" though two of them are actually rufwoof's displayed on forum in Chromium browser...

[williwaw]

If one wished to utilize legacy laptops in a vnc envrionment such as presented above, does one just need apps that can be run in any puppy?

Would it be worthwhile to have a specialized puppy for the client?

Do the client and the server need the same OS?

[user1111]

VirtualGL works in Fatdog (also needed to install perl as that isn't installed by default in Fatdog). SuperTux worked, but not at the high frame rates you seem to have achieved, but that's likely because I haven't configured/run it correctly.

Thanks.

Compared to my setup of just a framebuffer cli on the client, vnc'd through a ssh tunnel with compression on ... and that's dead slow/unusable for playing tux. For my needs however the much lower network flow is appropriate for when out and about as VirtualGL seems to require local LAN type speeds/bandwidth. For instance I can browse and do other office type activities for around 0.2Mbs. Again though, start watching videos or other screens/windows that involve lots of RectCopy'ing (or whatever) ... and the network data flow can soar. Likely if VirtualGL was also being used for mostly static screens I suspect its net/data flow would also be low.

With framebuffer client and vnc that's portable, I can access the server from Windows, Linux, android phone ... anything that supports vnc, maybe even DOS), and I've gone more for the sharing the same desktop that all devices see/control, possibly at the same time.

[user1111]

Good grief. kernel 5.9 has gone from .2 to .6 about as quick as I can compile the kernel (not really, it only takes a few minutes for kernel compilation using my .config).

Decide to add in virtualisation into the latest build, which only expanded the vmlinuz relatively little, still in the mid 5MB region (with integral initrd). That boots to cli with framebuffer. With qemu files added in, that's a 15MB tar.xz filesize, but once loaded means that the cli system can boot kvm based qemu - such as a full Puppy/Fatdog gui desktop - but with no X actually running in the host cli.

I've never tried it but I believe a 32 bit host can emulate a 64 bit guest under qemu. Likely slow though. In the past I have emulated twice as many cores and more ram than what was actually available within qemu and within reasonable limits it still ran reasonably well (4 cores on a 2 core system for instance).

Another nice aspect is that qemu sort of standardises the 'hardware'.

I'm running qemu outputting to vnc and then using a cli based framebuffer vnc to attach to that, so not sure how the likes of SuperTuxKart might run (yet to give it a go).

EDIT:

... Might work. This is on a 2GB ram system, booted to cli, kvm qemu booted fatdog iso, with virtualgl and perl then installed from the repo, and then sshfs mounted another box on which the tux kart sfs was loaded from, to then setup and run tux. Whilst the desktop is snappy, no different to sitting at a normal booted gui desktop, tux is very slow. Very much suspect its not the graphics side, but rather simply just the absence of adequate ram. Frankly surprised it didn"t lock up altogether with such little ram.

s.jpg (168.59 KiB) Viewed 1364 times

[wiak]

If one wished to utilize legacy laptops in a vnc envrionment such as presented above, does one just need apps that can be run in any puppy?

Would it be worthwhile to have a specialized puppy for the client?

Do the client and the server need the same OS?

I have mainly been using a Dog, being BionicDog64 as the server, with WeeDogLinux Arch64 as the client, so no they do not need to be the same distro.

It certainly is vitally important to configure VirtualGL correctly to get the fast frame rates I have been getting - when set up optimally the results are amazing (I was amazed) and works well it seems on wifi connected LAN (which I mainly use now) as a hard-wired ethernet one (which is what I used in earlier experiments when I doubted it would be so good). I'm currently installing it again (but this time using WDL Arch64 as a server) but it's been a while since I did my original configuration (which continues to work fine) so I've forgotten the nitty gritty unfortunately - will probably have to experiment with it again to acheive such good results as I have with the BionicDog64 server (I'm using the same server hardware so should be able to get the same fast performance). Clearly, for high frame rates, there is likely to be a fairly high amount of LAN traffic - VirtualGL simply lets the server sort out the graphics acceleration and render the frame using the server graphic card OpenGL capability prior to sending it to the vnc client (note that vncconnect is used to connect the client to the server and that is actually using ssh). Without the fast frame rate my kids and I would certainly not be able to play supertuxkart as we do (seems just as fast as playing on the local machine - that is certainly not the case with vnc alone).

I haven't tried this on Puppy per se, but I have no doubt it can be done, though may need a bit fiddling and finding component parts if they are not in PPM. It is really worth the effort though if you happen to have a faster machine and lots of less graphics capable ones on your home network.

wiak

[user1111]

When I connect using straight fbvnc to a server on the same LAN (vi wifi) it is distinctly slower than when I pipe it through a compressed ssh tunnel.

Fundamentally I set up the server to server vnc port :5900 on 192.168.1.4 and on my wifi connected laptop I run

ssh -f -t -C -N -L 5900:localhost:5900 192.168.1.4

and then on the laptop run fbvnc localhost 5900 (in other versions of vnc it might be vncviewer 192.168.1.4:5900 ... syntax).

With straight vnc you can visually see the frame form/fill - as though a block rectangle was being written, through the compressed ssh tunnel and it just snaps into view. The network load also significantly reduces.

[wiak]

Whilst the desktop is snappy, no different to sitting at a normal booted gui desktop, tux is very slow. Very much suspect its not the graphics side, but rather simply just the absence of adequate ram. Frankly surprised it didn"t lock up altogether with such little ram.

Yes, I think all the machines we are using with virtualGL for supertuxkart are 4GB. The other thing, I mentioned above, is that we use vglconnect for the initial connection, and that may be important - that in fact uses ssh so may well help via the compression effects as you suggest. I really need to research/experiment all this more though, since once it worked (well) I never bothered working out the whys and hows or it all since we were too busy simply then playing the game... However in my first quick new attempt (using WDL Arch64 as server, I've forgotten how I did everything and my first results don't seem so good - I'll need to compare the BionicDog64 virtualGL install (on same machine) with my Arch attempt and try to figure out if all is well or if not what I did different. Assuming I succeed I'll report back about that.

wiak

[user1111]

Fatdog includes tigervnc by default, which includes vncserver and x0vncserver.

On the server create a passwd
vncpasswd ... and enter a password (twice to validate)

On server, in /root/Startup create a script containing

#!/bin/sh
sleep 10
DISPLAY=:0 x0vncserver -rfbauth ~/.vnc/passwd

and make it executable, so the next time the system boots it will automatically start x0vncserver

On the client, run tigervnc viewer and connect to the server, likely port 5900
(a higher port number if you already have other vnc servers running). For instance if the IP of your server is 192.168.1.4 then enter 192.168.1.4:5900 into your vnc viewer/client and then when prompted enter the password you set above (with the vncpasswd command).

... That in effect combines vnc and X ... so when you connect to the server and load something like SuperTuxKart ... gameplay will be pretty good