We might want to separate the different optimized native codecs into different jars, and fetch the right one in the installer. However the node should be clever enough to figure out which jar to use, and for distribution/invites we will need it to fetch all of them eventually.
On Thu, Feb 16, 2006 at 07:06:12AM -0500, Ed Tomlinson wrote: > On Wednesday 15 February 2006 18:23, NextGen$ wrote: > > * freenetwork at web.de <freenetwork at web.de> [2006-02-15 17:08:05]: > > > > > i don't think it is wise if all the binary libraries have the same name! > > > > > > cpu identification has not to be only done by the installer to fetch the > > > correct lib, but also when running the node. > > > people (me) tend to copy data and even java programs from windows to > > > linux and vice versa, or having multiple operating systems on the same > > > computer and run java programs from one single location. > > > now the best that can happen if by windows box runs a debian binary (or > > > even extremely more worse: a sse3 lib from work on my athlon thunderbird > > > at home - that's sure to blow) is that it refuses to work, the words that > > > it crashes. to prevent this a cpu detection has to be > > > done to keep the node from executing wrong library machine code, to the > > > detection has to be in the node. and calling the correct library by its > > > filename is FAR easier than to guess if the available lib is the corerect > > > one for the platform. > > > i think it is also very unintuitive to have different libs share the same > > > name as you can never know if the current library is the correct for the > > > used machine enviroment, in fact there is IMHO no reason to actually LET > > > them have the same name! > > > > At least an obvious one : Simplicity : getting rid of CPUID code in the > > node. > > > > > also, for multi-os machines it would make sense to have the, e.g. windows > > > and linux, library both available and in the same folder without having > > > to swap them by a rename script which is extra hassle > > > > > > so, in short: > > > separation of a huge native lib into smaller libpacks - yes > > > let them have the same name - many, some small and some large, NO!s > > > > > > > Well, it's basicaly a tradeoff : Code duplication against ease of use for > > some power users (I don't think that many people are moving around their > > node on different CPUs/OSes). > > > > What do Higher Gods think ? > > I understand how and why you want to do this. I just do not see it as a win. > You are > introducing a more complex install and a less flexible runtime. In the case > where the > installer downloads the cpuid based -ext library you have increased the > complexity > of the install for a small bandwidth saving. If -ext contains all the code > and you just > set a env variable there is no win - just complexity. > > In my mind simpler is better. > > As you say 'What do Higher Gods think ?' > > Thanks > Ed > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20060216/a96b305d/attachment.pgp>
