There's a rather large difference between having a set of programmer's manuals and having the transistor-level
blurprints
Simple typo, or Freudian slip?:-)
of the logic implementation.
Yes - Intel probably just got the former, and made their own implementation of AMD64 (rev 1, without the two instructions AMD put back), and thus didn't do any reverse engineering.
If only ethereal could display SS7 or ISDN messaging to.
SS7 and ISDN messaging over what transport? It can't capture on MTP1 links or capture raw ISDN traffic, but if you're doing SS7-over-IP, Ethereal should be able to capture that, and it can also display Q.931 over TPKT over TCP. It can also handle at least some SS7 and ISDN captures from other sources.
EtherPeek can sniff on any ethernet interface, in fact on the Mac it uses libpcap
...at least on OS X - unless it uses raw BPF (if the EtherPeek executable is Mach-O, what does "otool -L" say about it?). The older non-OS X versions presumably didn't use libpcap or BPF.
AiroPeek for wireless sniffing (support for a number of cards)
...because they had to supply their own drivers, thanks to the lack of any standard mechanism in Windows by which drivers for 802.11 cards can supply 802.11 packets to NDIS and offer standard NDIS OIDs to request monitor mode and the like. Ethernet doesn't have that problem, so EtherPeek on Windows can just connect to Ethernet drivers through NDIS (just as WinPcap does).
...or even a distributed RFGrabber device for sniffing.
No, it works on many other UN*Xes (on at least some of which it ran before it ever ran on Linux), just as Ethereal does, and it even works on Windows, as long as you replace "tcp" with "win":-) - WinDump is a port of tcpdump to Windows, done by the WinPcap developers.
It's pretty easy to configure a router to copy each packet to a specific port for analysis by a dedicated machine.
Well, for some routers/switches, anyway.
There's even an entry in the Ethereal FAQ and an entry in the tcpdump FAQ about that, including links to documentation for at least some switches for doing "port monitoring". (If people have links for switches not listed there, send them on to the ethereal-users or tcpdump-workers mailing lists so we can add them to the FAQs.)
What is it that makes you think it is so incredible within this genre of applications?
For some users, the fact that, unlike Sniffer Pro or Etherpeek, it runs on operating systems that don't come from Redmond, Washington, USA or, in the case of Etherpeek but not Sniffer Pro, Cupertino, California, USA, certainly helps make Ethereal popular.
The one feature this has over most all others is that you can capture AND look at traces at the same time. Most (Ethreal included) require you to capture a "snapshot" then to "post-analysis".
Ethereal: capture with "Update list of packets in real time" enabled (although that might miss packets if you're capturing a lot of traffic).
The only down side is their "driver" depends upon the underlying OS and on MAC OS 9, the timestamps were a not that accurate.
The same applies to Ethereal and tcpdump (which, being libpcap/WinPcap-based, rely on the underlying OS's drivers).
Unless I missed something, Ethereal and tcpdump use the same library (libpcap)
True.
...but tcpdump isn't the "underneath" Ethereal.
True.
Ethereal is very good at breaking down any Ethernet frame, where as TCP dump, as far as I know, only deals with TCP/UDP/IP packets.
Ethereal has dissectors for more protocols than tcpdump does; however, tcpdump has dissectors for more than just TCP/UDP/IP (some protocols atop them, such as NFS, as well as non-IP-based protocols, including 802.11 management frames).
But didn't the Big-Mac supercomputer run Linux instead of OS X?
If by "the Big-Mac supercomputer" you mean Virginia Tech's G5 cluster, the answer to your question is "no" - see their slide presentation on it, in particular page 13, "Software" of that PDF.
Ok, sure, there are Windows versions of these programs. In fact there are PalmOS and BeOS (check Ethereal's web site if you don't believe me) versions as well
Yes, I believe you for BeOS, but not for PalmOS; there's an entry that lists BeOS, and says "Be (Palm?)", but that refers to the "owner"/maintainer/distributor of the OS, and Be no longer exists, with Palm having bought their intellectual property - there's no entry for PalmOS. (Not only have I checked Ethereal's Web site, I've written much of the FAQ on that site - as well as much of the Ethereal code, including some of the Windows support....)
but are they in widespread use?
That appears to be the case for the Windows version - a number of the questions on the Ethereal mailing list come from Windows users (and a number of the Ethereal developers are doing their development on Windows!), and there are a large number of downloads of the Windows installer for Ethereal (47517 downloads of the Ethereal 0.10.0 installer in February, for example).
You obviosly missed the point of my post, that Winows ME is more stable/reliable than OS X is a load of crap.
I wasn't addressing that point - which wasn't what you were addressing, either, in the part to which I was replying. Windows Me is "Windows OT", while OS X is "Mac OS NT"; the original poster was probably either trolling/flamebaiting or confusing "Mac OS OT" (pre-X) with OS X.
I was addressing the claim that Microsoft Orifice plus UNIX admin tools "just doesn't happen in the Windows environment", by noting that at least some of those "UNIX admin tools" are also available on Windows.
It's a great combination of useablility (i.e. MS Office and UNIX Sys Admin tools nmap, ethereal, etc.) that just doesn't happen in the Windows environment.
The two "UNIX Sys Admin" tools you mention by name - Nmap and Ethereal - both run on Windows.
Re:sensationalism... bleh...
on
Three Headed Frog
·
· Score: 2, Insightful
The fact that their pond was 2-3 Kelvin warmer than it would have been 50 years ago has nothing to do with this freak occurance.
The comment to which you're responding said "environmental problems", not "global warming".
till i don't find anything mentioned about the os requiring a reboot for changing the time zone ! ! !
Yeah, the system time zone is an environment variable setting (TZ), and there's no mechanism to use to tell existing processes to change their TZ setting and reload the time zone file.
Are there any other UN*Xes that let you change the time zone setting and have it affect processes that are already running? (Unless the UN*X in question explicitly documents that you can do this, don't say "yes" until you've actually tried it.)
I don't remember whether, in any version of Windows, you can change the time zone setting and have it affect existing processes.
I'm not saying that, if no other UN*Xes can handle a time zone change on the fly, that lets Solaris off the hook. A mechanism to allow that (whether by explicitly delivering notifications or by, for example, having some file contain a string with the current system TZ setting and a sequence number that's incremented each time the setting is changed, having tzset()mmap() the file, and having the code that converts between local time and UN*X time check whether the sequence number has changed since the last time it was called and, if so, have it reload the settings) might be useful
Solaris Express is Sun's program to allow users to preview upcoming versions of Solaris. It IS NOT Solaris 10.
True, but TFA makes the same mistake - it says things such as:
Solaris Express has a redesigned network stack to improve scalability and performance.
Solaris Express includes increased IPv6 support./etc/nsswitch.conf file policies for the hosts and ipnodes databases are included when IPv6 is enabled during installation. To avoid connection timeouts, IPv4 addresses for remote IPv6 capable hosts will be used if no IPv6 routes serve that host. IPv6 networks can also transfer packets over Internet Protocol Version 4 (IPv4) networks now by configuring a router to support a 6to4 tunnel.
and so on.
Re:Spectrum is finite, internet is infinite
on
What The Internet Isn't
·
· Score: 2, Insightful
Hmmm, I didn't realize there was a maximum frequency
He said "RF spectrum". Radio frequencies don't go up to infinity (well, I don't have a radio that goes up to gamma rays, at least).
Today's microprocessors have yet to catch up with the reliability, availability and maintenance features of IBM's large systems.
That is, to some degree, an apples-to-oranges comparison, as you're comparing microprocessors to complete computer systems.
I can think of one microprocessor that, by definition, is used in systems "with the reliability, availability, and maintenance features of IBM's large systems", as it's the microprocessor used in the CPUs of those systems.
Now, it might be that the z900 microprocessor has RAS features not present in commodity microprocessors; for example, the article on RAS design for the z900 says that
The on-chip Level 1 (L1) cache can survive an array failure by purging and deleting the cache line or compartment. The L1 cache "fuse" relocation technology allows the defective cache line to be relocated (L1 cache-line sparing) at the next FPOR.
I don't know offhand whether any other microprocessors support anything such as that - a Google search for "cache-line sparing" found a few hits, but they're all about System/390 or System/3100^Wz/Architecture. If somebody feels ambitious, they could look at recent server x86/SPARC/IA-64/Power-family/PA-RISC/etc. chips and see if they have anything like that.
I wouldn't be suprised if Intel tried to 'lock out' Linux, too.
Presumably you mean locking out with something other than EFI, given that Linux supports EFI, as this ArsTechnical article notes ("Nevertheless, one thing is certain: Linux already runs on EFI boxen, so this isn't some evil ploy to kick Linux off of the PC.")
Most source files that, when compiled, have RCS IDs in the resulting object file, and that are used to build tools, came from OpenBSD.
Try running a script such as
for i in/usr/bin/*/bin/*/sbin/*/usr/sbin/* do echo $i: ident $i 2>/dev/null | egrep '(Free|Net|Open)BSD' done
and look at the output. Many tools have no RCS IDs in the binary. Some of them have multiple RCS IDs in them, as more than one source file for a tool in that set has an RCS ID in it that shows up in the object file.
If we prune that output to leave, for each tool, only one line for each OS for each tool, we get 85 lines for NetBSD, 75 lines for FreeBSD, and 19 lines for OpenBSD - OpenBSD is overrepresented in your results because, for example, the OpenSSH stuff came from OpenBSD, with each tool having multiple source files, and most if not all of those files put the RCS ID into the binary.
NetBSD is slightly overrepresented by the counts I gave, as Panther's yacc came from NetBSD, and its skeleton parser puts an RCS ID into the object file; if we remove those 7 lines, we get 78 for NetBSD.
Of course, there are a lot of commands that don't have any RCS information at all. 171 commands do, but there are a total of 928 commands. This means that your counts and my counts don't necessarily give any believable information about the number of tools that came from FreeBSD, NetBSD, or OpenBSD, unless all the tools without RCS IDs came from elsewhere (GNU, Apple, etc.).
Correct me if i'm wrong, but isnt the KDE team currently getting a version of KDE ready for Mac OS X? It doesnt take a genius to figure out where this is heading.
Heading towards a version of KDE for Mac OS X?
Heading towards a choice, for Mac OS X, between two browsers using the KHTML code - Konqueror and Safari?
Slashdot Mirror
Simple typo, or Freudian slip? :-)
Yes - Intel probably just got the former, and made their own implementation of AMD64 (rev 1, without the two instructions AMD put back), and thus didn't do any reverse engineering.
I suspect if you tried tcpdump on your Solaris server it'd get traffic in both directions with "host foo".
What OS is your firewall running? And is it doing any NAT stuff as well?
SS7 and ISDN messaging over what transport? It can't capture on MTP1 links or capture raw ISDN traffic, but if you're doing SS7-over-IP, Ethereal should be able to capture that, and it can also display Q.931 over TPKT over TCP. It can also handle at least some SS7 and ISDN captures from other sources.
...at least on OS X - unless it uses raw BPF (if the EtherPeek executable is Mach-O, what does "otool -L" say about it?). The older non-OS X versions presumably didn't use libpcap or BPF.
...because they had to supply their own drivers, thanks to the lack of any standard mechanism in Windows by which drivers for 802.11 cards can supply 802.11 packets to NDIS and offer standard NDIS OIDs to request monitor mode and the like. Ethernet doesn't have that problem, so EtherPeek on Windows can just connect to Ethernet drivers through NDIS (just as WinPcap does).
That's based on the old WSP100 device from Network Chemistry. BTW, those devices probably use Network Chemistry's Tazmen Sniffer Protocol, so other applications that handle that protocol, such as Kismet, should also work with them.
Eh? "host foo" in tcpdump captures traffic to or from foo, just as it does in snoop.
No, it works on many other UN*Xes (on at least some of which it ran before it ever ran on Linux), just as Ethereal does, and it even works on Windows, as long as you replace "tcp" with "win" :-) - WinDump is a port of tcpdump to Windows, done by the WinPcap developers.
Well, for some routers/switches, anyway.
There's even an entry in the Ethereal FAQ and an entry in the tcpdump FAQ about that, including links to documentation for at least some switches for doing "port monitoring". (If people have links for switches not listed there, send them on to the ethereal-users or tcpdump-workers mailing lists so we can add them to the FAQs.)
For some users, the fact that, unlike Sniffer Pro or Etherpeek, it runs on operating systems that don't come from Redmond, Washington, USA or, in the case of Etherpeek but not Sniffer Pro, Cupertino, California, USA, certainly helps make Ethereal popular.
Ethereal: capture with "Update list of packets in real time" enabled (although that might miss packets if you're capturing a lot of traffic).
The same applies to Ethereal and tcpdump (which, being libpcap/WinPcap-based, rely on the underlying OS's drivers).
Err, umm, Ethereal (at least for IRIX 6.5)?
True.
True.
Ethereal has dissectors for more protocols than tcpdump does; however, tcpdump has dissectors for more than just TCP/UDP/IP (some protocols atop them, such as NFS, as well as non-IP-based protocols, including 802.11 management frames).
No, they didn't.
Clorox did.
If by "the Big-Mac supercomputer" you mean Virginia Tech's G5 cluster, the answer to your question is "no" - see their slide presentation on it, in particular page 13, "Software" of that PDF.
Yes, I believe you for BeOS, but not for PalmOS; there's an entry that lists BeOS, and says "Be (Palm?)", but that refers to the "owner"/maintainer/distributor of the OS, and Be no longer exists, with Palm having bought their intellectual property - there's no entry for PalmOS. (Not only have I checked Ethereal's Web site, I've written much of the FAQ on that site - as well as much of the Ethereal code, including some of the Windows support....)
That appears to be the case for the Windows version - a number of the questions on the Ethereal mailing list come from Windows users (and a number of the Ethereal developers are doing their development on Windows!), and there are a large number of downloads of the Windows installer for Ethereal (47517 downloads of the Ethereal 0.10.0 installer in February, for example).
I wasn't addressing that point - which wasn't what you were addressing, either, in the part to which I was replying. Windows Me is "Windows OT", while OS X is "Mac OS NT"; the original poster was probably either trolling/flamebaiting or confusing "Mac OS OT" (pre-X) with OS X.
I was addressing the claim that Microsoft Orifice plus UNIX admin tools "just doesn't happen in the Windows environment", by noting that at least some of those "UNIX admin tools" are also available on Windows.
The two "UNIX Sys Admin" tools you mention by name - Nmap and Ethereal - both run on Windows.
The comment to which you're responding said "environmental problems", not "global warming".
Yeah, the system time zone is an environment variable setting (TZ), and there's no mechanism to use to tell existing processes to change their TZ setting and reload the time zone file.
Are there any other UN*Xes that let you change the time zone setting and have it affect processes that are already running? (Unless the UN*X in question explicitly documents that you can do this, don't say "yes" until you've actually tried it.)
I don't remember whether, in any version of Windows, you can change the time zone setting and have it affect existing processes.
I'm not saying that, if no other UN*Xes can handle a time zone change on the fly, that lets Solaris off the hook. A mechanism to allow that (whether by explicitly delivering notifications or by, for example, having some file contain a string with the current system TZ setting and a sequence number that's incremented each time the setting is changed, having tzset() mmap() the file, and having the code that converts between local time and UN*X time check whether the sequence number has changed since the last time it was called and, if so, have it reload the settings) might be useful
True, but TFA makes the same mistake - it says things such as:
and so on.
He said "RF spectrum". Radio frequencies don't go up to infinity (well, I don't have a radio that goes up to gamma rays, at least).
Belgium? Or Poland? Also, France declared war on Germany at the same time.
That is, to some degree, an apples-to-oranges comparison, as you're comparing microprocessors to complete computer systems.
I can think of one microprocessor that, by definition, is used in systems "with the reliability, availability, and maintenance features of IBM's large systems", as it's the microprocessor used in the CPUs of those systems.
Now, it might be that the z900 microprocessor has RAS features not present in commodity microprocessors; for example, the article on RAS design for the z900 says that
I don't know offhand whether any other microprocessors support anything such as that - a Google search for "cache-line sparing" found a few hits, but they're all about System/390 or System/3100^Wz/Architecture. If somebody feels ambitious, they could look at recent server x86/SPARC/IA-64/Power-family/PA-RISC/etc. chips and see if they have anything like that.
Presumably you mean locking out with something other than EFI, given that Linux supports EFI, as this ArsTechnical article notes ("Nevertheless, one thing is certain: Linux already runs on EFI boxen, so this isn't some evil ploy to kick Linux off of the PC.")
Here's what Netcraft has to say....
Most source files that, when compiled, have RCS IDs in the resulting object file, and that are used to build tools, came from OpenBSD.
Try running a script such as
and look at the output. Many tools have no RCS IDs in the binary. Some of them have multiple RCS IDs in them, as more than one source file for a tool in that set has an RCS ID in it that shows up in the object file.
If we prune that output to leave, for each tool, only one line for each OS for each tool, we get 85 lines for NetBSD, 75 lines for FreeBSD, and 19 lines for OpenBSD - OpenBSD is overrepresented in your results because, for example, the OpenSSH stuff came from OpenBSD, with each tool having multiple source files, and most if not all of those files put the RCS ID into the binary.
NetBSD is slightly overrepresented by the counts I gave, as Panther's yacc came from NetBSD, and its skeleton parser puts an RCS ID into the object file; if we remove those 7 lines, we get 78 for NetBSD.
Of course, there are a lot of commands that don't have any RCS information at all. 171 commands do, but there are a total of 928 commands. This means that your counts and my counts don't necessarily give any believable information about the number of tools that came from FreeBSD, NetBSD, or OpenBSD, unless all the tools without RCS IDs came from elsewhere (GNU, Apple, etc.).
Heading towards a version of KDE for Mac OS X?
Heading towards a choice, for Mac OS X, between two browsers using the KHTML code - Konqueror and Safari?