Stewart Stremler wrote:
The Java-based ones I've looked at are all unable to run securely in a
JVM sandbox (limited disk access, full network access). The lure of
using a custom classloader (rarely *actually* needed) is just too much.
Of course, compared to a C program with no sandbox at all, this isn't
an issue, I suspect.
One thing I have started to see lately are Java apps that can actually
do hot update. Does that require a custom classloader?
Can't bittorrent "dial down" the bandwidth? Or there's that user-space
network library lets you control the bandwidth availability on a
per-process basis -- we should be able to provide the functionality
without the conconmitant network load.
Both, but rtorrent has been particularly bad.
Since I have been dealing with low-CPU machines, both enhanced ctorrent
and rtorrent come up a lot.
Enhanced ctorrent compiles almost everywhere and works. rtorrent is
painful to compile even to functionality and then crashes quite
regularly do to memory corruption. rtorrent also apparently pounds on
mmap (a particularly vulnerable and unstable piece of the Linux kernel).
Overall, rtorrent should just die. The problem is that enhanced
ctorrent is "good enough" for most uses and is very minimal but has no
maintainer. rtorrent has a maintainer and is accreting (stupid spell
checker--go away) features without even a basic security consideration.
Such is open source,
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-steer
