Slashdot Mirror

http://wireshark.zing.org/download/osx/Wireshark%201.0.0%20Intel.dmg

Netsaint I think netsaint i very cool. I.t checks for services in various network devices therefore reporting on uptime etc.. Sends out emails if one device goes down and so on. Very configurable. Love it, also ties in nicely with Cricket(link the devices with their respective cricket pages).A reporting tool for netsaint(Impress your boss!!)here

Cricket bases on rrdtool which is written by Tobi Oetikers(the guy who wrote MRTG. If you look at the rrdtool page you see various other frontends, I just happen to like cricket. Great for graphing routers and switches(and pretty much else) through snmp(you can configure it to graph other things, for example their is a package that creates graphs of the RTA's of devices in netsaint(look at the cricket contrib page.

ntop ntop, a sniffe with a web based interfaces(and a console one) were nice for monitoring various aspects of parts the network. Check out one of the newer cvs snapshots

I haven't had time to check out OpenNMS yet. Another nice tool is ethereal, a awesome gui sniffer.
One thing that is especially great about netsaint and cricket and netsaint is the great number of 3rd party addons, which make life a lot easier

The open source ethereal network analyser Ethereal at zing.org has a large number of protocols defined.

Another good analysis package is the SNORT intrusion detection system at snort.org

However, on a properly configured network most people will be properly isolated from seeing most traffic due to switching. I used to be on a very busy hub. I could see pretty much everything. It was very interesting. After they got more connections installed to get rid of the hub we all went to the switch. Now I only see stuff for me and broadcast stuff.

As a side note, I have to say the Ethereal packet analyser is one of the best peices of open source software I have ever seen. I think there's a lot of crappy open source stuff out there that gets a lot more credit then it deserves but Ethereal is excellent and does not suffer from these problems as far as I can tell. It doesn't get every packet right and occationally it crashes but it's not 1.0 yet. I have been using it for some time to reverse engineer the CIFS protocol(Microsoft Windows native file and print sharing protocol) and it works fantastic. It basically made the project possible. I have spend probably _hundreds_ of hours in front of it.

http://www.zing.org

Thanks Richard!

KidSock

I pride myself in contributing lots of humble changes or fixes to lots of projects. Still, I'm not in the business of getting my name in the AUTHORS file of every project under the sun (even though it a nice side effect of a hobby that exploded :-) My motivation is to make my life easier and more fun, while contributing to the public good.

The most flattering thing that was ever said about my contributions was hidden in the URL of an interview by Feed Magazine. When I showed this URL to my family, the reaction was "wait a sec! Bottomfeeders? Isn't that a bit derogative?". It took quite some explaining to make it clear that it was the culmination of what I've done over the years: I've joined the hordes of folks who, by submitting small patches, fixes, bits of functionality, have made the difference between making Open Source a hobby of a select few, and making it a (possibly) useful tool.

Oh well. I hope the folks at Orbiten will improve the situation (I'm sure their mailboxes will suffer the slashdot effect), and make the relative merit of their measuring methodology more clear. It is gratifying to see that someone picked up the odious task of trying to quantify what Open Source has to offer.

As a side note, I lost my previous (very well written, thanks for noticing!) reply to this message because of accidentally clicking on a banner ad on slashdot. Oh, for the irony!

What I was referring to would be something a bit more like Debian, where things are quite so user-friendly and "windowsish". In other words, a distribution that would be more fun for developers to play around with.

"Fun" in what sense? I don't consider configuring and tweaking a machine anywhere near as much "fun" as developing software for it; I have no problem with a "user-friendly and 'windowsish'" desktop, say - one of the reasons I use KDE on my machine at home is that the environment it gives me is "good enough" that I need to spend a lot of time figuring out all the knobs and buttons I needed to tweak to make it "good enough" for me.

I'd rather be editing source code for Ethereal, say, than editing configuration files.... (And, when trying to look into a networking bug, I'd rather be looking at network traces with Ethereal, say, than pawing through raw hex dumps of packets; part of the reason I got involved with Ethereal in the first place was that neither snoop, nor tcpdump, nor Microsoft's Network Monitor could cope with NFS or SMB requests or replies that required more than one frame. Having had to pull apart an NFS READDIR reply by hand, I decided that it was the sort of work best done by a computer, rather than by a human....

Ethereal can't yet handle multiple-frame "packets", either, but it's something we want to do, and we have some ideas about how to do it.)

I.e., as I said in another comment in another thread:

I'd rather use my brain cells doing software development than configuring software tools, tweaking my system so that it recognizes my PnP ISA sound card, blah blah blah.

(I also think that a system that doesn't need configuration is preferable to a system that offers a Nice Friendly GUI for configuration. If the system can figure something out for itself, e.g. what sort of peripherals it has, or what properties some peripheral has, it shouldn't oblige you to tell it that something, regardless of whether you do it by editing a configuration file or pushing buttons on a nice shiny GUI application.)

I suspect many claims of fragmentation of Linux may be overstated.

However, I think the claim:

The Linux world is not fragmented at all--one kernel source tree and one user-land source tree goes into every single Linux distribution out there.

is also overstated.

First of all, there's the issue of versions of software. Linux distributions are built from many pieces maintained by different people, so it is possible that a given release one distribution might have a 2.2.x kernel and a 2.1.y glibc and so on, whilst a given release of another distribution that has the same 2.2.x kernel might have a different version of glibc, or a different version of utility XXX, or whatever - meaning that different user-land source trees are going into those distributions. Perhaps the next release of the second distribution uses the same version of glibc as the release in question of the first distribution, but it might then have a different kernel, or a different version of utility XXX or YYY, or whatever.

In addition, some distributions may well add their own changes to some or all of the components they bundle into their distributions. For example, it is not the case that all Linux distributions have "standard" versions of libpcap - Red Hat 6.1 has a patched version that, whilst it has some improvements, changes the format of capture files written by applications that use the libpcap code to write capture files (e.g., tcpdump) and doesn't change the magic number on those files. This obliged Ethereal, which uses its own library to read capture files in order to handle capture files that are not libpcap-format capture files, to go through some pain in order to be able to read

1. standard libpcap capture files;
2. libpcap capture files with the changed format and unchanged magic number;
3. libpcap capture files with the changed format and a different magic number, as produced by a later version of the patch than was picked up by Red Hat 6.1;

transparently (which the patched libpcaps don't do - the later patch can read the original format with the standard magic number, and can read the changed format with the new magic number, but can't read the changed format from files that use the standard magic number and that format; I can sympathize with the patch's developer for not doing so, as the hack I put into Ethereal's capture-file-reading library is really a bit gross, but, for Ethereal, I wanted it to be able to Just Work - hand it a capture file, and it consumes it, without having to be told what it is, regardless of whether the libpcap file that comes with the system on which it's running is capable of doing so). (I filed a bug on this, as did several other people; apparently a future Red Hat release will pick up a later patch, so that the libpcap files with a different file format will have a different magic number, and files from unpatched versions of libpcap can be read by tcpdump, for example.)

And, of course, not all Linux distributions have the same configuration file setup - for example, not all of them use a System V-style init and rc files.

I suspect there are people out there who can cite other examples of being bitten by differences between distributions, so I consider it an error to assert that "one kernel source tree and one user-land source tree goes into every single Linux distribution out there", or even to assert that the differences between the source that goes into those distributions don't cause any problems.

None of this, however, indicates that

1. Linux is necessarily any more badly fragmented than the BSDs (I suspect that, on the whole, it's easier to move software between Linux distributions than it is to move them from one BSD system to another, although I suspect most software probably moves with relatively little pain between Linux distributions, between BSD systems, from Linux distribution XXX to BSD system YYY, from BSD system YYY to Solaris, from Solaris to HP-UX, etc. - although there are presumably examples of pain caused by all of those transitions);
2. there is no fragmentation in BSD.

Likewise, unless you're Microsoft, you can't force anyone to use a particular widget set, UI, anything.

It's not clear you can even do that if you're Microsoft; one of the applications running on the NT partition of my home machine uses GTK+. (No, it's not the Gimp, it's Ethereal.)

There's also Qt for Win32 as well.

It is important to remember that CDE/Motif 2.1 is a large improvement over 1.2

E.g., it finally has widgets from which you can construct a tree view or a multi-column list (as one of the developers of Ethereal, my interest in toolkits that don't come with tree-view or multi-column list support is somewhat limited - yeah, there are probably alternative tree-view or multi-column list widgets out there, but having to supply it and have people have to compile it is a bit of a pain).

and that's why it was developed

Yeah, most new versions of products aren't specifically intended to be worse than their predecessors (although some products have been known to be improvements on their successors...)

--so if you're going to judge CDE/Motif, judge it by 2.1.

Except that if a lot of UNIX systems still ship with 1.2[.x], 2.1 isn't necessarily usable for many applications (unless you want to force people to upgrade in order to run your application, which you might be able to get away with for a commercial app, but I suspect you couldn't get people to do in order to run a free-software app).

By the way, do I risk an invasion from Hot Grits Man if I note that my copy of the OSF/Motif(TM) 2.0 Programmer's Guide has, right after the RESTRICTED RIGHTS NOTICE on the trademark and license page, a RESTRICTED TIGHTS[sic] LEGEND?

Other people likely to take the isk of using the new feature, because with the source code, they can fix anything that causes a problem

...which would also be true of {Free,Open,Net}BSD, as you have the source code.

then these fixes are given back to due to the GPL and all will benefit from them

...which is also often true of {Free,Net,Open}BSD as well.

In BSD, things happen slowley because the people working on it are more concerned with sercurity and stability.

Umm, how quickly do things happen in, say, the 2.2[.x] Linux kernel tree, as opposed to the 2.3[.x] tree? You appear to get at least some choice of "bleeding-edge" vs. "stable" there...

...and you also do with FreeBSD (and possibly the other BSDs), by going with the "-current" tree if you want to be on the bleeding edge or going with a "-stable" release if you don't.

Also, if someone does make a good change or add an important feature, they could always keep it and not share it, so these features will be adopted slowly.

That has nothing to do with adopting features, it has to do with whether they're available for the open-source BSDs to adopt - and there appear to be people contributing stuff back to the BSDs, e.g. Whistle have contributed a number of things to FreeBSD.

The end result is that Linux, while more prone to problem when using the latest and greatest kernal/library/etc, it more quickely adopts features that user want and need.

Well, maybe. Perhaps the ISA PnP tools, or the ISA PnP kernel patch, for Linux can be made tow work as well as the ISA PnP support has worked for me on my box (it handles my PnP ISA sound card just fine - no, I do not want a PCI sound card, I'd rather leave my PCI slots available for cards such as networking and SCSI cards), but the PnP ISA patch didn't work very well on the 2.0[.x] kernel on my Debian partition (I could've debugged it, but didn't particularly have any interest in doing so, as it Just Worked on FreeBSD), and it wasn't clear whether I'd have to update some config file to use the ISA PnP tools (I could've dug into that, but didn't particularly have any interest in doing so, as it Just Worked on FreeBSD).

I.e., I don't think it's as clear-cut as you describe - you can do bleeding-edge stuff with FreeBSD (and perhaps the other ones) if you want, and you can do trailing-edge stable stuff with Linux if you want. (Note: "trailing-edge" is not being used as a pejorative here; heck, I don't run "-current" on my home machine, as I'm primarily using it for development of stuff for the Ethereal network analyzer, and for surfing/reading mail/etc., so I'm reasonably happy to be somewhat on the trailing edge.)

Actually, the first line of defense should be part of the e-mail *client*, not the server. It's the last paragraph of this article that indirectly points this out--the paragraph that says "Free, easy to use, public domain cryptographic tools are a necessity."

Crypto is your only real privacy protection. It's ridiculous that it's not readily available for everyone--it's not as if the technology isn't there. No, this won't stop DOS attacks and such, but it will guard your e-mail from prying eyes.

By the way, you may actually have better privacy on Hotmail than on your ISP. I've talked to former ISP employees that admit to printing out their users' "juicy" e-mails and passing them around the office each morning for fun. Besides that, cool software like Ethereal makes e-mail passing through your network segment on it's way to the server quite easy to read if it's unencrypted.

If you expect anyone other than yourself to protect the privacy of your e-mail, then you are kidding yourself.

numb@g27.org

The Ethereal site is here. (I shan't say what the best sniffer is, as I'm not exactly a neutral observer.... :-))

(Note also that Ethereal isn't Linux-only.)