> Where does /etc/sysconfig/tcedir point?
It's a symLink pointing to the /dev/sda2 DirTree with empty files, which I'm now deleting,
since TC should not mess with M$ partitions.
Changing RAM:/etc/sysconfig/tcedir won't fix the problem, for the next boot,
unless the change gets stored in my persistent partition /dev/sdb1
> You really need to read the book.
Yes "life is better with Coke".
I've read it & heard the TextToSpeech version.
-----------
A new problem has started:
under <X/fbuf>, although the mouse cursor is alive, it doesn't activate anything.
currently TC:X is stuck on the Destop with opera-12;
fortunately Ctrl/Alt/F1 gets me to my chain-of-rootVTs.
! I just thought of using Alt/F1 in <X>, which killed opera-12 and freed-up the mouse.
Actually: <X menu> showed that opera was still active & selecting it brought back
a normal/live opera, which I then confirmed by answering a gmail
all after starting to write THIS on VT:links!
One thing that doesn't look right is top's output:--
PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND
6625 4231 root R 5208 0.2 0 5.4 ./oberon
7405 4223 root R 11868 0.6 1 0.4 top
7164 2 root SW 0 0.0 1 0.1 [kworker/1:0]
7167 2 root SW 0 0.0 1 0.0 [kworker/u4:0]
4914 4883 tc S 785m 42.0 1 0.0 /usr/local/lib/opera-12/opera-12
...... should opera take so much CPU activity, while dormant?
I just went to <ControlPanel/BakupRestore> and was able to edit <Device:sda2> to sdb1
and do a <test Bakup>.
-- PS. the problems of not being able to <mouse copy> between <x> & VT for purposes
of conducting tests in one window & reporting the results in another, demonstrates
the value of oberon & wily, where lacking <mouse copy> and human-short-term-memory
accuracy is eliminated, by being able to have multiple windows on the same screen.
----What is ControlPanel / TerminalServer good for?