Hello,
I have Jnode 0.2.4 11/06 copied from a livecd image to a bootable system.
The system runs a Riva TNT NV04 card, with 768MB of RAM.
JNode boots fully, with plugins, and runs the GUI in full color mode.
I can start and run all of the default applications from start *except Tools > Console *
When I place the cursor over it, it does not even highlight as a selectable option.

Can anyone give me some pointers on things to check for that would keep JNode from allowing me to start a console from the GUI?
I am totally new to JNode, so I am probably missing something obvious, but I assume "Tools > Console" gets me to a JNode Shell in a window in the GUI.

I'm having some problems with remove() on Ext2Directory.

1. It seems that checkEntriesLoaded() is not called inside AbstractFSDirectory. This means that if remove() is the first operation on an implementation of AbstractFSDirectory (such as Ext2Directory) then the remove() fails with a FileNotFoundException. This looks as if just adding checkEntriesLoaded() would fix the problem.

2. The removal of an entry doesn't seem to be flushing properly. The call to flush() in the remove() method in AbstractFSDirectory calls through to writeEntries() in Ext2Directory which does nothing and has the comment "nothing to do becaude createFileEntry and createDirectoryEntry do the job". It looks to me like there should be some code here to flush the removal, but it is a bit beyond my experience with JNode to write it.

Hi,

I checked out the latest version out of svn today and I get a out of memory error during build (see below). I increased the memory but it still gives the error. Anyone else have this problem? This is on 64 bit linux suse. Javac is 1.6.0., could that be a problem?

This is the startup line in build.sh at the moment, I think that should be enough memory:

java -XX:MaxPermSize=512m -Xmx2g -Xms128m -jar $dir/core/lib/ant-launcher.jar -lib $JAVA_HOME/lib -lib $dir/core/lib -f $dir/all/build.xml $*

Thanks for any help!

Rien

Out of memory error:

rnentjes@linux:~/programming/jnode> ./build.sh x86_64

I wanted to point the people working in JNode-FS to this recent PhD thesis:

http://lfs.irisa.fr/~pad

Particularly, if you look into the papers folder

http://lfs.irisa.fr/~pad/rawaccess.query/papers

There's the thesis itself (sadly in French, if you can't read French or happily in French if you're more fluent in French than in English), but there are the slides of the defense (in English) and two USENIX papers about the LFS and the PoFFS.

In a nutshell, Yoann Padioleau extended Linux through FUSE (Filesystem in USEr space) so as to allow a logical access to files. When you cd to a "directory" in LFS what you're actually doing is crafting a formula to access the underlining files, through metadata. While this requires a good deal of tinkering in Linux, I think JNode is in a much better position to incorporate this approach. The use of formulae appears normally related to access control lists in regular file systems. The beauty of LFS is that it allows a unified view of security, tagging and search. (more below)

My latest bjorne shell patch includes a first attempt at connecting standard input to the keyboard in a useful way. I've hacked the keyboard interpretter to map CTRL + key to control characters, and implemented a minimal TerminalInputStream that (just) maps ^D to a soft EOF marker. To see this working run:

$ chsh bjorne proclet
$ cat > /jnode/tmp/foo
the quick brown fox ...
^D

You will immediately notice that the characters typed as 'cat's standard input don't get echoed, and that there is no line editting. This forum topic is about how to implement these.

In the good old UNIX world, echoing, line-editting, ^D, ^C, and lots of other terminal input-related stuff are implemented in the "tty" device driver stack, typically in the OS kernel. The behaviour of the terminal is controlled by a bunch of ioctls that set flags, specify active characters and so on. There is a lot of arcane stuff here, but the one big thing that this gives us is that a classic UNIX application can just read a stream of data characters without worrying about what is going on behind the scenes vis-a-vis line editing etc.