[Oberon] Proof of Concept, ARM Linux Oberon
lab.eas at gmail.com
Sat May 10 19:59:28 CEST 2014
]> Also, I can't install and run by just following the documentation.
]> IOW "I found a way to work, but, I don't know what I'm doing"!!
]I suppose the problem was a rights issue. Can you open other programs
What do you mean "other programs windows"? Here's part of my `pstree`:-
The way I use LNO-FrameBuffer is:
klux: OFSTools.Mount SRC LinuxFS . ~
IIRC ./oberon gives seg-faults. Jan V. also reported similar problems.
Just today I needed to use LNO, to get old NativeObn documents for a legal
matter, from 2001 !! That's an example of the need to be able to access
any part of the directory-tree, and handle NativFS, *nix, DOS.
]> ALO works nicely on current rPi. I can't see any difference between
]> Versions: 140418 & 140423; and have one of each running.
]IIRC HALT(12) to HALT(255) is supported in 140423. I added a changelog
]for newer versions.
]> So LNO & ALO *MUST* be able to easily access AosFS, *nix, FAT documents
]> anywhere in the Directory-space. LEO does this superbly.
]Everyone is free to implement that feature.;-) AosFS and NativeFS disks
]would be easy to implement. However, I don't necessarily want them on my
Isn't AosFS the same as NativeFS -- that you've already got?
DOS & *nix are already in several of Native:Editors else should be easy to
add to ALO's existing facilities.
"on my ARM" sounds as if its a toy.
I'm talking about rPi being a substitute for an X86-PC, where you'd want
to handle complex tasks. rPi is ALREADY *nix, so if ALO can't handle that,
it's isolated. And adding DOS is easy and will often be needed.
Currently the biggest problem is to get a smaller ALO frame, without getting
smaller characters. That's also why I wanted to understand how the FrameBuffer
version is implemented. And also because that's what Native and OP2013 do.
== Chris Glur.
More information about the Oberon