[Oberon] Re: LNO > framebuffer > VNC ?
easlab at absamail.co.za
easlab at absamail.co.za
Thu Feb 9 12:01:09 CET 2006
cg> Q1 - what is the oldest version of N-O's VNC which worked ?
shark at gulfnet.sd64.bc.ca wrote:
> VNC and most things in the alpha release,
> ETH Oberon / PC Native 05.01.2003, work
> fairly well. Is there any reason to use
> an earlier release?
Perhaps not if you are already using a newer version.
Every change brings potential problems.
That's why it's called the bleeding-edge.
If I have perceived problems, which are not even
acknowledged, then I should not expect find them
cleared in the later version ?
I'll try 'new' LNO once/if I get a 'frame buffer running'.
The old LNO runs well in an xterm.
I've never seen anything but a DOS-like terminal in linux's
VTs before. Apparently a fb driver [module or part of the
kernel] is needed.
Another nice reason to have LNO and N-O running together:
the unusual characters like 'copyright-sign' ...etc. which were
never include in *Scn.Fnt can be gradually added as they
occur, by using a commonly available char-map under linux.
Just to see what the missing char looks like, to be able to
create it manually with N-O's available FontEditor.Panel .
BTW this is an example of the concept of 'negative entropy',
where the system gets better [tuned] by use - instead of dirty:
if some contributor[s] adds a few chars each year, we can
approach perfection, provided the accumulating mechanism
Q- would it be absurd to simulate 'transparencies' by
having the linux system switching the LNO on & off fast,
to facilitate 'seeing the linux image' while writing to
the N-O destination ?
== Chris Glur.
PS. the related text [below] was written previously and I
believe not posted ? The idea is to leaverage the many facilities
avaliable to linux, which will never be available to ETH systems.
Subject: LNO for USB ?
A good reason to have a working LNO, is to be able to
access facilities not available in NO.
Eg. *.pdf , *.ps viewing, where the result of the view-under-linux
can be immediately used by switching back to LNO.
Similarly, NO drivers for new hardware will/must always lag
behind equivalent linux drivers -- we do/should ride on the
back of linux.
The problem of forking/fragmentation of efforts:--
Understandably the enthusiasm is for efforts towards the newer
BlueBottle, Aos ...whatever [let's call it/them 'NO-descendants'].
Does this mean that by 'upgrading' from NO to the newer
versions, one will have more facilities ? Not so !!
The main power of NO [and presumably its decendants] is the
text handling facilities. And internet usage MUST be an essential
part of the system usage.
Yet it is obvious to me that inet-access is not done by NO-descendants
1. there's increasing top-posting and absurd/funny stuff, like
replacing single & double quotes with character strings - in general
a degeneration to using special formats: mime, rtf, and M$ & other
2. the problem-to-reset-serial-port-after-abnormal-exit which
I raised years ago, and was never aknowledged nor denied.
And which has now been 'worked around confirmed' a thousand
times by an extra manual 'reset':
effectivley Close <theModem's port>.
And google shows that this problem was has been discussed since
1992, even in connection with Apple-machines.
Ie. NO-descendants users haven't acknowledged/solved the
problem, and accordingly just don't use ETH-systems for inet
access, since they would have to continually reboot.
Perhaps that's another use for LNO: use linux to access inet,
and then pass the text to ETH-system[s] for its superior text
Re. bridging between different OSs, DOS/FAT and diskettes
have served the computer industry well; but fd0 has reached
the end of its life. Especially with minaturisation driven by
mobility and energy wastage awarness, USB-stick seems to
be the replacement ?
I'm guessing that NO-descendants is [or will soon be]
USB-flash capable, but NO will not be upgraded.
More information about the Oberon