To fully access the data stack from eth0 or wlan0 you need to run wireshark as root otherwise your trace will not be complete.
Nope.
For one thing, Wireshark shouldn't be accessing the network interfaces, it should be asking the dumpcap program, which is one of the components of Wireshark, to do so. To quote Wireshark's README.packaging file:
WIRESHARK CONTAINS OVER TWO MILLION LINES OF SOURCE CODE. DO NOT RUN THEM AS ROOT.
For another thing, the README.packaging document (in the "Privileges" section, which contains that rather emphatic quote), and the CaptureSetup/CapturePrivileges page in the Wireshark Wiki, discuss ways in which you can avoid even running dumpcap as root - it may need additional privileges, but not full root privileges.
All packet sniffers technically need to have root to be effective on any Unix like system.
Nope. See the above documents and the main libpcap man page (following "Reading packets from a network interface may require that you have special privileges:"). That's what the ChmodBPF script installed by Wireshark on OS X does; see the "Under BSD (this includes Mac OS X)" section - it does the "some other way to make that happen at boot time".
This message was not sent from an iPhone because Peter Sellers really was a deviated prevert without a dime for the call
Presumably he had to answer to the Coca-Cola company for that?
I don't use software that chmods or chown mydirectories. Wireshark has done so. Citation? Look it up. Wireshark sucks.
Well, I looked it up, and there are no chmod or chown calls in the Wireshark source (trunk, 1.10, or 1.8), and there are no obvious pages found by Teh Google about this.
Citation (and, no, "look it up" isn't a citation, it's a trick used by people who don't actually have citations) or it didn't happen.
When last I heard, a few years ago, QT had been acquired by Nokia. More recently, it seems that Nokia is being acquired by the borg(Microsoft).
It would seem that QT is to be owned by Microsoft. Is this correct? If so, what does that hold for QT? I realize that QT is LGPL or some such, but that doesn't mean that Microsoft won't ruin it or snuff it out. See Oracle and MySQL for a road map. Hopefully I am wrong.
Well with GTK+ being cross platform, Wireshark on MacOS still required using the X Windows interface. So will the move to Qt finally make it a native app?
It will make it an app that doesn't use X11 on OS X.
It won't make it an all-Cocoa app (although it will, modulo issues with QtMacExtras, use the native toolbar widget, at least, and, time permitting, it'll use the native file dialog sheets rather than the definitely-doesn't-look-like-OS-X Qt file dialog).
It won't be sufficient to make it an app following the OS X "one process for all open windows" model; that would require, for example, replacing all the static variables holding dissection state with per-open-file variables (doable, but a fair bit of work). Whether that will be done for 1.12 is another question.
I wondered what a kernel panic looked like. Ten years of Linux and never experienced that myself. I guess KDE is more stable than Android (or the computer's hardware is better).
Presumably you either mean "the Linux kernels I've run on my machines are more stable than the Linux kernel running on that particular Android machine" or "KDE and the rest of the userland is less likely to provoke a kernel panic than the Android userland".
I would like to see a lower-cost, ARM-based Apple laptop. They are merging they software development kits to make desktop-class applications coded to run on ARM, so it might be in the roadmap.
I don't know what you mean by "They are merging [their] software development kits", but, as far as I know, there are still separate iOS and OS X SDKs.
They might port the parts of Darwin not present in iOS to ARM (where "port" largely means "compile for and fix what, if anything, breaks"), and port the not-already-shared parts above Darwin (e.g., AppKit - Foundation is already shared), with the same meaning of "port", but that's not convergence.
I'm not sure about that. It has been known since 2007 that Apple is tinkering with Mac OS X on ARM. Now that Apple has their own version of ARM, how long before they eye the Intel processor and think "not invented here." Apple is notorious for not conforming to any standard they don't have to. The step from Intel to an Apple ARM processor is the first step to this and it's going to happen probably within 5 years.
...the result of which would be a Mac, running OS X (not iOS), with an ARM processor. Merging iOS and OS X has nothing to do with making an ARM-based Mac.
No, and not Shuttleworth, either, so his claim about what Apple will do is worth about as much as all the various random bloggers/columnists also saying "oh, yeah, iOS and OS X will become the same OS some day", i.e., it's worth nothing. Maybe they will, but there's no concrete evidence that they will.
A language's usefulness is more a matter of the abstractions it supports than the particular libraries available
Not that the libraries aren't useful. All other things being equal, including the stuff you don't have to write in that language because somebody else has already done so, yes, a language with clean abstractions is better than a language with not so clean abstractions, but the libraries aren't exactly chopped liver.
Many years ago, a poster commented that the work necessary to complete a particular project was the equivalent of writing a compiler; he was trying to emphasize just how broken and unmaintainable the code was. The irony in his statement is that most professional projects are far more complex than a compiler needs to be; because he didn't understand how they worked, he thought of them as necessarily complex. However, the operation of a compiler is actually quite simple to someone who understands how they work; the McCarthy paper shows how high level code constructs can be easily broken down into lower-level machine language instructions, and Knuth implements a MIX interpreter in a few pages in the "The Art of Computer Programming." Neither building a compiler nor an interpreter are monumental undertakings if you understand the principles of parsing and code structure. i.e., what does it mean if something is an operator, versus, say, an identifier.
You are aware that a compiler is more than just a parser, right? There are these minor sub-projects of a compiler called "code generators" and "optimizers". Understanding the principles of parsing and code structure won't help you understand the principles of optimizing and generating code.
Spend some time commuting on I-280 (the Junipero Serra Freeway) and you'll soon realize that it's clogged with people doing 5 mph under the speed limit in the fast lane...
Spend some time on 280 at the right time of day and you'll soon realize that some sections are clogged with people doing 40+ mph under the speed limit in all lanes.
Being larger makes a person better at sports where greater size (which is probably a proxy for muscle mass here) is an advantage. I'm not certain that, in all sports, a big muscle-bound person would be better than, say, a slim wiry person.
Boys are, on average, larger, but, then, the average person has (approximately) one ovary and one testicle. A larger boy would be better than a smaller boy at a sport where greater size is an advantage, but a larger girl might be better than that same smaller boy at that sport.
Mobile has a completely different IPC model that can't be supported by a 'desktop' style GUI. Specifically, you can't have applications sending each other input events willy-nilly.
What about "I use this machine a lot while I'm not sitting down" prevents applications from sending each other input events as they choose?
As I understand it, that single-line 20 Mb/s is only possible if you live basically right next to the CO or a DSL-enabled remote terminal (RT). By the time you get to my distance, ADSL2+ is only slightly faster than plain jane ADSL, circa 1998.
We’ve also seen some inquiries about qualification distances for these products. While qualification distance can vary based upon individual conditions, here are the general guidelines. This is subject to change based upon our observations about performance in the field, because we never want to over promise and fail to deliver.
3Mbps/2Mbps: 11,100ft (2.1 miles)
6Mbps/2Mbps: 9,500ft
12Mbps/2Mbps: 8,000ft
18Mbps/2Mbps: 6,600ft
30Mbps/2Mbps: 5,000ft
for pair-bonded ADSL2+, so divide by 2 to get non-pair-bonded results. That gives 1.5Mbps/1Mbps at 2.1 miles, which is about what I got for download and better than what I got for upload back in the late '90's. How far are you from the CO or RT?
to be honest, i never quite understood all that BSD/Mach stuff. what exactly is a kernel vs a linux or operating system?
In most operating systems, there's a component that runs in a more privileged processor mode; that code is "the kernel" plus, if the kernel supports them, any loadable kernel modules that have been loaded.
"Linux" is sometimes used to refer to the Linux kernel, which is used as the kernel in various "Linux distributions", and it's sometimes used to refer to a distribution as a whole.
An operating system generally includes components other than the kernel; some people consider the kernel (and perhaps the loadable kernel modules) to be the operating system, others don't.
how can something be both bsd and mach, but not unix?
"Unix" is used for a whole bunch of different purposes. Sometimes it refers to the operating systems that AT&T made available in the 1970's, 1980's, and early 1990's, sometimes it refers also to operating systems that were based on AT&T's code (BSD, SunOS/Solaris, HP-UX, AIX, IRIX, etc.) even if the developers replaced a lot of the AT&T code with their own code, and sometimes it refers to those operating systems, regardless of how much AT&T code is in them, that have passed the Single UNIX Specification test suite and thus can have the trademarked name "Unix" associated with them.
OS X is in the second of those two categories (with only a small amount of AT&T code left, just as do the current BSDs) and, as of OS X Leopard, is also in the third of those categories, so it's based on BSD and Mach, and is Unix in one of those senses. Prior to Leopard, it was only "Unix" in the second sense, so somebody could use that to say it wasn't "Unix", even though it was "Unix-like" in the strong sense (see below).
all I know is there's a command prompt and it's not dos, so... case in point.
Lots of OSes have non-DOS-style command prompts, and not all of them are Unix or even "Unix-like", either in the weak sense of "sort of looks like Unix, but is sufficiently different that nobody'd mistake it for Unix" or the stronger sense of "compatible with Unix, even if it's not based on AT&T code and hasn't been tested with the Single UNIX Specification test suite (most if not all Linux distributions are "Unix-like" in that strong sense).
(And not all OSes with a DOS-style command prompt are DOS - OSes in the Windows NT family have a kernel and userland that's not at all DOS-derived, but the cmd.exe application provides a command prompt that's DOS-like.)
I'm saying that you're right when you say "OS X has a BSD+Mach kernel" and you're wrong when you say "They're the same thing!" if by "they" you mean OS X and FreeBSD (i.e., people trying to use OS X as evidence of large market share for FreeBSD are wrong; it's evidence for large market share for BSD UNIX in general, but not any of {Free,Net,Open,DragonFly}BSD in particular).
If you didn't mean OS X and FreeBSD by "they", what did you mean?
ok, so you're saying I'm wrong? OSX does not have a BSD Mach kernel?
OS X's kernel is a BSD+Mach+various Apple stuff hybrid, many of its loadable kernel modules are BSD-derived, and the Unix part of its userland is a BSD+GNU+various Apple stuff+various other stuff hybrid; that doesn't mean that OS X is the same thing as FreeBSD, even if most of the BSD stuff is FreeBSD-derived.
Sorry to break it to you, but there's a Mach kernel working inside your system, not a FreeBSD kernel as many idiots like to believe.
More precisely, there's a kernel composed of Mach-derived code (providing the low-level process and thread management, Mach messaging, VM system, and some low-level platformsupport), BSD-derived code (providing the high-level process management atop the Mach low-level code, VFS layer and some file systems that plug into it, and networking layer and networking stacks), and Apple-developed code in various places including I/O Kit. The Unix system call interface is provided by the BSD-derived code.
is fs a script because you aren't able to operate 'find',
fs is a script that runs find with a long list of file extensions because I'd rather not type the long list of file extensions in a find command every time I want to find source files. I can operate find, I just prefer to write a shell script to do it for me rather than doing it manually over and over again.
or is find simply not available on your oh-so-unixish os x?
As per the above, fs wouldn't work if find weren't available on OS X.
So it looks like mostly FreeBSD and a little of the old Mach
Well, if you call the osfmk directory of the XNU source a little, I guess it's "a little of the old Mach", although a fair bit of that code comes from NeXT and Apple as well.
I think NetBSD was used as a means for porting between architectures more than a literal inheritance.
Well, let's look at the libc source (the libc part of libSystem):
("fs" is a script that finds source files and prints their names to the standard output). The files it found with "NetBSD" in them were./gen/FreeBSD/fmtcheck.c,./gen/FreeBSD/lockf.c,./gen/FreeBSD/stringlist.c,./gen/NetBSD/utmpx.c,./include/arpa/tftp.h,./include/FreeBSD/nl_types.h,./include/getopt.h,./include/limits.h,./include/NetBSD/utmpx.h,./include/paths.h,./include/search.h,./include/stddef.h,./include/stringlist.h,./include/util.h,./include/wchar.h,./include/wctype.h,./stdlib/FreeBSD/getopt.c,./stdlib/FreeBSD/getopt_long.c,./stdlib/FreeBSD/hcreate.c,./stdlib/FreeBSD/tdelete.c,./stdlib/FreeBSD/tfind.c,./stdlib/FreeBSD/tsearch.c,./stdlib/FreeBSD/twalk.c,./stdlib/NetBSD/strfmon.c,./string/FreeBSD/strndup.c,./string/FreeBSD/wcscat.c,./string/FreeBSD/wcscmp.c,./string/FreeBSD/wcscpy.c,./string/FreeBSD/wcscspn.c,./string/FreeBSD/wcslcat.c,./string/FreeBSD/wcslcpy.c,./string/FreeBSD/wcslen.c,./string/FreeBSD/wcsncat.c,./string/FreeBSD/wcsncmp.c,./string/FreeBSD/wcspbrk.c,./string/FreeBSD/wcsspn.c,./string/FreeBSD/wmemchr.c,./string/FreeBSD/wmemcmp.c,./string/FreeBSD/wmemcpy.c,./string/FreeBSD/wmemmove.c,./string/FreeBSD/wmemset.c, and./util/fparseln.c.
The "NetBSD" and "FreeBSD" directory names are somewhat historical - for example, the 10.8.4 version of getopt_long() comes from NetBSD.
of course there are probably newer bits of FreeBSD used that are only known internally to Apple.
And other bits only known to people who download the open source bits and look at them.:-)
Then the timeline proceeds with Mac OS X as what appears to be where all of the development is taking place (including inheriting from FreeBSD), with Darwin and OS X Server only ever taking from OS X like mirrors. Then suddenly in 2006 this model changes and the OS X 10.5 beta inherits from Darwin 9.0 beta, when OS X 10.5 and Darwin 9 mature the model goes Darwin -> Mac OS X -> Mac OS X Server...
That's the timeline, not reality. Darwin was always produced by taking parts of OS X and making them available in source form; the model didn't change with Leopard.
Then in 2007 during the OS X 10.7 beta the model changes again when the server branch is eradicated all together and gets integrated into OS X and OS X gets integrated into Darwin so the model goes OS X -> Darwin again but without the server
The relevant bits of the FreeBSD userland are periodically (every major release) imported into OS X. The two systems are fairly different, so kernel changes in FreeBSD probably won't show up, but tweaks to command line tools and other stuff probably will.
The best way to think about it is that Darwin is "the kinda sorta fifth BSD", separate from {Free,Net,Open,DragonFly}BSD, but willing to pick stuff up from the *BSDs, just as the *BSDs are willing to pick up stuff from other *BSDs to various degrees.
The relevant bits of the FreeBSD userland are periodically (every major release) imported into OS X. The two systems are fairly different, so kernel changes in FreeBSD probably won't show up, but tweaks to command line tools and other stuff probably will.
Darwin is not a BSD kernel
Yeah, it's a kernel that's a combination of Mach and BSD.
heh, well the userland part of FreeBSD has more desktop installs than Linux distros.
Or, at least, part of the userland part of FreeBSD, combined with part of the userland part of NetBSD, combined with a bunch of vendor-written code, has more desktop installs that Linux distros (most of those "installs" being what was shipped with the machine; BTW, the auto-correct feature of the latest non-beta version of that vendor's OS tries to convert "distros" into "distress").
In theory, yes, I could bond two channels together.
Are you talking about two-line Fusion here? I.e., are you talking about trying to get more than the 20Mb/s maximum for single-line Fusion? (I certainly don't remember getting 20Mb/s from my ADSL back in 1998/1999....)
Slashdot Mirror
To fully access the data stack from eth0 or wlan0 you need to run wireshark as root otherwise your trace will not be complete.
Nope.
For one thing, Wireshark shouldn't be accessing the network interfaces, it should be asking the dumpcap program, which is one of the components of Wireshark, to do so. To quote Wireshark's README.packaging file:
For another thing, the README.packaging document (in the "Privileges" section, which contains that rather emphatic quote), and the CaptureSetup/CapturePrivileges page in the Wireshark Wiki, discuss ways in which you can avoid even running dumpcap as root - it may need additional privileges, but not full root privileges.
All packet sniffers technically need to have root to be effective on any Unix like system.
Nope. See the above documents and the main libpcap man page (following "Reading packets from a network interface may require that you have special privileges:"). That's what the ChmodBPF script installed by Wireshark on OS X does; see the "Under BSD (this includes Mac OS X)" section - it does the "some other way to make that happen at boot time".
This message was not sent from an iPhone because Peter Sellers really was a deviated prevert without a dime for the call
Presumably he had to answer to the Coca-Cola company for that?
Yes Qt will make it a non-X11, more native application on OS X (carbon, though if I recall correctly).
Newer versions of Qt support 64-bit programs, so they don't run atop Carbon.
I don't use software that chmods or chown mydirectories. Wireshark has done so. Citation? Look it up. Wireshark sucks.
Well, I looked it up, and there are no chmod or chown calls in the Wireshark source (trunk, 1.10, or 1.8), and there are no obvious pages found by Teh Google about this.
Citation (and, no, "look it up" isn't a citation, it's a trick used by people who don't actually have citations) or it didn't happen.
When last I heard, a few years ago, QT had been acquired by Nokia. More recently, it seems that Nokia is being acquired by the borg(Microsoft).
It would seem that QT is to be owned by Microsoft. Is this correct? If so, what does that hold for QT? I realize that QT is LGPL or some such, but that doesn't mean that Microsoft won't ruin it or snuff it out. See Oracle and MySQL for a road map. Hopefully I am wrong.
Fortunately, yes, you are wrong. Digia bought the business side of Qt from Nokia in 2012. The free-software side of Qt is the Qt Project.
Well with GTK+ being cross platform, Wireshark on MacOS still required using the X Windows interface. So will the move to Qt finally make it a native app?
It will make it an app that doesn't use X11 on OS X.
It won't make it an all-Cocoa app (although it will, modulo issues with QtMacExtras, use the native toolbar widget, at least, and, time permitting, it'll use the native file dialog sheets rather than the definitely-doesn't-look-like-OS-X Qt file dialog).
It won't be sufficient to make it an app following the OS X "one process for all open windows" model; that would require, for example, replacing all the static variables holding dissection state with per-open-file variables (doable, but a fair bit of work). Whether that will be done for 1.12 is another question.
I wondered what a kernel panic looked like. Ten years of Linux and never experienced that myself. I guess KDE is more stable than Android (or the computer's hardware is better).
Presumably you either mean "the Linux kernels I've run on my machines are more stable than the Linux kernel running on that particular Android machine" or "KDE and the rest of the userland is less likely to provoke a kernel panic than the Android userland".
I would like to see a lower-cost, ARM-based Apple laptop. They are merging they software development kits to make desktop-class applications coded to run on ARM, so it might be in the roadmap.
I don't know what you mean by "They are merging [their] software development kits", but, as far as I know, there are still separate iOS and OS X SDKs.
They might port the parts of Darwin not present in iOS to ARM (where "port" largely means "compile for and fix what, if anything, breaks"), and port the not-already-shared parts above Darwin (e.g., AppKit - Foundation is already shared), with the same meaning of "port", but that's not convergence.
I'm not sure about that. It has been known since 2007 that Apple is tinkering with Mac OS X on ARM. Now that Apple has their own version of ARM, how long before they eye the Intel processor and think "not invented here." Apple is notorious for not conforming to any standard they don't have to. The step from Intel to an Apple ARM processor is the first step to this and it's going to happen probably within 5 years.
...the result of which would be a Mac, running OS X (not iOS), with an ARM processor. Merging iOS and OS X has nothing to do with making an ARM-based Mac.
NOBODY WANTS THIS! Who's running Apple, Balmer?
No, and not Shuttleworth, either, so his claim about what Apple will do is worth about as much as all the various random bloggers/columnists also saying "oh, yeah, iOS and OS X will become the same OS some day", i.e., it's worth nothing. Maybe they will, but there's no concrete evidence that they will.
Cybernetics. Information Theory. Done. Everything else in the Universe can be mastered & described with these, even physics and quantum physics.
Your ideas are intriguing to me and I wish to subscribe to your newsletter. May I see your plane ticket to Stockholm?
A language's usefulness is more a matter of the abstractions it supports than the particular libraries available
Not that the libraries aren't useful. All other things being equal, including the stuff you don't have to write in that language because somebody else has already done so, yes, a language with clean abstractions is better than a language with not so clean abstractions, but the libraries aren't exactly chopped liver.
Many years ago, a poster commented that the work necessary to complete a particular project was the equivalent of writing a compiler; he was trying to emphasize just how broken and unmaintainable the code was. The irony in his statement is that most professional projects are far more complex than a compiler needs to be; because he didn't understand how they worked, he thought of them as necessarily complex. However, the operation of a compiler is actually quite simple to someone who understands how they work; the McCarthy paper shows how high level code constructs can be easily broken down into lower-level machine language instructions, and Knuth implements a MIX interpreter in a few pages in the "The Art of Computer Programming." Neither building a compiler nor an interpreter are monumental undertakings if you understand the principles of parsing and code structure. i.e., what does it mean if something is an operator, versus, say, an identifier.
You are aware that a compiler is more than just a parser, right? There are these minor sub-projects of a compiler called "code generators" and "optimizers". Understanding the principles of parsing and code structure won't help you understand the principles of optimizing and generating code.
Spend some time commuting on I-280 (the Junipero Serra Freeway) and you'll soon realize that it's clogged with people doing 5 mph under the speed limit in the fast lane...
Spend some time on 280 at the right time of day and you'll soon realize that some sections are clogged with people doing 40+ mph under the speed limit in all lanes.
Being larger makes boys better at sports.
Being larger makes a person better at sports where greater size (which is probably a proxy for muscle mass here) is an advantage. I'm not certain that, in all sports, a big muscle-bound person would be better than, say, a slim wiry person.
Boys are, on average, larger, but, then, the average person has (approximately) one ovary and one testicle. A larger boy would be better than a smaller boy at a sport where greater size is an advantage, but a larger girl might be better than that same smaller boy at that sport.
Mobile has a completely different IPC model that can't be supported by a 'desktop' style GUI. Specifically, you can't have applications sending each other input events willy-nilly.
What about "I use this machine a lot while I'm not sitting down" prevents applications from sending each other input events as they choose?
As I understand it, that single-line 20 Mb/s is only possible if you live basically right next to the CO or a DSL-enabled remote terminal (RT). By the time you get to my distance, ADSL2+ is only slightly faster than plain jane ADSL, circa 1998.
Well, this blog post by Sonic's CEO says:
for pair-bonded ADSL2+, so divide by 2 to get non-pair-bonded results. That gives 1.5Mbps/1Mbps at 2.1 miles, which is about what I got for download and better than what I got for upload back in the late '90's. How far are you from the CO or RT?
to be honest, i never quite understood all that BSD/Mach stuff. what exactly is a kernel vs a linux or operating system?
In most operating systems, there's a component that runs in a more privileged processor mode; that code is "the kernel" plus, if the kernel supports them, any loadable kernel modules that have been loaded.
"Linux" is sometimes used to refer to the Linux kernel, which is used as the kernel in various "Linux distributions", and it's sometimes used to refer to a distribution as a whole.
An operating system generally includes components other than the kernel; some people consider the kernel (and perhaps the loadable kernel modules) to be the operating system, others don't.
how can something be both bsd and mach, but not unix?
"Unix" is used for a whole bunch of different purposes. Sometimes it refers to the operating systems that AT&T made available in the 1970's, 1980's, and early 1990's, sometimes it refers also to operating systems that were based on AT&T's code (BSD, SunOS/Solaris, HP-UX, AIX, IRIX, etc.) even if the developers replaced a lot of the AT&T code with their own code, and sometimes it refers to those operating systems, regardless of how much AT&T code is in them, that have passed the Single UNIX Specification test suite and thus can have the trademarked name "Unix" associated with them.
OS X is in the second of those two categories (with only a small amount of AT&T code left, just as do the current BSDs) and, as of OS X Leopard, is also in the third of those categories, so it's based on BSD and Mach, and is Unix in one of those senses. Prior to Leopard, it was only "Unix" in the second sense, so somebody could use that to say it wasn't "Unix", even though it was "Unix-like" in the strong sense (see below).
all I know is there's a command prompt and it's not dos, so... case in point.
Lots of OSes have non-DOS-style command prompts, and not all of them are Unix or even "Unix-like", either in the weak sense of "sort of looks like Unix, but is sufficiently different that nobody'd mistake it for Unix" or the stronger sense of "compatible with Unix, even if it's not based on AT&T code and hasn't been tested with the Single UNIX Specification test suite (most if not all Linux distributions are "Unix-like" in that strong sense).
(And not all OSes with a DOS-style command prompt are DOS - OSes in the Windows NT family have a kernel and userland that's not at all DOS-derived, but the cmd.exe application provides a command prompt that's DOS-like.)
so your saying I'm write...
I'm saying that you're right when you say "OS X has a BSD+Mach kernel" and you're wrong when you say "They're the same thing!" if by "they" you mean OS X and FreeBSD (i.e., people trying to use OS X as evidence of large market share for FreeBSD are wrong; it's evidence for large market share for BSD UNIX in general, but not any of {Free,Net,Open,DragonFly}BSD in particular).
If you didn't mean OS X and FreeBSD by "they", what did you mean?
ok, so you're saying I'm wrong? OSX does not have a BSD Mach kernel?
OS X's kernel is a BSD+Mach+various Apple stuff hybrid, many of its loadable kernel modules are BSD-derived, and the Unix part of its userland is a BSD+GNU+various Apple stuff+various other stuff hybrid; that doesn't mean that OS X is the same thing as FreeBSD, even if most of the BSD stuff is FreeBSD-derived.
Sorry to break it to you, but there's a Mach kernel working inside your system, not a FreeBSD kernel as many idiots like to believe.
More precisely, there's a kernel composed of Mach-derived code (providing the low-level process and thread management, Mach messaging, VM system, and some low-level platform support), BSD-derived code (providing the high-level process management atop the Mach low-level code, VFS layer and some file systems that plug into it, and networking layer and networking stacks), and Apple-developed code in various places including I/O Kit. The Unix system call interface is provided by the BSD-derived code.
is fs a script because you aren't able to operate 'find',
fs is a script that runs find with a long list of file extensions because I'd rather not type the long list of file extensions in a find command every time I want to find source files. I can operate find, I just prefer to write a shell script to do it for me rather than doing it manually over and over again.
or is find simply not available on your oh-so-unixish os x?
As per the above, fs wouldn't work if find weren't available on OS X.
So it looks like mostly FreeBSD and a little of the old Mach
Well, if you call the osfmk directory of the XNU source a little, I guess it's "a little of the old Mach", although a fair bit of that code comes from NeXT and Apple as well.
I think NetBSD was used as a means for porting between architectures more than a literal inheritance.
Well, let's look at the libc source (the libc part of libSystem):
("fs" is a script that finds source files and prints their names to the standard output). The files it found with "NetBSD" in them were ./gen/FreeBSD/fmtcheck.c, ./gen/FreeBSD/lockf.c, ./gen/FreeBSD/stringlist.c, ./gen/NetBSD/utmpx.c, ./include/arpa/tftp.h, ./include/FreeBSD/nl_types.h, ./include/getopt.h, ./include/limits.h, ./include/NetBSD/utmpx.h, ./include/paths.h, ./include/search.h, ./include/stddef.h, ./include/stringlist.h, ./include/util.h, ./include/wchar.h, ./include/wctype.h, ./stdlib/FreeBSD/getopt.c, ./stdlib/FreeBSD/getopt_long.c, ./stdlib/FreeBSD/hcreate.c, ./stdlib/FreeBSD/tdelete.c, ./stdlib/FreeBSD/tfind.c, ./stdlib/FreeBSD/tsearch.c, ./stdlib/FreeBSD/twalk.c, ./stdlib/NetBSD/strfmon.c, ./string/FreeBSD/strndup.c, ./string/FreeBSD/wcscat.c, ./string/FreeBSD/wcscmp.c, ./string/FreeBSD/wcscpy.c, ./string/FreeBSD/wcscspn.c, ./string/FreeBSD/wcslcat.c, ./string/FreeBSD/wcslcpy.c, ./string/FreeBSD/wcslen.c, ./string/FreeBSD/wcsncat.c, ./string/FreeBSD/wcsncmp.c, ./string/FreeBSD/wcspbrk.c, ./string/FreeBSD/wcsspn.c, ./string/FreeBSD/wmemchr.c, ./string/FreeBSD/wmemcmp.c, ./string/FreeBSD/wmemcpy.c, ./string/FreeBSD/wmemmove.c, ./string/FreeBSD/wmemset.c, and ./util/fparseln.c.
The "NetBSD" and "FreeBSD" directory names are somewhat historical - for example, the 10.8.4 version of getopt_long() comes from NetBSD.
of course there are probably newer bits of FreeBSD used that are only known internally to Apple.
And other bits only known to people who download the open source bits and look at them. :-)
Then the timeline proceeds with Mac OS X as what appears to be where all of the development is taking place (including inheriting from FreeBSD), with Darwin and OS X Server only ever taking from OS X like mirrors. Then suddenly in 2006 this model changes and the OS X 10.5 beta inherits from Darwin 9.0 beta, when OS X 10.5 and Darwin 9 mature the model goes Darwin -> Mac OS X -> Mac OS X Server...
That's the timeline, not reality. Darwin was always produced by taking parts of OS X and making them available in source form; the model didn't change with Leopard.
Then in 2007 during the OS X 10.7 beta the model changes again when the server branch is eradicated all together and gets integrated into OS X and OS X gets integrated into Darwin so the model goes OS X -> Darwin again but without the server
The relevant bits of the FreeBSD userland are periodically (every major release) imported into OS X. The two systems are fairly different, so kernel changes in FreeBSD probably won't show up, but tweaks to command line tools and other stuff probably will.
The best way to think about it is that Darwin is "the kinda sorta fifth BSD", separate from {Free,Net,Open,DragonFly}BSD, but willing to pick stuff up from the *BSDs, just as the *BSDs are willing to pick up stuff from other *BSDs to various degrees.
The relevant bits of the FreeBSD userland are periodically (every major release) imported into OS X. The two systems are fairly different, so kernel changes in FreeBSD probably won't show up, but tweaks to command line tools and other stuff probably will.
Darwin is not a BSD kernel
Yeah, it's a kernel that's a combination of Mach and BSD.
so the kernel changes will never show up
Not necessarily.
heh, well the userland part of FreeBSD has more desktop installs than Linux distros.
Or, at least, part of the userland part of FreeBSD, combined with part of the userland part of NetBSD, combined with a bunch of vendor-written code, has more desktop installs that Linux distros (most of those "installs" being what was shipped with the machine; BTW, the auto-correct feature of the latest non-beta version of that vendor's OS tries to convert "distros" into "distress").
In theory, yes, I could bond two channels together.
Are you talking about two-line Fusion here? I.e., are you talking about trying to get more than the 20Mb/s maximum for single-line Fusion? (I certainly don't remember getting 20Mb/s from my ADSL back in 1998/1999....)