[17:48:05] <ESR_> Having used this system in a pretty heavy-duty way now I
have some observations:
[17:48:51] <toad_> hmmm?
[17:48:53] <ESR_> 1. Design of the web interface -- very good. The
arrangement of the controls is clever and logical.
[17:49:37] <toad_> hmmm that's an interesting opinion, there are dramatically
different ones ...
[17:50:11] <ESR_> I think it's impressive. Drab-looking, but who gives a
shit?
[17:50:17] <toad_> well basically it's still too geeky, and not enough
bundled - it needs to incorporate more functionality (i.e. Freetalk), and
geek-centric stuff needs to be on submenus
[17:51:06] <ESR_> Could use more stuff bundled in, I suppose, but it does what
it does quite well.
[17:51:15] <toad_> also status messages can still take up a lot of room - we
should move the bookmark updates to only live on the browse page, n2ntms to
live on the friends page etc, with a single notification on the homepage
[17:51:20] <toad_> okay, what's 2. ?
[17:52:58] <ESR_> 2. Performance efficiency of the tools, awful. My machine
has been brough to its knees by *two uploads*. I can't imagine what the Java
could be doing to eat my proocessor this way, but X is very sluggish.
[17:53:16] <toad_> yeah most likely that's due to running out of memory
causing constant garbage collection
[17:53:23] <evanbd> Looking over logs and the docs on the web site... I think
the problems ESR had / is having may have as much to do with poor and
outdated documentation.
[17:53:32] <toad_> that's a common problem, the db4o branch solves it at the
cost of some more disk i/o
[17:53:34] <ESR_> sorry, that should have been "*two processes*".
[17:54:03] <toad_> (and slightly more non-GC CPU usage)
[17:54:45] <ESR_> evanbd: Well, of course!
[17:54:48] <toad_> the db4o branch should be merged in the next two months, it
won't solve every performance problem, but it should solve those related to
memory usage and excessive garbage collection
[17:55:18] <toad_> evanbd: imho a well designed UI doesn't need lots of
documentation, nobody reads the docs until they run into trouble ...
[17:55:51] <ESR_> toad_: You're right. Documentation is an admission of UI
design failure.
[17:56:15] <toad_> so for example it should be possible, and easy, to insert a
freesite from within the web interface
[17:56:20] <evanbd> Yes, but for one reason or another Freenet has shown a
persistent inability to build such a UI. I think this merits consideration
of either the reason that is happening or alternate fixes.
[17:56:29] <ESR_> (This is probably my most shicking heresy to a Unix
audience :-) )
[17:56:36] <toad_> ESR_: :)
[17:56:54] <ESR_> Aaargh,,,can't type.
[17:57:02] <toad_> evanbd: maybe constant firefighting has something to do
with it? :|
[17:57:11] <toad_> evanbd: i should have merged the db4o branch a month ago :|
[17:57:29] <evanbd> I'm sure it does. I'm not saying those reasons are bad
reasons, merely that they appear to exist.
[17:57:59] <flaushy> toad_: i would disagree with the statement about
documentation, but i do think, that that is a field where community can do a
charme
[17:58:09] <ESR_> 3. Props to you guys for being smart and responsive and
really caring about your code. The quality of the on-channel support here is
high.
[17:58:11] <toad_> but we do have some idea of what needs to change, in the
bug tracker and elsewhere ... ian thinks we may be able to get a (specific)
sponsor to pay for a GUI redesign, we'll see whether anything happens to that
[17:58:32] <toad_> ESR_: thanks
[18:00:41] --> mpp has joined this channel (n=mpp at i538776A4.versanet.de).
[18:00:46] <ESR_> Your guess about the low memory limit leading to excessive
GC and VM thrashing seems plausible now I've heard it.
[18:00:59] <toad_> that's what it's been in the past imho
[18:01:06] <toad_> not in every case but in many cases
[18:01:32] <toad_> CPU-intensive stuff runs on low-priority threads, so it
ought not to have a big impact on responsiveness, although we will push your
load avg up
[18:02:20] <ESR_> With 17 uploads done the problems seems to be gone, so I
think number of simultaneous uploads may be a driver; it's probably not often
anyone pushes that as hard as I just did.
[18:02:28] <toad_> yep
[18:02:38] <toad_> well when they do they've learned to up the memory
limits :|
[18:02:39] <DuClare> less segfaulted :(
[18:03:15] <ESR_> The real question is why you have a memory limit at all.
You're using a language with GC...
[18:03:34] <toad_> perhaps ... java always has a memory limit afaik
[18:04:00] <toad_> and GC and swapping go together *REALLY* badly
[18:04:09] <toad_> so it makes a certain amount of sense
[18:04:14] <evanbd> Yes, it does. There's no reason you *couldn't* set it
large, but it might be better not to.
[18:06:13] <ESR_> 4. Recovery from failure conditions is really good, ans
something you don't explain well enough. J. Random user is likely, foer
example, to miss the fact that uploads go in a persistent queue ansd *aren't*
aborted if you kill jsite or close the web interface.
[18:06:37] <toad_> jsite uploads *ARE* aborted if you kill jsite
[18:06:51] <toad_> it's one major deficiency in jsite cos it means it's
impossible to insert huge sites
[18:06:56] <ESR_> I'm sorryt, I was think thaw.
[18:06:59] <toad_> ah
[18:07:05] <ESR_> I weas thinking of thaw.
[18:07:25] <toad_> yeah ... thaw is sort of third party ... it's great but we
don't bundle it cos it's not part of the base UI ...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20081216/710d185b/attachment.pgp>
