Slashdot Mirror

You could take a look at: http://www.sysorb.com/

> The network will cover 20+ states, and several European and Asian countries and Australia.
* Our system allows for "satellites" which are remote monitoring stations allowing you to perform checks against a given node from several remote locations.
* Our system works well even in NAT'ed setups where several remote private-network sites report in status info to a central monitoring server
* You can even delegate administrative tasks, so that the asian administrators can view only their own systems but may have administrative privileges there, for example

> about 30 servers mixed between linux and windows
* In addition to SNMP and various network checks (HTTP/...) we provide an agent which provides detailed system monitoring data for your servers - this agent runs on both Windows and the most common Linux distributions (in addition to NetWare/HP-UX/Solaris/...)

> really decent cheap web based monitoring application to maintain the entire system.
* You can get on-line quotes on our site, or send a mail to sales@... they will answer :)
* Both configuration and day-to-day monitoring operations is completely web based
* We have clever web-based configuration system to make it easy to set up detailed monitoring on large networks

All in all, there's pros and cons to all the systems you mention and (no surprise) to ours as well. No two are really alike. My best advise to you is to take a look around, get some free trials going and see what you like. And talk to the vendors. If they won't help you during the trials, they probably won't either when you face real problems later on.

In spite of this being a blatant plug for the company I work for, I hope the moderators will go lightly on this post since it is completely on topic and specifically answers the question asked. Thank you very much :)

Luckily, /. is monitored, this historical event will be kept in the monitoring systems for ever and ever ;)
Go to the monitoring system page.
Click the www.slashdot.org link
Select services
This will give you some graphs showing the outtage.

Huh ?
I'll check up on the DHTML thing tomorrow when I've gotten some sleep...

The network monitoring system is a client/server system. The server is a large program (it is a distributed database and a remote monitoring system), and the client is a very small easily portable program.

Thus, the server is available for RedHat 6.2 (and therefore also 7.0, the 6.2 version will work there), Debian 2.2, FreeBSD 4.0, NT 4.0 (and therefore also Win2K).

The client is available for the same platforms, plus, RedHat 5.2 (with a Linux 2.0 kernel), and FreeBSD 3.4.

As you will have noticed, the software is in beta, but we are *very* close to a release. There are bugs left, but we will have a release out fixing the last known ones, probably around the weekend.

Should anyone out there have oppinions, suggestions, demands or "other", for a commercial program soon-to-ship for Linux among other platforms, I would welcome such feedback.

Please use this e-mail address and check out the website.

And please accept my apologies for going slightly off-topic on the subject here.

Huh ?
I'll check up on the DHTML thing tomorrow when I've gotten some sleep...

The network monitoring system is a client/server system. The server is a large program (it is a distributed database and a remote monitoring system), and the client is a very small easily portable program.

Thus, the server is available for RedHat 6.2 (and therefore also 7.0, the 6.2 version will work there), Debian 2.2, FreeBSD 4.0, NT 4.0 (and therefore also Win2K).

The client is available for the same platforms, plus, RedHat 5.2 (with a Linux 2.0 kernel), and FreeBSD 3.4.

As you will have noticed, the software is in beta, but we are *very* close to a release. There are bugs left, but we will have a release out fixing the last known ones, probably around the weekend.

Should anyone out there have oppinions, suggestions, demands or "other", for a commercial program soon-to-ship for Linux among other platforms, I would welcome such feedback.

Please use this e-mail address and check out the website.

And please accept my apologies for going slightly off-topic on the subject here.

Ok, I should have formulated that better...

Shared libraries lose their big benefits when every binary ships it's own version of that shared library. On win2k that has become the rule now, to avoid library version conflicts.

On GNU/Linux (and most other systems), you *can* ship a separate version of that library with each binary that requires it. But the libraries will be installed at the standard locations, so if more apps require the same version, they will actually share the library. This is what RedHat used in the glibc-compat package, which provides a compatibility library so that RedHat 6.2 binaries will run flawlessly on RedHat 7.0, using the proper versions of their shared libraries, while the "native" RedHat 7.0 binaries run on the newer libraries. Simple, elegant.

Our Linux apps (currently on RedHat 6.2 only) ships with a special libstdc++, which we will probably be the only ones using. However, because of RedHat's approach, we will not do this in the next release, it is perfectly reasonable to simply use the compatibility libraries on 7.0 and the native libraries on 6.2. Once we start supporting a stable 7.X platform, we will of course run on the native library versions there.

On NT and Win2K we must ship specific versions of some DLLs in order to get anything running. There is no backwards compatibility, and there is no DLL versioning. It is of course very simple to just ship your own DLLs, and it works perfectly well, I am just arguing that I fail to see the problem with the GNU/Linux (and most UNIX like systems) approach. Especially given great vendor support such as what we see from RedHat (and probably others too).

It is not usually an option for a vendor to link statically because of license restrictions.

However, a vendor is allowed to ship a specific version of glibc and libstdc++ with the software, as long as they provide some reasonable access to the source code as well.

As posted somewhere else, that is what we ended up doing for the RedHat 6.2 port of our network monitoring software. We ship a version of libstdc++ that matches our binary, it is installed without interfering with the other versions of libstdc++ that may be installed on the system, and everyone's happy.

Really, I am surprised how well this stuff works, and I cannot understand why so many people keep complaining about how horrible the system is. I think it's brilliant. And programs can still share the shared libraries, it's not like the Win2K way of doing things, where each app ships it's own set of so-called "shared libraries".

I work for a company building a network montioring system available for FreeBSD, NT (and 2K), and both RedHat and Debian Linux. We're adding platforms as people request them.

Really, RedHat 7.0 includes the libraries that shipped with 6.2, so while we only support RedHat 6.2 we still work out-of-the-box on RedHat 7.0. Why not use the compatibility libraries ? That's what they're there for - they're not performing worse or anything, they are just older versions of the library.

On UNIX-like systems you actually have VERSIONING on your system libraries. So you can have a perfectly running system with ten different versions of the C library, and each application will use the version it requires.

You're welcome to check out our beta-versions available from sysorb.com, if you don't believe me :)