Followed golinux's thread, this one too.

A month ago a ChatGPT ad/spam showed up in my email and two weeks ago I got a snailmail full-color, oversized postcard. Both described how cool ChatGPT is and how it would enhance my life. Reminded me of 'The Cloud' promotions years ago, and entrusting personal stuff on someone else's hard drive... and paying a monthly fee for the priviledge.

The difficulty in searching ChatGPT was deciding which of the zillions of links to follow. While big tech's already using it and it's widely promoted, the experts are issuing dire warnings?

OpenAI's new ChatGPT bot: 10 dangerous things it's capable of
December 6, 2022
https://www.bleepingcomputer.com/news/t … apable-of/

Links following above article:
OpenAI releases tool to detect AI-written text
Microsoft unveils AI-powered Microsoft 365 Copilot assistant
DuckDuckGo launches AI-powered search query answering tool
Brave Search launches AI-powered summarizer in search results
Microsoft adds AI-powered Bing Chat to Windows 11 taskbar

Google's AI Robot TERRIFIES Officials Before It Was Quickly Shut Down
February 21, 2023
8:35
https://inv.vern.cc/watch?v=ERXG_yndO3E
NOTE: Observant comments. Scroll for more AI videos on same page

ChatGPT creator warns of AI dangers
19 Mar, 2023
https://www.rt.com/news/573243-gpt-creator-ai-danger/
From the article:

Indeed. It's often time consuming to confirm whether the news we're reading or watching is real. Like the greenscreen and real time video editing already in use, and digital people (eg: Google's AI Robot) the public seems to trust more than real people, AI adds another subtle layer of BS to wade through... assuming we even see it for what it is.

@Head_on_a_Stick

Appreciate your thoughts. Yes, I can upgrade to the new procps and accept the different  memory reporting and hope it'll be corrected soon. I can also keep the older procps until the problem's resolved, hopefully soon. I've had to put a hold on a pkg several times when the upgrade was available but one or two of its dependencies were not. I'll keep the older procps for now until some other essential pkg/s require the upgrade.

FWIW
The new procps has libprocps as a dependency. I didn't find any reported bugs for the library but I did find the links below for procps-2:4.0.2-1 and a fix for 2:4.0.2-2. Neither mentions a memory reporting problem. Despite what was fixed, procps-2:4.0.2-2 caused the memory problem. There might be more bug reports but I didn't find any.

Oct 24 2022
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022573
Dec 5 2022
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025495

Downgraded to 2:3.3.17-5+devuan1, rebooted and memory is back to normal.

Damn fine catch, rbit. Thank you!

... and coming up with a miraculous fix for a 'modest' fee.

@Head_on_a_Stick

Glad the doas in my previous post looked normal. I just ran it again. Any idea why xorg is almost double what it was with the same files open on the desktop?

doas ps_mem | grep 'Xorg\|fluxbox'
  4.2 MiB +   1.1 MiB =   5.3 MiB       fluxbox
100.4 MiB +   4.7 MiB = 105.0 MiB       Xorg

Yes, free still shows excess memory. With just xterm on the desktop:

free -m
               total        used        free      shared  buff/cache   available
Mem:            3771         465        2939          53         630        3306
Swap:           1824           0        1824

Procps was updated on Dec 6:
[UPGRADE] procps:amd64 2:3.3.17-7.1devuan1 -> 2:4.0.2-1devuan1
along with this:
[REMOVE, NOT USED] libprocps8:amd64 2:3.3.17-7.1devuan1
The libprocps8 pkg is in the Debian repos but not in Devuan's... haven't looked into why.
Was updated again on Dec 16:
[UPGRADE] procps:amd64 2:4.0.2-1devuan1 -> 2:4.0.2-2devuan1

Yes, the CPU's a Haswell but the intel-microcode and iucode-tool pkgs are not installed. The firmware-linux and firmware-linux-nonfree pkgs are not installed, either. Neither of the sda/sdb OSs have had any of those pkgs installed for well over a year. The kernel, though, has about ten built-in Intel modules for sound, better function and security.

No worries, my thanks for all you've done to help.

.xinitrc

#!/bin/sh
#
numlockx &
conky --pause=1 -c ~/.conky/conky.conf &
# feh --bg-scale '~/.fluxbox/backgrounds/neon-surf.jpg' &
# feh --bg-scale '~/.fluxbox/backgrounds/la-playa.jpg' &
feh --bg-scale '~/.fluxbox/backgrounds/night-poppies-1.jpg' &
#
exec fluxbox

The line for feh invokes:

.fehbg

#!/bin/sh
feh --no-fehbg --bg-scale '~/.fluxbox/backgrounds/night-poppies-1.jpg'

And FWIW:

.xserverrc

#!/bin/sh
exec /usr/bin/Xorg -nolisten tcp "$@" vt$XDG_VTNR

Got the Fluxbox desktop, minus the background, etc.

Appreciate your thoughts, and I'm open to whatever info you ask for. However, just so you know, a little over halfway down the second page of 'Show your desktop (rebooted)' is my desktop from Sep 2018, #42. The .xinitrc and .fehbg files have been edited maybe two or three times since then for the background, and the .xsession file was never edited after creating it 2+ years ago.

BUT... what you asked gave me an idea. The only changes on these OSs, aside from updates and infrequent color scheme edits, are occasional downloads of videos, etc. The excess memory might be from a download, a dot file edit or something else. I moved everything except .Xauthority, .xinitrc (commented out conky, feh, xnumlock) and .xserver to 'old.home.stuff' and rebooted. Same excessive memory.

@ralph.ronnquist

Thanks for the suggestion.

$ df -h | grep -E 'Filesystem|tmpfs'
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           378M  748K  377M   1% /run
tmpfs           5.0M  8.0K  5.0M   1% /run/lock
tmpfs           1.1G     0  1.1G   0% /dev/shm
tmpfs           378M  4.0K  378M   1% /run/user/1000

Been searching for an explanation of the above results but haven't found anything useful, or what it may have to do with suddenly showing excessive memory use. Appreciate any help.

Ain't that the truth.

Most recent Xorg log, Dec 14
https://droptext.cc/napw

FWIW, my Dell 24" bit the dust about five months ago and currently using an old Motorola 37". 

inxi -G
Graphics:
  Device-1: Intel 4th Generation Core Processor Family Integrated
    Graphics driver: i915 v: kernel
  Display: server: X.Org v: 1.21.1.4 driver: X:
    loaded: modesetting dri: crocus gpu: i915
    resolution: 1920x1080~60Hz
  API: OpenGL v: 4.6 Mesa 22.3.0 renderer: Mesa Intel HD Graphics
    4400 (HSW GT2)

Thanks for the thought, HoaS. I still have/use the ps-mem.py.sh script from 2015. I installed the one you linked and below are the results with just a root terminal on the desktop.

Old

# ps-mem.py.sh

 Private + Shared = RAM used    Program 

  4.0 KiB +  93.0 KiB =  97.0 KiB       startpar
 36.0 KiB +  94.0 KiB = 130.0 KiB       bootlogd
 76.0 KiB + 180.0 KiB = 256.0 KiB       init
100.0 KiB + 180.0 KiB = 280.0 KiB       atd
240.0 KiB + 371.0 KiB = 611.0 KiB       cron
508.0 KiB + 317.0 KiB = 825.0 KiB       dhclient
264.0 KiB + 572.0 KiB = 836.0 KiB       xinit
528.0 KiB + 459.0 KiB = 987.0 KiB       udevd
504.0 KiB + 548.0 KiB =   1.0 MiB       dbus-daemon
496.0 KiB + 902.0 KiB =   1.4 MiB       login
964.0 KiB + 808.0 KiB =   1.7 MiB       rsyslogd
  1.0 MiB + 878.0 KiB =   1.9 MiB       su
688.0 KiB +   1.2 MiB =   1.9 MiB       getty (5)
  1.3 MiB + 568.0 KiB =   1.9 MiB       elogind-daemon
  3.8 MiB +   4.3 MiB =   8.1 MiB       fluxbox
  4.2 MiB +   5.9 MiB =  10.0 MiB       bash (3)
  8.3 MiB +   7.1 MiB =  15.4 MiB       xterm
 10.8 MiB +   9.4 MiB =  20.2 MiB       conky
101.1 MiB +  48.9 MiB = 150.1 MiB       Xorg
---------------------------------
                        217.5 MiB
=================================

New

# ps_mem -d

 Private  +   Shared  =  RAM used       Program[pid]

  4.0 KiB +  70.5 KiB =  74.5 KiB       startpar [671]
 36.0 KiB +  44.5 KiB =  80.5 KiB       bootlogd [670]
100.0 KiB +  45.5 KiB = 145.5 KiB       atd [1400]
 76.0 KiB + 108.5 KiB = 184.5 KiB       init [1]
136.0 KiB +  84.5 KiB = 220.5 KiB       getty [1465]
136.0 KiB +  84.5 KiB = 220.5 KiB       getty [1468]
144.0 KiB +  83.5 KiB = 227.5 KiB       getty [1466]
136.0 KiB +  93.5 KiB = 229.5 KiB       getty [1467]
136.0 KiB +  99.5 KiB = 235.5 KiB       getty [1464]
240.0 KiB + 116.5 KiB = 356.5 KiB       cron [1437]
264.0 KiB + 280.5 KiB = 544.5 KiB       xinit [26536]
528.0 KiB +  50.5 KiB = 578.5 KiB       udevd [412]
508.0 KiB +  84.5 KiB = 592.5 KiB       dhclient [1114]
504.0 KiB + 185.5 KiB = 689.5 KiB       dbus-daemon [1439]
496.0 KiB + 268.5 KiB = 764.5 KiB       login [1463]
964.0 KiB +  69.5 KiB =   1.0 MiB       rsyslogd [1374]
  1.0 MiB + 344.5 KiB =   1.3 MiB       su [26612]
  1.3 MiB + 114.5 KiB =   1.5 MiB       elogind-daemon [1444]
  1.4 MiB + 500.5 KiB =   1.9 MiB       bash [1473]
  1.4 MiB + 596.5 KiB =   1.9 MiB       bash [26653]
  1.4 MiB + 592.5 KiB =   2.0 MiB       bash [26590]
  3.8 MiB +   1.7 MiB =   5.5 MiB       fluxbox [26547]
  8.3 MiB +   1.2 MiB =   9.5 MiB       xterm [26588]
 13.3 MiB +   1.6 MiB =  14.9 MiB       conky [26548]
101.0 MiB +   1.3 MiB = 102.2 MiB       Xorg [26537]
---------------------------------
                        146.7 MiB
=================================

The old and new scripts show different memory and shared memory values, and a 70MB difference in total. Some spot checks of xorg, conky and free:

xorg

# smem -k | sed -e '1p' -e '/xorg/!d' | grep -v sed
  PID User     Command                         Swap      USS      PSS      RSS 
26537 (user)    /usr/lib/xorg/Xorg -noliste        0    99.8M   102.8M   109.9M 

# cat /proc/26537/smaps | grep -i rss |  awk '{Total+=$2} END {print Total/1024" MB"}'
112.652 MB

conky

#  smem -k | sed -e '1p' -e '/conky/!d' | grep -v sed
  PID User     Command                         Swap      USS      PSS      RSS 
26548 (user)    conky --pause=1 -c /home/xe        0    13.0M    14.2M    20.1M 

#  cat /proc/26548/smaps | grep -i rss |  awk '{Total+=$2} END {print Total/1024" MB"}'
20.1133 MB

# free -m
               total        used        free      shared  buff/cache   available
Mem:            3771         455        2762          52         835        3316
Swap:           1824           4        1820

I'm probably missing something but how do you reconcile the differences between the totals of either ps_mem with free?

Very helpful... that was my experience on Ceres with VBox 6.1.28-dfsg-1+b1 and kernel/headers 5.14.0-3. Appreciate the info. I'll try an earlier VBox and see how it goes.

One of dbus's new dependencies in Unstable is dbus-system-bus-common. I had VBox installed for a while and didn't get the "No such file or directory" msg. That pkg may be in Testing.

I don't know, but thanks for the tip.