Alo Sarv
lead developer

Donate via

Latest Builds

version 0.3
tar.gz tar.bz2
Boost 1.33.1 Headers
MLDonkey Downloads Import Module Development
Payment completed
Development in progress.
Developer's Diary

Saturday, April 30, 2005

GCC4 support, working on built-in modules support

As I suddenly discovered, Apple seems to have released XCode 2, which is based on GCC 4; and this merely a week after gcc4 was released. So I quickly rushed to install gcc4 myself, and test hydranode with it. After some fixes (related to namespaces usage), and patching boost libraries (patch used is available here), hydranode is now fully gcc-4 compatible.

Moving on, we had the issue of static builds, or, more precicely, the lack of support for them. This is due to lack of support for built-in modules (static build of core w/o modules isn't worth much), so I headed down to battle with autoconf. After 6 hours, I can report some success. It's possible to use --with-builtin=ed2k,hnsh now, which results in ed2k and hnsh modules being built into core binary. However, there are still some open issues - while I dropped some preprocessor tricks for now, we need to re-add them, since some of the init/shutdown routines break when doing dynamic builds, so the updates aren't in ths svn repository yet.

Madcat, ZzZz

Wednesday, April 27, 2005

Science, Art and Personality

Last summer, I had a discussion on whether programming is science or art. The common opinion is that programming and code is science, but why? This raises a more fundamental question - what IS art? When is something science, a tool, an object, and when does that object become art?

Take a chair. The one you'r sitting on right now. It's an object, it has no significence whatsoever. You can sit on it, use it. It isn't an art. But now, take the same chair, put it in a glass box, in an otherwise empty room, and call people to look at it - voila - it's art. Suddenly, the simple object became a piece of art.

Following that logic, code is just another tool. It produces an application. It has no other significence or value. Thus, programming, as in "creating code", is science. However, code, just as the chair in the previous example, can become art, if you say it is art.

What difference does it make? Compiler doesn't care how the code looks like. End-users never see the code. From scientific perspective, there's no difference.

There is a difference. There are things that cannot be classified, explained rationally, or justified; not many notice them, people can rarely explain them, but nearly everyone feels that. The difference is in personality. And personality goes a long way.

A code with personality, an application with a personality, a project with a personality - you instantly notice it, you can feel it. And it is that feeling is what creates brand loyality. It is that feeling is what brings people together. It is that feeling is what makes the difference between two otherwise identical chairs [projects/applications].

Websites, user interfaces, logos, names - they are all inherent from a specific personality. Without personality, the chair [website/logo/project] is just that - a chair. You can sit on it, but that's that. But a chair with a personality is a completely different story.

Personality goes a long way.


Tuesday, April 26, 2005

Canceling, ServerList::connect() fixes, safeDelete()

Yesterday was filled we lengthy discussions with our designer on the philosophical aspects behind hydranode, it's features, future directions and so on. We arrived at several important conclusions, found a number of good "words" on which to build further "hydranode theme". I will not go into further details at this time though, since the ideas and philosophies still need some fine-tuning and polishing...

Today, however, I finally got a day off from design-related stuff, and got to get some coding done. One of the important issues that had been open for a long time was download canceling - canceling by name was cumbersome, and didn't quite work at all, so I implemented canceling by ID instead (in shell), which operates just as with search results - `cancel 3` cancels 3rd download in `view downloads` listing.

The new canceling code, however, brought up another issue that we had tried to fix for long time, but never really got fixed - crashes on download destruction. But since the canceling code exposed the bug more clearly than any previous times, the reasons behind the bug became obvious, while the fix needed some thought still. The issue itself was simple - when PartData emitted EVT_DESTROY event, SharedFile handled the event, and deleted the PartData object. However, other code handled the event aswell - namely, ED2K module, DownloadList class. The problem is, if SharedFile event handler is called before DownloadList handler, PartData gets deleted, and DownloadList gets event from invalid pointer, leading to crash later, deep in Client class destructors.

Originally, it was fixed by using FILO (first-in last-out) ordering in event handlers (since SharedFile is the first class to add handler for PartData), however, this doesn't work when dealing with AllHandler concept (add handler for all objects of same type) - AllHandler is called AFTER normal event handlers, and that's what DownloadList was doing. Changing AllHandler to be called before other handlers would'v been just as error-prone as current way, since it would create the same problem, only reversed, possibly in some other context. A more generic solution was needed.

Obviously, this problem only appears when dealing with object destruction, so logically, the solution would be to ensure that the object gets deleted at the end of event loop, when all pending events have been handled. Hence, EventTable::safeDelete() method was implemented, which schedules the object for destruction, and at the end of event loop, the object is actually deleted.


On other news, command handling in Shell was improved today; now all commands can be abbrevated as much as is needed to resolve ambiguouties. For example, `s` is ambiguous - 'search' or 'shutdown', while `se` already resolves to `search`. Also, commands are now initially sent to current object, and only if that fails, global commands are handled. Ambiguoutiy resolution is still limited to one at a time, thus in serverlist/ dir, `c` resolves to 'connect', instead of giving ambiguouty between 'connect' and 'cancel'.

Network downtimes are now also handled more gracefully in hydranode; crashes in ServerList::connect() have been fixed (again a long-time bug, with 4 reports in tracker associated with it). While servers are still dropped from serverlist due to failed attempts, it is guaranteed that at least two hard-coded servers always remain in list at all times.

Madcat, ZzZz

Saturday, April 23, 2005

The daily post

You are not going to abandon us now, will you? I mean wtf - who's going to keep us company.

I don't know - blog about whatever comes to your mind. Is 64bit better than 32bit for the donkey network? Should sha1 be replaced by sha256? Should the code be refactored to throw exceptions instead of ints? How many unique downloads you got today for the core? What do you think of (implementing) this or that other P2P? Need I go furhther :)

Hehe. Abandon? Naah, hydranode has way too much potential, way too interesting future to abandon this blog. You are right ofcourse, there are always things to blog about. But sometimes there are times when few days break from blog can go a long way towards writing more interesting blog posts, I tend to believe in quality rather than quantity.

An interesting thing I found out few days ago ... I had heard ppl talking that MSVC has nice optimizer, but never really had chance to experience it first-hand myself, until few days ago ... comes out, hydranode is many times faster when compiled with MSVC, CPU usage down from 20-30% to 1-4%. This is rather interesting, because during development, my primary target was GCC, and hydranode code is optimized to work with GCC, and there's still room for further optimizations - scheduler/network handling code isn't even close to the speeds I'd like to see there. And already, with that slow code, MSVC produces so fast binaries out of it. By the time I get CPU usage down to <5% margin under heavy load with GCC, cpu usage on win32 will be non-existent, which is a Good Thing :)

What else ... the new website is nearly complete, missing only minor things and touches now, so should be lanched soon (that's what the references to buttons and design in last blog post were about - not the GUI). Speaking of GUI - yes, it's being worked on, but the work is non-visible, mostly consisting of discussions, thinking, dreaming, and so on - the typical design process. We have very high requirements for the GUI and it's features, just as we'v had for the core from the beginning.

The GUI application structure will be identical to the engine's - there will be a core application, which displays the actual dialogs, and provides an API, but does nothing else. Communication with the engine(s) is implemented in plugin(s), which use the API calls to display data. Generally, it makes sense to have only single communication-plugin loaded at a time, altough there are no restrictions for connecting same GUI to multiple cores, should one need that (not needed for 99.9% users tho). However, this application layout gives the same benefits we'v been enjoying in the core - plugins can extend the GUI w/o causing feature bloat. Keeps everything nice and modular. The future is that the majority of GUI features will be implemented by plugins. For example, media libraries, integrated media players, unpackers, file content viewers or whatever comes to mind, should be implemented by plugins.

Madcat, ZzZz

Friday, April 22, 2005

Talking about design?

You'r probably wondering, why the blog posts are becoming rarer and rarer recently. And you'v already heard several reasons for that in the past, but let me give you some more.

During past year, the main development target was the engine, and edonkey plugin. Programming is science, and science can be discussed and talked about. However, the engine is finished, edonkey module is finished, so what do I write blog posts about now?

The answer to that question seems obvious - I don't. This doesn't mean I don't work on hydranode - I still pull 12-16h development-days, I still wake up 9pm and go to sleep 8am, but when I go to sleep, I have nothing to say that would be "talkable". So what is it that I'm doing?

Design. Visual things. And talking about design is like dancing about architecture - you can't do it. I is impossible to talk and discuss about design, since design is art, design is largely influenced by taste, and you can only fight about taste, not discuss it in a civilized manner. Consider how would the following sample blog post look like:

"Today I spent several hours playing around with various layouts, testing several color schemes. Blue certainly doesn't cut it, perhaps red does? Oh, and I changed a button to use bold font today, now it looks so much better."

Not very interesting, eh? And how would you comment such a post? "What? RED? Why? Green is definately the way to go!". And there, you have it, fight about whether something should be red or green. Time wasted on fighting instead of designing. Often, some bad design decisions are needed in order to understand the problem better, and re-design it into a fundamentally different, better thing the day after - but with daily updates, everyone sees that, and starts fighting and discussing things that were simply steps on the path. Some believe the journey is more important than the destination. While it is often the case, when it comes to design, the journey is something private, and only the destination should be shown to the others.

When talking about code and programming, such things never raise, since there's always a clear indication which is right way to do something, and which is wrong. Code is science, design is art.

Frankly, I really don't know what to do with this blog. Interface development (once it starts) will be rather un-interesting thing to talk about, except perhaps some fundamental application design topics (how different parts of the interface code should interact - already decided and designed at this point). One thing for sure - the "daily diary" times are mostly over.


Tuesday, April 19, 2005

64bit iostreams too much to ask? *doh* ...

I had been wondering for quite some time now why I had so much corruption recently. Some investigation showed that it appeared in >2gb downloads, post the 2gb margin, but reasons eluded me... until today, when I stumbled upon this little list post:

Apparently, GCC 3.2 and 3.3 seem to have broken libstdc++ which does NOT implement 64bit file offsets. Since I initially tested large-file support using gcc 3.4, and only recently (and by accident) happened to compile/run hydranode regularly on 3.3-based system, I noticed it.

There aren't really any ways around it. It's fixed in 3.4, but it doesn't seem to be backported. And I cannot say "you need gcc 3.4 to compile hydranode" either, having gcc-3.2 required is already high enough. So, I simply had to go and rewrite all file IO code, using C functions instead. SharedFile and PartData now use new code, didn't get to update hasher code yet. And this definately broke win32 port, at least temporarely, since win32 has slightly different C function names for those calls. *doh*.

This will introduce a delay in the release, as much as I hate to say it, since I have to start testing all over again (and I lost 15gb partial downloads due to a typo while writing the new io code - backups are for wimps :P), so ... *doh* I'd say.

Other notes:
Madcat, ZzZz

Monday, April 18, 2005

More win32 stuff

Finally starting to get somewhere with the win32 port. After resolving the zlib issues (incorrect build setting), and timers (bug in 32 -> 64-bit value conversion), hydranode seems to be working - at least it's not crashing anymore. However, still more tuning and debugging is needed. Things that I'v noticed thus far is still the .met / .dat files corruption on saving, and from what I can see, uploads handling isn't working correctly either - upstream is pretty empty, despite sharing several files and having people in queue (possibly related to the bandwidth-calculator not opening up slots properly). Additionally, we still have the many-connections-lost bug mentioned earlier, which significently reduces overall performance. Oh, and then we have some random wierd freezes ... and from what I can tell, we'r running 4 (four) threads, while we'r supposed to run only two. On posix, there's pthread_manager thingie, which adds it up to 3, perhaps win32 has some similar thing, which would account for the extra threads?

Madcat, ZzZz

PS: Project files in SVN should compile/run cleanly on win32 now, zlib files are in SVN, only external dependancy is boost libraries. So anyone adventurous enough might even try compiling/running it on win32. MSVC .NET 2003 is only compiler supported right now, GCC 3.2+ support via autoconf will be added at some later time.

Saturday, April 16, 2005

Full feature freeze, future timeline

As you might have noticed, blog posts have become less "daily" recently. The reason is simple - there hasn't been much going on past few days really; been chilling, taking a step back and looking at the bigger picture of things. And the good news is that I like what I see. The engine, as well as ed2k module are functioning well, only needing routine maintainance. Bigger changes and improvements are being planned, but held back until their right time. The schedule timeline is staying as originally announced - 0.1 release will be done in the middle of next week. Following that, efforts will go towards user interface, which will then be released as 0.2 once it's operational. During that time, 0.1 branch will receive only bugfixes. The interface, once finished, will be released for linux and Mac OS X initially, with windows version delayed until QT4 release (announced to be released late Q2 2005). The remainder of the plugins, with Bittorrent and Ares being on top of the list, will be developed after that.

Until the 0.1 release, there will most likely be little activity, except for routine bugfixes and portability-related fixes in the codebase. As noted before, the current open issues are some build system problems (which blocks Mac port right now aswell - autoconf doesn't support .bundles really), and win32-related issues.

In other news, hydranode wiki is now online, at the request of TobiasTheCommie (also maintained by him - direct all questions/suggestions/problems regarding the wiki to him). Location:


Wednesday, April 13, 2005

Win32 updates

Been working out win32 issues, because 0.1 release shall include win32 binaries also (true, command-line only...). While the core is stable on linux, I want win32 binaries in 0.1, because shortly after 0.1 release (perhaps after cpl days relaxing time), we'll be diving into full-time interface development, with win32 as primary target.

The problem is, software that's ported from one platform to other is quickly noticable - it's pretty obvious for most cross-platform software which platform it was originally written on, and which it was ported to - the ported platform's support is never as good. But this isn't what we can afford with hydranode, and this is definately what we can afford on win32 port, which is the most important one.

And I will not release with our current website, it's completely out of the question. New website is being worked on, and will be launched along with 0.1 release. If all goes according to plans, it should happen around middle of next week.

The current open bugs on win32 are server.met corrupting (random places) on shutdown, and stack corruption somewhere in zlib compression routines. Also, there seemed to be some issues regarding connecting to many clients at very short interval - on linux/mac, I could easily open up hundreds of connections in a few moments, but on win32, something seems to go seriously wrong, and all connections end up failing. We'll see if "max connections per 5 seconds" limit will help any...


Monday, April 11, 2005

Documentation upgrades (phase 1)

Been working a lot on reviewing the existing documentation. Vast majority of it was so out of date that I now call them "design sketches" and will move them to completely separate section on website, since they only have a historical value. Only things that survived the time and evolution was the very first introduction document, written during project analysis phase (summer 2004). The updated core design document survived mostly intact also, altough it still needs some upgrades.

What happens now is that I need to write some more documentation. "MORE?! Don't you have enough trouble maintaining existing ones already?" Yes, but since I'm dumping most of the existing one... besides, we currently lack a proper user manual, and a proper coding standard document.

The old coding standard document is good, but insufficient. It was taken from a (rather old) version of Linux Kernel coding standard document, and touched up with C++-related stuff. However, with some recent patches, I realized that there's a lot more that needs to be properly documented in regards to our rather strict coding standards. Those that have submitted patches to me know that I don't let patches through that don't follow coding standard to the word, but if the word is fuzzy, what are we talking about at all? So, it's rather neccesery.

User manual has even higher priority, and needs full maintaining, to keep up with software updates - outdated user manual is worse than no document at all.

Madcat, ZzZz

PS: Yes, I know the on-site docs aren't updated - I'll update them all at once when I'm done with them.

Friday, April 08, 2005

Shell stuff

Shell got a nice boost today, with a 62k patch from sca, re-structuring the command handling. Also, as pointed out by Xaignar, std::string::data() is lot faster than c_str() that we were using at few (possibly performance-critical) locations, so a slight performance improvement there (altough not noticable).

I'v been working on some prototypes for new shell parser (sca's patch still doesn't give us tab-completition), but they need more work. What we need there is two parsers really - first pass the stream through telnet protocol parser, that strips out all telnet-protocol related stuff, and after that send to main command parser. The main parser will parse the stream, per-byte, and use signals to message the user, e.g. onTabComplete signal requests user-code to attempt to tab-complete the token, onSpecialChar signal sends the special-char to any user-defined handler(s) (optional), for example, if user wanted to handle up/down/left/right arrows somehow. onCommand signal indicates EOL and full command ready for processing.

To onCommand signal, we'll connect a command-lookup function, which determines how to handle the command. That function must look at (a) current object's commands, (b) globally declared commands, and then pass the command to, in (a) case, to the object, or (b) to internal shell function for handling. The internal shell functions should be implemented using a map lookup (already done in sca's patch).

On other news, I'm reviewing site content, and preparing to update the on-site documentation - it's in pretty bad/old shape right now, many things are out of date, or simply rusty. Documentation also needs same amount of maintainance as code does, but I never seem to have time to maintain docs ... but as they say - "You never have time, you have to take time."


Thursday, April 07, 2005


Hasn't been anything very interesting during past two days. Been looking over different things, doing some designing, and planning of future moves.

Towards that end, I put up a better status matrix on mainpage. The ed2k module feature freeze is a funny thing ... in reality, we' r actually missing one component from basic protocol - compressed downloads. The problem is we need streaming decompression (using zstream), but I'm not so sure I want to implement it right now, since the module is pretty nice and stable right now (and it was really crap to get it stable), so I'm not sure I want to break that so close to 0.1 release (and zstream will cause at least temporarely de-stabilization in download process). There are also other things that need to be delayed there for future - corruption is a pretty big problem (800mb lost out of 3.8gb downloaded in 12h session), so AICH is needed as soon as possible, but not right now. Right now, I'm declaring ed2k module to feature-freeze, only open for bugfixes - I know there's at least one memleak in there still open, but I can't recall any open crashes anymore at this time.

The other open topics right now is better logging handling (required by shell) - discussed in depth at tracker issue #49, and better shell handling (also discussed at tracker issue #49). For that reason I also implemented ftp module few days ago (still not complete tho) - to test out the shell module in a slightly more demanding and different context as our current contexts (and franky, it was very refreshing to get out of the usual "wake-up-fix-ed2k-fix-core-sleep" loop, and implement something new and interesting for a change.

Since both ftp and http initial implementations are rather simple, and also make some additonal demands to shell code (which is being restructured right now), I can easily push them into 0.1 release (altough if they don't make it, it's not an issue). But shell updates (most importantly full tab-completition support), as well as log updates are requirements for 0.1.

Madcat, ZzZz

Tuesday, April 05, 2005

Early disconnects, docs updates and FTP module

After this, my net connection went down, so I couldn't work on ed2k anymore... but then I recalled someone mentioned ftp on irc last night, so I rolled up my sleeves and headed down to modules/ftp subdir. 5 hours and several cups of coffee later, I checked in ~500-line ftp module base to our svn repository. It can connect/auth properly, and I downloaded few test files using hardcoded commands, but there are some problems left open regarding connection managements / passive transfer / dirlist handling (the latter one is really crap to parse), so it needs a bit more work. For the curious - FTP module documentation, or - ftp.cpp / ftp.h source.

Speaking of documentation - I regenerated all on-site code documentation. Not much updates on the engine side, but ed2k protocol documentation has several added parts, and ed2k module in general has a ton of new stuff since last online docs update. Enjoy :)

Regarding the daily svn snapshots - I don't think they will be available, at least not at this time. The reason is I prefer updating on-site direct links when I feel the code is reasonably stable, but daily snapshots can often lead to very broken, even harmful code becoming generally available, which is not a good idea. To that end, since ed2k module is pretty stable, and heading to feature freeze today/tomorrow, I updated the onsite code tarball (last update was exactly 1 month ago apparently). Get it here.


PS: There's been some rather interesting discussion regarding HNShell's internal re-structuring. For the interested, the discussion can be found here.

Sunday, April 03, 2005

Misc ...

Been a slow day, just small updates on code side:
The mailing list for the new subversion repository is up and fully functional - the subscription interface is located at here. Old subscriptions (e.g. on the list hosted on berlios) have not been transfered to the new list, so you need to re-subscribe if you still want to receive the repository change updates. Alternatively, the list archives are viewable here.

Madcat, ZzZz

Saturday, April 02, 2005

Moved CVS to subversion, SourceExchange upgrades

First and foremost, we finally changed to local subversion repository on our dedicated server - no more problems with berlios downtimes. While originally we intended to use CVS, in the end we realized subversion is much better choice, and I don't regret this choice. Subversion truly IS nice.

To access the repository, you need subversion client (available from, and the following command gives the latest version:
svn co svn://
Yes, I know it sounds a bit stupid with that many "hydranodes" in the command, but sadly, it's neccesery. Web-based view of the repository is available from Change notifications mailing-list has already been set up, but is lacking a web-frontend, so it's not possible to subscribe to it yet.

Special thanks to our server-admin for the long hours of work on setting all this up :)

On the code side, the new SourceExchange code was merged to svn, and seems mostly operational. The gain is noticable - now nearly 80% of sources are received via source-exchange - before this, the ratios were roughly 60% passive, <5% UDP server and 35% local server.

Memory usage should'v gotten a nice boost too - namely, we were registering event handlers to PartData from each source, which generated a ton of overhead from event tables. Now, we have a thin wrapper API called DownloadList in ed2k module, which takes care of handling PartData events (and registers only one event handler). Moreover, DownloadList (or to be precice, Download object) is tighly coupled with Client object, to keep them in sync at all times, leading to increased stability - keeping PartData and Client relationship stable was a constant headache, but now both of these dynamic objects are tied together via the DownloadList wrapper API, which acts as a kind of "stabilizator". Granted, there may still be bugs in the new code, but it's structure is fundamentally more stable, so ...

Madcat, ZzZz

PS: There still seems some bugs left in the SVN setup, if you experience database errors, retry in couple hours (it seems to have crashed again during this blog post writing).

Friday, April 01, 2005

Credits; lower mem usage on compilation; working on SrcExch

As you'v probably noticed, I'v been skipping "daily" blog posts a bit recently. It does not, however, mean that I didn't work on HydraNode that day - I pretty much work on hydranode 24/7. Missing blog posts simply mean I was either too tired, too bored, or simply didn't want to say anything. Often, by the time I decide that now it's time to get to sleep, I'm so tired, so frustrated at some bugs, that writing a blog post simply isn't something I want to do. Now, I know that you are expecting blog post every morning, to read before going to work/school etc, but hey - I'm only a kitty, sometimes I need room to breathe too :)

So anyway, to make up for last nights missing blog post, here's the update for last night's entries:
Today was a slightly different day tho. Today, the following things got done:
The MultiIndex stuff might be of interest in detail - we know from past experience that MI can get heavy on compilers, but we found workarounds to that. However, as I'm using MI at many classes already, the memory usage issue became obvious, so the following helped a lot:
// in header
namespace Detail {
struct MyIndex;
class MyClass {
boost::scoped_ptr<Detail::MyIndex> m_list;
// in source file
namespace Detail {
struct MyIndex : boost::multi_index_container<...> {};
MyClass::MyClass() : m_list(new Detail::MyIndex) {}
Simple, stupid, yet effective. Similar tricks had to be done with all iterators we needed in headers (PartData headers needed some, as well as ServerList), and that's that.

The rest of the day/night went towards implementing SourceExchange support. The problem is that some of our data structures didn't really support this idea, so I had to implement DownloadList class in ED2K module, which acts as a thin wrapper around PartData objects. The good side is that it localizes several formerly duplicate code regarding downloads scanning, and handling. Furthermore, it ties several objects more strictly together, acting as a stabilizator between two very dynamic entities - PartData and Client. The implementation is 90% finished, and passed initial testing, but needs more work - AnswerSources packet parser isn't fully working yet (altough I'm already getting responses), and some source counters / lists aren't properly updated yet. So bottom line is the system should be fully functional tomorrow evening.

This means we have 3 entries left on 0.1 roadmap - zstream, buildsystem and shell stuff. Well, in reality, it seems we still have one more thing - scheduler. It's scheduled for post-0.1 fixing, but I'v had some time to think about it, and it's really only cpl hours work. The problem is, Scheduler, in it's current state, isn't very scalable - with 100+ sockets, cpu usage raises to 15% region already - that's bad. The source of the problem is that Scheduler handles events from all sockets, which means map lookups during EVERY socket event. Even though we are talking about only pointer comparisons, it's still heavy. Scheduler got a tad over-designed when I wrote it few months back, so now it's time to simplify it. Namely, I believe we can scrap the ENTIRE scheduler.h file (900 lines of code), and implement the neccesery things in SSocket class, with few callback functions and few shared pointers. It should definately speed up networking a lot, and have positive effect on compile times also (which seems to becoming an issue more and more).

On other notes, a comment mentioned precompiled headers. HydraNode supports precompiled headers, but only on MSVC right now, since I haven't yet managed to convince the build system to do it with GCC (maybe I can implement it with new build system, which is planned for 0.1). However, hydranode relies heavily on templates and template-based libraries, so precompiled headers have very little effect - on MSVC, they only lower compile time by 30% (compared to non-template code, for which pch can have up to 90% speedup effect).

About the athlon64 - I'm doing regular testing on amd64 myself, in 64bit mode, so hydranode is, and continues to be, fully 64-bit aware and supported.

Thanks for the link on Filesystem Hierarchy stuff - useful stuff. I must admit I haven't had time to read it thoroughly, but it seems /opt hierarchy is the right place for hydranode.

Madcat, ZzZz

Archives: December 2004 January 2005 February 2005 March 2005 April 2005 May 2005 June 2005 July 2005 August 2005 September 2005 October 2005 November 2005 December 2005 January 2006 February 2006 March 2006 April 2006 May 2006 June 2006 July 2006 August 2006 September 2006 Current Posts

This page is powered by Blogger. Isn't yours?