In a previous version of the message, I started going through a list of multitasking systems that worked in ways I find very different than either Unix or the Amiga. Things like DESQview (multitasking multi-threaded extensions to MS-DOS with interapplication communication.) VxWorks ( a RTOS for embedded devices) etc. I took out the list because I thought that it didn't add significantly to the point. I'm now a bit sorry that I didn't. Those feature don't define Unix. Instead of "multitasking" being a Unix-like behavior, I'd describe Unix as having a mode of multitasking where new processes are described in terms of the processes that spawn them and inherit their parents characteristics. Instead of saying that interapplication communication is a Unix-like behavior, I'd describe Unix has having a unified of files, devices, pipes, and network communication. Most of these behaviors the Amiga got from its history from Tripos, and none of these were created with an attempt to mimic, nor any knowledge of the existence of Unix.
As another point of proof. Notice that Tim King's resume talks about his work on the Amiga OS, but doesn't describe it as Unix-like. His later work on Helios he describes as Unix-like. http://www.tim-king.com/cv.html If he doesn't describe the Amiga OS as being Unix-like, I see no reason why anyone else should
The Mac OS X installer does allow you to decide whether or not to optionally install the "BSD Subsystem", but that is not talking about whether to install Unix or not. It is always a BSD kernel running on a Mach microkernel. Processes and files and other kernel resources, even when they are created by programs using the Carbon API, still correspond to Unix PIDs and file descriptors and whatever and behave in that fashion. Even if you don't install the BSD subsystem, you still have a BSD kernel, the init process is still is spawned first and brings up the rest of the system. There is still a/bin/sh for running scripts, etc. The "BSD Subsystem" the installers mentions refers to user-space Unix components that aren't required for booting. The choice to install (or not) the BSD subsystem only controls whether more esoteric unix programs like, python, indent, info, banner, etc. are installed.
I don't know what you mean by "full range of operations" of the Unix file system, unless you are referring to the way that the HFS filesystem drivers handle filenames in a case insensitive manner. (with makefile and Makefile both matching the same file.) All the other behavior (open/read/write/stat/link/unlink/fcntl/etc) all follow Unix semantics.
No, dos.library wasn't the only part that wasn't in C. There was the huge amount of 68K code too.
And I'm not sure if you noticed that the thread, or even this topic is about, but it isn't the "overall style and feel of an OS", but what actually defines Unix as an OS. The initial question is "Can GNU Ever Be Unix?" and the thread started with a discussion of the Open Group's certification. Yes, you mentioned an "artistic license", but then compared it to a system with a complete BSD 4.4 kernel. You have to get to an extremely abstracted view before you can equate AmigaOS and Unix, and by then you have can probably include 75% of the operating systems ever developed to be in the same category.
Just because dos.library was written in BCPL, and BCPL is an ancestor of C, that doesn't make AmigaOS an ancestor of Unix. If you wanted to call AmigaOS an ancestor of TripOS, you would have less of an argument from me.
The difference between what the HURD has designed and the various efforts to implement them in Unix like operating systems is in user space. The HURD allows (or will allow, once its done) per-process overrides of any system call. LUFS simply allows a user space program to tell the kernel how to represent a device. With the HURD, there is no reason why another user will even see the results of your translators.
What I don't understand, is how the HURD is so late when it has these features. Creating or modifying a new system call should just involve installing a translator, testing it, and at worst logging out. No rebooting to test a new kernel feature.
I did a bit of research on this a few weeks ago. Most of the BSD kernel in OS X is still predominantly based on the kernel they bought from NeXT. There is a similarity because of the common ancestry in BSD 4.3 and 4.4, but since then they have both diverged significantly. There are a few localized chunks of the kernel that have FreeBSD copyrights ( the crypto directory in particular)
The system library and user commands portions of Unix (manual sections 1 and 3) contain a lot more similarity between Darwin (the OS X version of Unix) and FreeBSD.
I'm sorry. I wasn't very clear. I know what Amigas and the AmigaOS were. It was the idea of calling it "Unix-like" that caused the confusion.
Take a look at an API listing of things like dos.library and exec.library, and take a look at/usr/share/man/man2 and try to find something resembling a kernel level similarity. Take a look at AmigaDOS and compare it to the Bourne shell and/usr/share/man/man1. A fair amount of/usr/share/man/man3 got standardized as ANSI C, so it starts to get similar around there.
The description of AmigaOS as "unix" or "unix-like" implies a lack of understanding of what the Amiga was, or what Unix is. For example, The Unix process model inherently revolves around a parent child relationship between processes and fork() to create new processes. Without a fork(), don't even begin to talk to me about something being "unix-like". The Amiga process creation is much more like pthread_create() of a routine retreived from a dynamically loaded library.
Re-reading the article, I noticed a small point I missed when I posted the previous message. AT&T didn't sell the trademark to the Open Group. They sold the whole thing, source, trademark, and compliance certification to Novell, who split up their purchase to SCO and the Open Group. It was Novell who as a corporation recognized the difference between Unix as a standard interface to Unix as a body of source code.
Before the Open Group had the trademark and developed the certification process, AT&T held the trademark and might allow AT&T source licensees to use it. In the later years, they had a certification process that became the initial Open Group certification. When AT&T owned it, anything marked as Unix had some amount of AT&T code as its base. BSD hadn't still contained AT&T code, the Net2 release was in 1994, so all commercial BSD based systems (older SunOS, NeXT, older SGI, etc.) were derivatives of a common code base . Xenix was a based on an early Bell Labs release. (I don't know where the reference to AmigaOS came from.)
The AT&T conformance was mostly to prove that when vendors made local modifications, they didn't mess anything up.
"UNIX" means different things to different people. One definition would be something that contains ATT UNIX code. Another would be something that has a bunch of certifications. Linux has neither.
It didn't occur to me at the time that AT&T sold the Unix copyrights and the Unix Trademark, but that act was solidly admitting defeat to the Open Software Foundation (now the Open Group) in the Unix wars. The OSF created their OSF/1 operating system to try to promote Unix as an API standard and not the name of a family of systems derived from a single source. The fact that AT&T sold them the name can be viewed as an implicit admission that it was the API and not the source code that matters.
The Unix trademark is now owned by an organization whose initial charter was to make the AT&T based SYSVr4 irrelevant. Many groups have surpassed them. (There are probably many more Linux systems around than Digital Unix, the most recent OS derived from OSF/1) but their goal was achieved.
But it was, to the limit of patentability that was available at the time. This was before Diamond v. Diehrand the US patent office deemed software as "pure mathamatics" and unpatentable. The patent that was developed from Unix, the setuid patent was written in terms of the gates in memory that got flipped and read to check access control.
If Bell Labs hadn't assigned the patent to the public domain (supposedly over the cost of collecting license fees) Then development on Unix clones would have started much later.
That quote doesn't imply that the albums were all on the Billboard chart. It says that the agreed on value of the CD was based on some formula that has something to do with the Billboard's charts. The albums that never made it could be distributed. Its just the record company would have to give away many more of the failures in order to make up the same dollar value.
To prevent the companies from dumping unwanted inventory, lawyers for the states came up with a formula based on how much time artists spent on the Billboard charts, Wisconsin Assistant Attorney General Eric Wilson said. But he conceded, "it may be hard to believe looking at the selections."
but the results don't seem to stack up. Does anyone know what the formula they came up with? From the small description there, I can imagine a few possible flaws. Either there was some minimum price, which encouraged the shipment of many, many slow moving items, or it was based on the Billboard charts results for the artist, not the album. (Will Smith and Whitney Houston have both made some very popular works, but the albums being reported to be distributed aren't among their most notable ones.)
Re:Why IT is annoying
on
Are You Annoying?
·
· Score: 4, Informative
Although I really, honestly, believe that you could be trusted with root on your linux box at work. (and if you just send your IT guys my way. I'll be willing to vouch for you.) there are some scenarios where giving even experienced users root is a bad idea for the company as a whole.
There are many tools for computer maintenance that are rarely needed for managing one or two machines, or maybe even cumbersome and time consuming. When the number of machines to manage rises, the extra burden amortizes out over the number of machines and they get to be time savers. Having a machine that isn't managed by the automated tools starts to become a much larger chore.
People who manage their own machine are much more likely to take shortcuts. ("How does that virtual interface stuff work in redhat's/etc/sysconfig/? Oh, they changed it in this version! Screwm. I'll just add it to/etc/rc.d/init.d/network.") Having machines maintained differently can be a time waster.
There is probably a wide gap between the people who know how to administer a machine, and the number of people who think they know how to. Very often the computer maintenance staff tell the difference, but telling one Unix guru that he can't have root is easier than telling the two dozen bozos that they can't. Guessing wrong can be disastrous too, because if anything happens to that machine, they will be responsible for it.
Unfortunately, where I am is the worst of all worlds. The machines are maintained with automation tools, but they are set up poorly, so the default install is already screwed up. PC Tech support ignores Unix machines, so they are on their own and maintained by the individual users.
I'm sorry. I must not have been clear. Both Darwin 7.4 and OpenDarwin 7.2.1 seem to have (at least some of ) the kernel level functionality needed for BSM, but from neither package can I find any userspace utilities to activate it or read the accounting logs. I'm not so much interested in when it appeared or which versions support it, but rather if it is, or will be usable.
I'm not sure if the problem is that I'm looking for programs with names like bsmconv and auditd and the audit configuration is handled differently in Darwin or that those pieces don't exist yet.
The other day, I was looking around the Darwin kernel code and I saw references to BSM support in kern_audit.c and the like. But I couldn't find any userspace utilities designed to enable or extract information for the kernel's audit log. Am I missing something? or is this just a stub that is being filled in as they go along?
I've considered getting a camera phone, but never for the reasons that they seem to show in the commercials. Where I can imagine it coming in useful is when my wife sends me to the store for some insufficiently described item. Right now, I can call and say "did you mean the one in the purple box or the turquoise one.", to which I get a non-responsive answer like "its not really a box so much as a plastic wrapping.." and the frustration on both sides builds from there with each subsequent question and response.
With a camera phone, I can send two pictures and say "this one or that one"
The first thing that I thought when I read that was that it just might be marketing spin on an engineering issue. For example, one scenario would be that many product development groups were being held up by one engineering group being late with a component to all of them. So an initially planned phased release of phones started piling up together. Too few new models, market share goes down a bit, and then they can respond with "but next year we are going to pick up the pace" and start releasing the product lines that were already in the development queue.
Unless I'm totally offbase (I'm going from memory here), the xnu module is just the mach kernel. The BSD portion is located in another module.
You do have a point in so far as Darwin's kernel modules allow lots of things to be moved entirely out of the kernel package. (more so than Linux's kernel modules, which are really more like compiled in stubs that can dynamically load in their implementation) There is an entire BSD kernel with the xnu package that sits on top of (or more accurately in Darwin's case "along side") the Mach microkernel.
Since are now the second person to quote me that passage out of the Darwin Kernel Programming guide, lets look at them piece by piece.
Notice how the vfs files are located in a different directory. Notice that the copyrights are different (in the Apple code, most of the BSD copyright notices are from the '80s until about 1993.) and that the license has what the FSF called the "obnoxious advertising clause") Notice that some of the function; their names and arguments are different and some added and removed functions on each side. At points, there are different algorithms. Also, the Apple one is much more likely to make use of gcc extensions like __inline__.
Notice the ACL support in the FreeBSD code that isn't in the Darwin code and the journalling code that isn't in FreeBSD.
The Darwin version of the berkeley packet filter code has an RCS string mentioning FreeBSD, but a 2001 timestamp. The Darwin version also has a "#ifdef __APPLE__" that isn't in the FreeBSD version.
The bridging code has similar connections and looks like it was grabbed from FreeBSD some years ago and diverged. The rest of the code has chunks that are the same, but divergent differences, early BSD copyright dates, and looks like the diverged much earlier.
UNIX security model
the file kern_prot.c is where a lot of this takes place.
Notice that the Darwin code still uses pre-ANSI C calling convensions, while the FreeBSD version was converted to ANSI style some years ago. Also note that even the earliest sources on the FreeBSD CVS repository and the Darwin sources have differences. The FreeBSD version has references to things like "defined(COMPAT_SUNOS)" that aren't in Darwin.
So unless you think the Apple website is wrong and they don't really use FreeBSD in their kernel, despite their own developer's website saying that they do, I think you might be mistaken.
Yes, I think that quote that you grabbed somewhat misleading. Or at least a large simplification. Lets look at how many lines in the kernel have either copyright or RCS variables that reference FreeBSD
I discounted the references to appletalk, which aren't apple code and skew the results. If you look closely at the rest of those 53 files, they are hardware related files that aren't common between the two. (most of the PCI and low level disk drivers are handled by Mach, not BSD on the Darwin side)
Based on this, I'll repeat my assertion. The Darwin kernel is an evolutionary outgrowth of the work that was done at NeXT. NeXT's BSD is based off of the BSD source before it became free software and before the FreeBSD project began. There is very little, if any FreeBSD code in Apple's kernel. The rest of the BSD subsystem, the parts above the kernel, (mostly the stuff in/usr/lib and/{,usr}/{,s}bin) are a different story and have a lot of connection to FreeBSD.
By their contributions to the BSDs? Apple uses FreeBSD a lot but it's only a trickle back. Sure, they give some gnawed bones to the FreeBSD kernel guys, but what about the rest of BSD?
Seeing this, it implies to me that you are just ranting with no idea what you talking about. The part of FreeBSD that Apple is not using is the kernel. They are using the BSD w/ Mach thing that they inherited from NeXT. It is the user space utilities that are mostly from FreeBSD. Instead of the ones that shipped with NextSTEP (the ones they licensed from Berkeley before BSD became free software) which were getting a bit long in the tooth, they grabbed most of/bin and/usr/bin/ from FreeBSD.
The comment about Open Source shipped by Sun seems misguided as well. First of all, Sun shipping open source software packages is a very recent phenomena.
Solaris Freeware. shows the packages that ship with Solaris 9. A small portion of those titles were distributed with Solaris 8 (I'm thinking less than a half dozen. That was the release they added ssh and Apache.) In Solaris 7 and earlier, the only thing close to free software were the hacked up binary only versions of Sendmail and and Bind.
I don't quite understand why you keep harping on OpenOffice too. They bought a failing company producing an office productivity suite because they wanted some sort of word processing and spreadsheet option to sell with the workstation systems. It was sort of like SGI buying the MIPS CPU maker. It wasn't good for them to do, but it would be disastrous for them no to do.
And Sun doesn't ship a lot of boxes. They ship a lot of boxes for a server manufacturer, which isn't quite the same thing.
No. Zeroconf came from Apple, developed by an Apple employee (Stuart Cheshire, whose job title is "Wizard without Portfolio") and was submitted to the IETF for standardization (not that much of the much of that work has succeeded yet. There are a bunch of drafts, but no official RFCs yet.) That is not leeching by any sense of the word. (or leaching either. Slightly different meanings, but I guess both would work.)
As others have said, using, improving, and returning your improvements back to the open source projects is hard to be considered leeching either. And this is what they are doing for gcc, FreeBSD, KHTML, and other projects.
Re:He Might Be Passe, But What He Is Doing Isn't
on
Wired on McBride
·
· Score: 2, Interesting
if it wasn't going to be McBride, it would be someone else down the line that would exploit this little problem
One could argue that this problem has been exploited already in a smaller scale, and people involved in Linux should worry about it getting worse and worse.
In many ways, what Darl is doing feels a lot like what William Della Croce, Jr. did in 1996. That took about a year to get resolved.
First a false trademark infringement claim. Now a false copyright infringement claim. I really fear the false patent infringement claim that I expect is coming up in the future.
Jobs did even worse than that. The original Macintosh, the Mac 512 and the Mac Plus (all the beige cuisenart looking models) had no control key at all.
Professor Andrew Tanenbaum is a professor who has written some great books. I'm very happy to have read read them. One of his books was Operatin g System Desgin and Implementation in which he describes operating systems with a toy, minimal, Unix-like operating system for the 8088 called Minix. It wasn't a really useful OS, but it was small enough to take a look at the code to any particular subsystem and learn how it worked. As an example of its mimilalism, it did have some hardware memory protection between processes, but did so with segment registers. That limited the size of each program to 64k.
Minix wasn't free or open source software. (ideas that were pretty much in their infancy) Tanenbaum sold it through his book publisher. Not for much, probably just enough to make it worth Prentice-Hall's time. Without the Internet as a cost effective distribution medium, someone had to take the orders and mail the disks. People loved tinkering with Minux, though. They ported it to other platforms, (Atari ST, Amiga, Sparc, 80306, etc.) They added to it and started distributing patches. Linus was using Minix-386 before he managed to get Linux to be self-hosting. In some reports, it was Linus' annoyance at having to pay for Minux that inspired him to make Linux free software.
Ken Brown, on the other hand, is someone whose name isn't very recognizable in technical circles. I'm tempted to say that he is a nobody, but maybe I just don't hang around the right circles. (Or on the other hand, maybe if I've never heard of him that means that I hang around the right circles.) I first read about the Alexis de Tocqueville Institution a couple of years ago when they published a paper questioning the security of free and open source software, and sold the paper in a through a system that allowed people to download the paper without purchasing it. Most of the links on their site are either links to articles from news sites about the institutes press releases, or links to papers that they promise will be ready soon.
Slashdot Mirror
In a previous version of the message, I started going through a list of multitasking systems that worked in ways I find very different than either Unix or the Amiga. Things like DESQview (multitasking multi-threaded extensions to MS-DOS with interapplication communication.) VxWorks ( a RTOS for embedded devices) etc. I took out the list because I thought that it didn't add significantly to the point. I'm now a bit sorry that I didn't. Those feature don't define Unix. Instead of "multitasking" being a Unix-like behavior, I'd describe Unix as having a mode of multitasking where new processes are described in terms of the processes that spawn them and inherit their parents characteristics. Instead of saying that interapplication communication is a Unix-like behavior, I'd describe Unix has having a unified of files, devices, pipes, and network communication. Most of these behaviors the Amiga got from its history from Tripos, and none of these were created with an attempt to mimic, nor any knowledge of the existence of Unix.
As another point of proof. Notice that Tim King's resume talks about his work on the Amiga OS, but doesn't describe it as Unix-like. His later work on Helios he describes as Unix-like. http://www.tim-king.com/cv.html If he doesn't describe the Amiga OS as being Unix-like, I see no reason why anyone else should
The Mac OS X installer does allow you to decide whether or not to optionally install the "BSD Subsystem", but that is not talking about whether to install Unix or not. It is always a BSD kernel running on a Mach microkernel. Processes and files and other kernel resources, even when they are created by programs using the Carbon API, still correspond to Unix PIDs and file descriptors and whatever and behave in that fashion. Even if you don't install the BSD subsystem, you still have a BSD kernel, the init process is still is spawned first and brings up the rest of the system. There is still a /bin/sh for running scripts, etc. The "BSD Subsystem" the installers mentions refers to user-space Unix components that aren't required for booting. The choice to install (or not) the BSD subsystem only controls whether more esoteric unix programs like, python, indent, info, banner, etc. are installed.
I don't know what you mean by "full range of operations" of the Unix file system, unless you are referring to the way that the HFS filesystem drivers handle filenames in a case insensitive manner. (with makefile and Makefile both matching the same file.) All the other behavior (open/read/write/stat/link/unlink/fcntl/etc) all follow Unix semantics.
No, dos.library wasn't the only part that wasn't in C. There was the huge amount of 68K code too.
And I'm not sure if you noticed that the thread, or even this topic is about, but it isn't the "overall style and feel of an OS", but what actually defines Unix as an OS. The initial question is "Can GNU Ever Be Unix?" and the thread started with a discussion of the Open Group's certification. Yes, you mentioned an "artistic license", but then compared it to a system with a complete BSD 4.4 kernel. You have to get to an extremely abstracted view before you can equate AmigaOS and Unix, and by then you have can probably include 75% of the operating systems ever developed to be in the same category.
Just because dos.library was written in BCPL, and BCPL is an ancestor of C, that doesn't make AmigaOS an ancestor of Unix. If you wanted to call AmigaOS an ancestor of TripOS, you would have less of an argument from me.
The difference between what the HURD has designed and the various efforts to implement them in Unix like operating systems is in user space. The HURD allows (or will allow, once its done) per-process overrides of any system call. LUFS simply allows a user space program to tell the kernel how to represent a device. With the HURD, there is no reason why another user will even see the results of your translators.
What I don't understand, is how the HURD is so late when it has these features. Creating or modifying a new system call should just involve installing a translator, testing it, and at worst logging out. No rebooting to test a new kernel feature.
I did a bit of research on this a few weeks ago. Most of the BSD kernel in OS X is still predominantly based on the kernel they bought from NeXT. There is a similarity because of the common ancestry in BSD 4.3 and 4.4, but since then they have both diverged significantly. There are a few localized chunks of the kernel that have FreeBSD copyrights ( the crypto directory in particular)
The system library and user commands portions of Unix (manual sections 1 and 3) contain a lot more similarity between Darwin (the OS X version of Unix) and FreeBSD.
I'm sorry. I wasn't very clear. I know what Amigas and the AmigaOS were. It was the idea of calling it "Unix-like" that caused the confusion.
Take a look at an API listing of things like dos.library and exec.library, and take a look at /usr/share/man/man2 and try to find something resembling a kernel level similarity. Take a look at AmigaDOS and compare it to the Bourne shell and /usr/share/man/man1. A fair amount of /usr/share/man/man3 got standardized as ANSI C, so it starts to get similar around there.
The description of AmigaOS as "unix" or "unix-like" implies a lack of understanding of what the Amiga was, or what Unix is. For example, The Unix process model inherently revolves around a parent child relationship between processes and fork() to create new processes. Without a fork(), don't even begin to talk to me about something being "unix-like". The Amiga process creation is much more like pthread_create() of a routine retreived from a dynamically loaded library.
Re-reading the article, I noticed a small point I missed when I posted the previous message. AT&T didn't sell the trademark to the Open Group. They sold the whole thing, source, trademark, and compliance certification to Novell, who split up their purchase to SCO and the Open Group. It was Novell who as a corporation recognized the difference between Unix as a standard interface to Unix as a body of source code.
Before the Open Group had the trademark and developed the certification process, AT&T held the trademark and might allow AT&T source licensees to use it. In the later years, they had a certification process that became the initial Open Group certification. When AT&T owned it, anything marked as Unix had some amount of AT&T code as its base. BSD hadn't still contained AT&T code, the Net2 release was in 1994, so all commercial BSD based systems (older SunOS, NeXT, older SGI, etc.) were derivatives of a common code base . Xenix was a based on an early Bell Labs release. (I don't know where the reference to AmigaOS came from.)
The AT&T conformance was mostly to prove that when vendors made local modifications, they didn't mess anything up.
It didn't occur to me at the time that AT&T sold the Unix copyrights and the Unix Trademark, but that act was solidly admitting defeat to the Open Software Foundation (now the Open Group) in the Unix wars. The OSF created their OSF/1 operating system to try to promote Unix as an API standard and not the name of a family of systems derived from a single source. The fact that AT&T sold them the name can be viewed as an implicit admission that it was the API and not the source code that matters.
The Unix trademark is now owned by an organization whose initial charter was to make the AT&T based SYSVr4 irrelevant. Many groups have surpassed them. (There are probably many more Linux systems around than Digital Unix, the most recent OS derived from OSF/1) but their goal was achieved.
But it was, to the limit of patentability that was available at the time. This was before Diamond v. Diehrand the US patent office deemed software as "pure mathamatics" and unpatentable. The patent that was developed from Unix, the setuid patent was written in terms of the gates in memory that got flipped and read to check access control.
If Bell Labs hadn't assigned the patent to the public domain (supposedly over the cost of collecting license fees) Then development on Unix clones would have started much later.
That quote doesn't imply that the albums were all on the Billboard chart. It says that the agreed on value of the CD was based on some formula that has something to do with the Billboard's charts. The albums that never made it could be distributed. Its just the record company would have to give away many more of the failures in order to make up the same dollar value.
Although I really, honestly, believe that you could be trusted with root on your linux box at work. (and if you just send your IT guys my way. I'll be willing to vouch for you.) there are some scenarios where giving even experienced users root is a bad idea for the company as a whole.
Unfortunately, where I am is the worst of all worlds. The machines are maintained with automation tools, but they are set up poorly, so the default install is already screwed up. PC Tech support ignores Unix machines, so they are on their own and maintained by the individual users.
Never mind, for Darwin 7.4 I found bsm-2.10
I'm sorry. I must not have been clear. Both Darwin 7.4 and OpenDarwin 7.2.1 seem to have (at least some of ) the kernel level functionality needed for BSM, but from neither package can I find any userspace utilities to activate it or read the accounting logs. I'm not so much interested in when it appeared or which versions support it, but rather if it is, or will be usable.
I'm not sure if the problem is that I'm looking for programs with names like bsmconv and auditd and the audit configuration is handled differently in Darwin or that those pieces don't exist yet.
The other day, I was looking around the Darwin kernel code and I saw references to BSM support in kern_audit.c and the like. But I couldn't find any userspace utilities designed to enable or extract information for the kernel's audit log. Am I missing something? or is this just a stub that is being filled in as they go along?
I've considered getting a camera phone, but never for the reasons that they seem to show in the commercials. Where I can imagine it coming in useful is when my wife sends me to the store for some insufficiently described item. Right now, I can call and say "did you mean the one in the purple box or the turquoise one.", to which I get a non-responsive answer like "its not really a box so much as a plastic wrapping.." and the frustration on both sides builds from there with each subsequent question and response.
With a camera phone, I can send two pictures and say "this one or that one"
The first thing that I thought when I read that was that it just might be marketing spin on an engineering issue. For example, one scenario would be that many product development groups were being held up by one engineering group being late with a component to all of them. So an initially planned phased release of phones started piling up together. Too few new models, market share goes down a bit, and then they can respond with "but next year we are going to pick up the pace" and start releasing the product lines that were already in the development queue.
Unless I'm totally offbase (I'm going from memory here), the xnu module is just the mach kernel. The BSD portion is located in another module.
You do have a point in so far as Darwin's kernel modules allow lots of things to be moved entirely out of the kernel package. (more so than Linux's kernel modules, which are really more like compiled in stubs that can dynamically load in their implementation) There is an entire BSD kernel with the xnu package that sits on top of (or more accurately in Darwin's case "along side") the Mach microkernel.
Since are now the second person to quote me that passage out of the Darwin Kernel Programming guide, lets look at them piece by piece.
Notice how the vfs files are located in a different directory. Notice that the copyrights are different (in the Apple code, most of the BSD copyright notices are from the '80s until about 1993.) and that the license has what the FSF called the "obnoxious advertising clause") Notice that some of the function; their names and arguments are different and some added and removed functions on each side. At points, there are different algorithms. Also, the Apple one is much more likely to make use of gcc extensions like __inline__. Notice the ACL support in the FreeBSD code that isn't in the Darwin code and the journalling code that isn't in FreeBSD.
networking (except for the hardware device level)
The Darwin version of the berkeley packet filter code has an RCS string mentioning FreeBSD, but a 2001 timestamp. The Darwin version also has a "#ifdef __APPLE__" that isn't in the FreeBSD version. The bridging code has similar connections and looks like it was grabbed from FreeBSD some years ago and diverged. The rest of the code has chunks that are the same, but divergent differences, early BSD copyright dates, and looks like the diverged much earlier.
UNIX security model
the file kern_prot.c is where a lot of this takes place.
Notice that the Darwin code still uses pre-ANSI C calling convensions, while the FreeBSD version was converted to ANSI style some years ago. Also note that even the earliest sources on the FreeBSD CVS repository and the Darwin sources have differences. The FreeBSD version has references to things like "defined(COMPAT_SUNOS)" that aren't in Darwin.
syscall support
So unless you think the Apple website is wrong and they don't really use FreeBSD in their kernel, despite their own developer's website saying that they do, I think you might be mistaken.
Yes, I think that quote that you grabbed somewhat misleading. Or at least a large simplification. Lets look at how many lines in the kernel have either copyright or RCS variables that reference FreeBSD
Now as a comparison, lets grab src/sys from FreeBSD for comparison
and just to round things out, lets look for how many references there is to Apple anywhere in the FreeBSD source.
I discounted the references to appletalk, which aren't apple code and skew the results. If you look closely at the rest of those 53 files, they are hardware related files that aren't common between the two. (most of the PCI and low level disk drivers are handled by Mach, not BSD on the Darwin side)
Based on this, I'll repeat my assertion. The Darwin kernel is an evolutionary outgrowth of the work that was done at NeXT. NeXT's BSD is based off of the BSD source before it became free software and before the FreeBSD project began. There is very little, if any FreeBSD code in Apple's kernel. The rest of the BSD subsystem, the parts above the kernel, (mostly the stuff in /usr/lib and /{,usr}/{,s}bin) are a different story and have a lot of connection to FreeBSD.
By their contributions to the BSDs? Apple uses FreeBSD a lot but it's only a trickle back. Sure, they give some gnawed bones to the FreeBSD kernel guys, but what about the rest of BSD?
Seeing this, it implies to me that you are just ranting with no idea what you talking about. The part of FreeBSD that Apple is not using is the kernel. They are using the BSD w/ Mach thing that they inherited from NeXT. It is the user space utilities that are mostly from FreeBSD. Instead of the ones that shipped with NextSTEP (the ones they licensed from Berkeley before BSD became free software) which were getting a bit long in the tooth, they grabbed most of /bin and /usr/bin/ from FreeBSD.
The comment about Open Source shipped by Sun seems misguided as well. First of all, Sun shipping open source software packages is a very recent phenomena. Solaris Freeware. shows the packages that ship with Solaris 9. A small portion of those titles were distributed with Solaris 8 (I'm thinking less than a half dozen. That was the release they added ssh and Apache.) In Solaris 7 and earlier, the only thing close to free software were the hacked up binary only versions of Sendmail and and Bind.
I don't quite understand why you keep harping on OpenOffice too. They bought a failing company producing an office productivity suite because they wanted some sort of word processing and spreadsheet option to sell with the workstation systems. It was sort of like SGI buying the MIPS CPU maker. It wasn't good for them to do, but it would be disastrous for them no to do.
And Sun doesn't ship a lot of boxes. They ship a lot of boxes for a server manufacturer, which isn't quite the same thing.
No. Zeroconf came from Apple, developed by an Apple employee (Stuart Cheshire, whose job title is "Wizard without Portfolio") and was submitted to the IETF for standardization (not that much of the much of that work has succeeded yet. There are a bunch of drafts, but no official RFCs yet.) That is not leeching by any sense of the word. (or leaching either. Slightly different meanings, but I guess both would work.)
As others have said, using, improving, and returning your improvements back to the open source projects is hard to be considered leeching either. And this is what they are doing for gcc, FreeBSD, KHTML, and other projects.
if it wasn't going to be McBride, it would be someone else down the line that would exploit this little problem
One could argue that this problem has been exploited already in a smaller scale, and people involved in Linux should worry about it getting worse and worse.
In many ways, what Darl is doing feels a lot like what William Della Croce, Jr. did in 1996. That took about a year to get resolved.
First a false trademark infringement claim. Now a false copyright infringement claim. I really fear the false patent infringement claim that I expect is coming up in the future.
Jobs did even worse than that. The original Macintosh, the Mac 512 and the Mac Plus (all the beige cuisenart looking models) had no control key at all.
Professor Andrew Tanenbaum is a professor who has written some great books. I'm very happy to have read read them. One of his books was Operatin g System Desgin and Implementation in which he describes operating systems with a toy, minimal, Unix-like operating system for the 8088 called Minix. It wasn't a really useful OS, but it was small enough to take a look at the code to any particular subsystem and learn how it worked. As an example of its mimilalism, it did have some hardware memory protection between processes, but did so with segment registers. That limited the size of each program to 64k.
Minix wasn't free or open source software. (ideas that were pretty much in their infancy) Tanenbaum sold it through his book publisher. Not for much, probably just enough to make it worth Prentice-Hall's time. Without the Internet as a cost effective distribution medium, someone had to take the orders and mail the disks. People loved tinkering with Minux, though. They ported it to other platforms, (Atari ST, Amiga, Sparc, 80306, etc.) They added to it and started distributing patches. Linus was using Minix-386 before he managed to get Linux to be self-hosting. In some reports, it was Linus' annoyance at having to pay for Minux that inspired him to make Linux free software.
Ken Brown, on the other hand, is someone whose name isn't very recognizable in technical circles. I'm tempted to say that he is a nobody, but maybe I just don't hang around the right circles. (Or on the other hand, maybe if I've never heard of him that means that I hang around the right circles.) I first read about the Alexis de Tocqueville Institution a couple of years ago when they published a paper questioning the security of free and open source software, and sold the paper in a through a system that allowed people to download the paper without purchasing it. Most of the links on their site are either links to articles from news sites about the institutes press releases, or links to papers that they promise will be ready soon.