Look, the kernel rarely works on its own. Leaving aside the embedded stuff, what has been successful, has been a combination of lots of userland applications and the Linux kernel. You are right in saying that most successful Open-Source project have strong central leadership. But GNU/Linux as a whole? Not a chance. So Gnome project goes one way, X(org) goes the other way. Apache goes one way, kernel goes the other way. Millions of such examples where 2 loosely related items in GNU/Linux have their independent leadership, do what they damn please.
Yup, and they never have Linux Plumbers Conferences to try to get parts of the platform that need to work together to work together well. Perhaps not "central leadership", but not "chaos", either.
As for Apache, it's an app that runs atop a number of platforms, including Linux-kernel-plus-some-particular-bits-of-userland; it manages to go its own way, and work, even though the Linux-kernel-plus-some-particular-bits-of-userland, Mac OS X, Solaris, FreeBSD, NetBSD, OpenBSD, DragonFly BSD, HP-UX, AIX, Windows, etc. platforms go their own way; Linux isn't particularly special in that case.
This is exactly what happened when moving from 2.0 to 3.0. Developers had to update their apps or they may have stopped working and got pulled. It doesn't matter if you used improper APIs.
O RLY? I didn't see updates for all the third-party apps on my iPhone prior to 3.0 or when 3.0 came out. Apple might require you to verify that your app still works with an OS update, and fix it if it doesn't, but if it still works on the new OS, there should be no need to make an update and, as far as I know, there is no need to make an update.
Also, MeeGo should provides an easy porting target for Android apps (Java duh?)
I have the impression that Android isn't exactly a standard Java platform, and it probably also has a pile of its own classes that you don't magically get to use on every Java platform.
and eventually iPhone Apps (GnuSTEP).
GNUStep doesn't exactly include every single class that's in iPhone OS (or Mac OS X, for that matter), either.
Though this is just a first step toward an iPhone-like developer model,
By which I presume you mean "a model where they only charge you $99/year, don't have multiple tiers of developer, and perhaps don't offer hardware discounts". There are a number of ways in which the Mac OS X and iPhone OS developer programs differ; the fact that they're getting rid of one of them (higher price) does not ipso facto mean that the long-term plan is to make the Mac OS X developer program exactly like the iPhone OS program, down to the app store and restrictions.
What scares me about this though is that Apple are gradually being sucked into their own hype; that only end-to-end control of the experience by Apple is the way to ensure quality. This in spite of the obvious failure in quality control in their store and the many inconsistencies in applying their policy.
Which is inexcusable, as Apple have had over 10 years worth of iPhone experience and should know how to do the app checking by now. Oh, wait....
(Yes, it should've been better from the start. I suspect it'll get better over time.
And, yes, I think there should be an option to allow installation of non-App Store apps, with a big pop-up warning that "IF YOU FLIP THIS SWITCH, AND YOUR PHONE TURNS INTO A BRICK OR GETS BROKEN INTO OR SOME APP STOPS WORKING AFTER A SOFTWARE UPDATE OR..., AND YOU BRING IT TO THE GENIUS BAR TO GET IT FIXED, WE WILL TAKE GREAT DELIGHT IN YOUR MISERY AND LAUGH YOU OUT OF THE STORE", so that you're not stuck with approved apps and they're not stuck with supporting apps that haven't gone through the approval process or devices running those apps. I like contracts that bind both parties, like API contracts - "you use only the documented routines, and use them only in the documented fashion, and we won't change them so that they stop working that way"; as somebody who's designed and implemented various program interfaces, I like them a lot better than, say, "I get to do what I want with your libraries and you have to support me".)
If they use API calls that Apple didn't want them to, why were they approved?
Perhaps because the review process isn't as good as it should be?
There's no app for that.
There's no supported stable API for that (in iPhone OS or in Mac OS X). (Yes, I think it would be nice if there were. I'm not about to say "Apple should ship what they have now", however.)
no, I have no idea why iPhone OS doesn't include iChat
Ah, that was my assumption that it did. How very strange - perhaps AT&T wanted the SMS revenue.
If so, why are AIM, Yahoo! Messenger!, etc. apps allowed on the App Store? Or is the idea that somebody has to go through some effort to find out about and get those apps, so a lot of people just default to using SMS?
So it looks like this may be about the PlaceEngine framework, not wifi per se.
The OS X version of PlaceEngine is an app, not a framework - and it, err, umm, uses a private framework:
$ otool -L PlaceEngine PlaceEngine: /usr/lib/libxml2.2.dylib (compatibility version 9.0.0, current version 9.16.0) /usr/lib/libcrypto.0.9.7.dylib (compatibility version 0.9.7, current version 0.9.7) /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 11.0.0) /System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Apple80211 (compatibility version 1.0.0, current version 2.0.0)
...
The iPhone OS version might do the same. Yes, it's unfortunate that there's no public API in OS X - and, I suspect, iPhone OS - to get information about nearby access points, but I wouldn't assume that the private interfaces are, in their current state, something that Apple would like to be forced to preserve in a compatible fashion so as not to break third-party apps.
Apple is understandably very protective about the lowest-level radio controls on a cell phone.
Apple's cell phone has more than one radio in it. The radio that implements IEEE 802.11 is separate from the radio that implements the GSM/UMTS air interfaces (and separate from the radios that implement Bluetooth and GPS).
One thing they gain is not having to care what third-party apps they break if they decide to change the way, say, the private framework in question works, because at time T they decided "it should work this way" and at time T+delta T they realized that with 802.11xyzzy, or with a change to the way they handle captive networks, or..., it really needs to work some other way.
Of course, they'd gain less irritation if they could catch this beforehand, but maybe the offending apps loaded up the private framework at run time rather than being explicitly linked with the framework; a simple otool -L would identify apps explicitly linked with the framework, but, unless you forbid using any interfaces that let you load libraries/frameworks at run time, it's probably trickier to catch those (although I guess you could sandbox apps so that they're not allowed to load anything from/System/PrivateFrameworks at run time - but that'd prevent Apple's own frameworks from doing that, so some way of granting privileges to some userland code in the process's address space but not to other userland code would be needed).
the solution is simple : break the internal API every now and then as needed, but provide a stable API for apps to hook into. This way a developer will think twice about doing such things, as it means their app could very well break come next update.
If by "provide a stable API for apps to hook into" you mean "provide a stable API for everything that you could do with an internal API", there's no point in the internal APIs, and you're now required to, for everything that a built-in app can do, design an API you're willing to live with and support for a while. I would not assume that's necessarily "simple".
...but not on Mac OS X, which, unfortunately, has none of them. (Do, however, see nm and otool -L; at least OS X has them, and the iPhone OS development tools might have them, or the OS X versions might Just Work on iPhone OS binaries, as iPhone OS binaries are Mach-O binaries for ARM.)
But, yes, it's certainly possible for some software to look at the executable image for an iPhone OS app and figure out what it's linked with and what routines it's using. It's a bit harder to detect whether it uses, for example, dlopen() to load a library or framework at run time and then uses dlsym() to look up symbols in that library, unless dlopen() and company are on the Forbidden Interface List for iPhone OS apps and they bounce anything that uses them.
I have no idea if Apple's chat program understands bluetooth, though, and you're probably not allowed to write a competing chat app.
"Apple's chat program" either refers to 1) iChat, which isn't available on the iPhone or 2) the SMS/Messages app, which only understands SMS/MMS (and MMS only in iPhone OS 3.0 and later and only if you have a 3G phone). On the iPhone, an IM-over-TCP/IP app is "competing" only in that they both let you have short message-based conversations, and there are several IM apps for the iPhone (AIM, Yahoo! Messenger!, etc.), although none from Apple Inc. (no, I have no idea why iPhone OS doesn't include iChat).
Why then does the link the Cnet article links to say this "Not all the Wi-Fi finding apps have been removed however. There are still a couple of Wi-Fi finders, including JiWire's Free Wi-Fi Finder and WiFi Directory"?
Because, to quote an update to the Cult Of Mac article, "Perhaps the private framework is the iPhone’s built-in 802.11 radio? The remaining Wi-Fi finders in the App Store aren’t stumblers, but lists of free hotspots that are found using the iPhone’s GPS or network triangulation capabilities." (emphasis mine).
Why do they need to protect me from maintaining my app? If I use an API and they do something that breaks it, it's my responsibility to fix it or they pull the app.
If it's an officially documented API, that is not the case, at least not with Mac OS X (and, as far as I know, with other commercial UN*Xes and Windows). People generally get peeved if updating the OS breaks an app, and the first organization to which they complain is likely to be the OS vendor, so the OS vendor makes at least some effort not to break APIs. I think Raymond Chen has talked about this at Microsoft, and it's also an issue at Apple (try doing nm -p/usr/lib/libSystem.dylib | egrep '\$' on OS X - at least in newer versions, you'll find multiple versions of some APIs, so that the API can be changed without breaking binary compatibility with older apps).
Does the iPhone OS SDK say otherwise? Does it explicitly say that, if any app works on version N and fails to work on version N+1, it's ipso facto the app developer's fault?
Among other things, iCal Server and Addressbook Server which, when combined with a *nix LDAP/IMAP/SMTP setup, become a credible replacement option for Exchange.
I'd be happy to be informed otherwise, but I don't think FOSS and *nix have applications that offer equivalent functionality.
Well, there's this open-source thing called Calendar and Contacts Server; it might offer similar capabilities to iCal Server and Addressbook Server.:-)
(...because the guts of iCal Server are Calendar Server, and the guts of Addressbook Server are Contacts Server. I don't know how hard it would be to make them work on other UN*Xes; they're mostly written in Python, using Twisted, and the Wikipedia page for Calendar Server says that "It is currently possible to install it on FreeBSD and several flavours of Linux." but that it "uses... extended file attributes", so it might have some trouble on arbitrary UN*Xes. OS X Server might offer some GUI front-end stuff atop Calendar Server to make it iCal Server, and atop Contacts Server to make it Addressbook Server, but the underlying servers are open-source.)
It probably doesn't run the obscure vertical apps that you've never heard of but everyone seems to need.
Probably depends on that vertical app. According to Apple, "[As] an Open Brand UNIX 03 Registered Product, Mac OS X Server can compile and run all your existing UNIX code. So you can deploy it in environments that demand full conformance, complete with hooks to maintain compatibility with existing software."
He said "The Xserve might be able to handle the server backend part of such an app (like Linux) assuming it's supported. However, the frontend is going to be all WinDOS." Being an Open Brand UNIX 03 Registered Product does not significantly increase your ability to run Windows applications.
It also doesn't improve your ability to run binary-only applications that are offered for other Open Brand UNIX 03 Registered Products but not for your OS - or even binary-only applications offered for UN*Xes, such as Linux, that are not Open Brand UNIX 03 Registered Products, but not for your OS.
Minor note: PowerPC was the line of processors used in the Apple computers. POWER (as in Power7) is the server line of processors with it's roots in the as/400 servers back in the 90's.
The first POWER processor was in the first RS/6000 machines, back when the AS/400's were still IMPI machines. In any case, POWER/PowerPC/Power Architecture/etc. are all close cousins....
As much as I loved my macbook, it couldn't do basic tasks I need to do as an information security professional.
No promiscuous mode. Tools like wireshark, aircrack, fakeap, etc all didn't work properly due to issues with closed source wireless drivers.
Promiscuous mode is supported by the Ethernet drivers (using the same BIOCPROMISC ioctl as on other systems using BPF, and the libpcap is largely standard, so promiscuous mode works on Ethernet with tcpdump/Wireshark/etc. the same way it works elsewhere).
I haven't checked whether it works with Wi-Fi adapters. However, monitor mode does work, although, with Atheros-based adapters, going into monitor mode disassociates you from the network. In Tiger, you have to capture on the wlt1 device (and, on PowerBooks, you have to tweak the plist for the adapter and reboot; in Leopard, you have to request 802.11 headers with the -y flag (tcpdump, TShark, dumpcap) or the GUI (Wireshark). In Snow Leopard, you use -I (which, in OS X, requests 802.11 headers; on other platforms, libpcap 1.0.0/tcpdump 4.0.0 and later do whatever is necessary to get monitor mode with -I) with tcpdump - you still need the "request 802.11 headers" stuff with TShark/Wireshark/dumpcap (because nobody's changed them yet to use the new libpcap 1.0.0 APIs if available.
We could modify the GPL a little to demand that all FOSS and derivatives live by the GPL
And how do you propose to modify the GPL to require that all FOSS projects follow it? You could change the GPL to forbid "mere aggregation" of a GPLed project and a non-GPLed project, but that might just inspire non-GPL FOSS projects such as *BSD, and derivatives such as OS X, to come up with non-GPLed replacements for GPLed projects (or, rather, inspire them to do so to a greater degree than they're already working on that).
You're right. It was about the silly little certification you said no one cared about.
No, it was about the source code. The certification has nothing to do with the source code; you could have a certified system using none of the AT&T-derived source code, or an AT&T-source-code-derived OS that doesn't pass all the tests required for certification.
Slashdot Mirror
Look, the kernel rarely works on its own. Leaving aside the embedded stuff, what has been successful, has been a combination of lots of userland applications and the Linux kernel. You are right in saying that most successful Open-Source project have strong central leadership. But GNU/Linux as a whole? Not a chance. So Gnome project goes one way, X(org) goes the other way. Apache goes one way, kernel goes the other way. Millions of such examples where 2 loosely related items in GNU/Linux have their independent leadership, do what they damn please.
Yup, and they never have Linux Plumbers Conferences to try to get parts of the platform that need to work together to work together well. Perhaps not "central leadership", but not "chaos", either.
As for Apache, it's an app that runs atop a number of platforms, including Linux-kernel-plus-some-particular-bits-of-userland; it manages to go its own way, and work, even though the Linux-kernel-plus-some-particular-bits-of-userland, Mac OS X, Solaris, FreeBSD, NetBSD, OpenBSD, DragonFly BSD, HP-UX, AIX, Windows, etc. platforms go their own way; Linux isn't particularly special in that case.
This is exactly what happened when moving from 2.0 to 3.0. Developers had to update their apps or they may have stopped working and got pulled. It doesn't matter if you used improper APIs.
O RLY? I didn't see updates for all the third-party apps on my iPhone prior to 3.0 or when 3.0 came out. Apple might require you to verify that your app still works with an OS update, and fix it if it doesn't, but if it still works on the new OS, there should be no need to make an update and, as far as I know, there is no need to make an update.
Also, MeeGo should provides an easy porting target for Android apps (Java duh?)
I have the impression that Android isn't exactly a standard Java platform, and it probably also has a pile of its own classes that you don't magically get to use on every Java platform.
and eventually iPhone Apps (GnuSTEP).
GNUStep doesn't exactly include every single class that's in iPhone OS (or Mac OS X, for that matter), either.
This may be closer than you think:
http://www.macrumors.com/2010/03/05/apple-seeking-to-stimulate-mac-development-with-99-mac-dev-program/
Though this is just a first step toward an iPhone-like developer model,
By which I presume you mean "a model where they only charge you $99/year, don't have multiple tiers of developer, and perhaps don't offer hardware discounts". There are a number of ways in which the Mac OS X and iPhone OS developer programs differ; the fact that they're getting rid of one of them (higher price) does not ipso facto mean that the long-term plan is to make the Mac OS X developer program exactly like the iPhone OS program, down to the app store and restrictions.
What scares me about this though is that Apple are gradually being sucked into their own hype; that only end-to-end control of the experience by Apple is the way to ensure quality. This in spite of the obvious failure in quality control in their store and the many inconsistencies in applying their policy.
Which is inexcusable, as Apple have had over 10 years worth of iPhone experience and should know how to do the app checking by now. Oh, wait....
(Yes, it should've been better from the start. I suspect it'll get better over time.
And, yes, I think there should be an option to allow installation of non-App Store apps, with a big pop-up warning that "IF YOU FLIP THIS SWITCH, AND YOUR PHONE TURNS INTO A BRICK OR GETS BROKEN INTO OR SOME APP STOPS WORKING AFTER A SOFTWARE UPDATE OR..., AND YOU BRING IT TO THE GENIUS BAR TO GET IT FIXED, WE WILL TAKE GREAT DELIGHT IN YOUR MISERY AND LAUGH YOU OUT OF THE STORE", so that you're not stuck with approved apps and they're not stuck with supporting apps that haven't gone through the approval process or devices running those apps. I like contracts that bind both parties, like API contracts - "you use only the documented routines, and use them only in the documented fashion, and we won't change them so that they stop working that way"; as somebody who's designed and implemented various program interfaces, I like them a lot better than, say, "I get to do what I want with your libraries and you have to support me".)
the whole private api bit is probably a cop out, a card they finally pulled and played to placate cellphone providers.
...because, without those apps, an iPhone cannot possibly find Wi-Fi networks, so you're forced to use GPRS/EDGE/HS*PA everywhere. Oh, wait....
If they use API calls that Apple didn't want them to, why were they approved?
Perhaps because the review process isn't as good as it should be?
There's no app for that.
There's no supported stable API for that (in iPhone OS or in Mac OS X). (Yes, I think it would be nice if there were. I'm not about to say "Apple should ship what they have now", however.)
no, I have no idea why iPhone OS doesn't include iChat
Ah, that was my assumption that it did. How very strange - perhaps AT&T wanted the SMS revenue.
If so, why are AIM, Yahoo! Messenger!, etc. apps allowed on the App Store? Or is the idea that somebody has to go through some effort to find out about and get those apps, so a lot of people just default to using SMS?
So it looks like this may be about the PlaceEngine framework, not wifi per se.
The OS X version of PlaceEngine is an app, not a framework - and it, err, umm, uses a private framework:
The iPhone OS version might do the same. Yes, it's unfortunate that there's no public API in OS X - and, I suspect, iPhone OS - to get information about nearby access points, but I wouldn't assume that the private interfaces are, in their current state, something that Apple would like to be forced to preserve in a compatible fashion so as not to break third-party apps.
Apple is understandably very protective about the lowest-level radio controls on a cell phone.
Apple's cell phone has more than one radio in it. The radio that implements IEEE 802.11 is separate from the radio that implements the GSM/UMTS air interfaces (and separate from the radios that implement Bluetooth and GPS).
One thing they gain is not having to care what third-party apps they break if they decide to change the way, say, the private framework in question works, because at time T they decided "it should work this way" and at time T+delta T they realized that with 802.11xyzzy, or with a change to the way they handle captive networks, or..., it really needs to work some other way.
Of course, they'd gain less irritation if they could catch this beforehand, but maybe the offending apps loaded up the private framework at run time rather than being explicitly linked with the framework; a simple otool -L would identify apps explicitly linked with the framework, but, unless you forbid using any interfaces that let you load libraries/frameworks at run time, it's probably trickier to catch those (although I guess you could sandbox apps so that they're not allowed to load anything from /System/PrivateFrameworks at run time - but that'd prevent Apple's own frameworks from doing that, so some way of granting privileges to some userland code in the process's address space but not to other userland code would be needed).
the solution is simple : break the internal API every now and then as needed, but provide a stable API for apps to hook into. This way a developer will think twice about doing such things, as it means their app could very well break come next update.
If by "provide a stable API for apps to hook into" you mean "provide a stable API for everything that you could do with an internal API", there's no point in the internal APIs, and you're now required to, for everything that a built-in app can do, design an API you're willing to live with and support for a while. I would not assume that's necessarily "simple".
see ldd, strace and ltrace, for example.
...but not on Mac OS X, which, unfortunately, has none of them. (Do, however, see nm and otool -L; at least OS X has them, and the iPhone OS development tools might have them, or the OS X versions might Just Work on iPhone OS binaries, as iPhone OS binaries are Mach-O binaries for ARM.)
But, yes, it's certainly possible for some software to look at the executable image for an iPhone OS app and figure out what it's linked with and what routines it's using. It's a bit harder to detect whether it uses, for example, dlopen() to load a library or framework at run time and then uses dlsym() to look up symbols in that library, unless dlopen() and company are on the Forbidden Interface List for iPhone OS apps and they bounce anything that uses them.
I have no idea if Apple's chat program understands bluetooth, though, and you're probably not allowed to write a competing chat app.
"Apple's chat program" either refers to 1) iChat, which isn't available on the iPhone or 2) the SMS/Messages app, which only understands SMS/MMS (and MMS only in iPhone OS 3.0 and later and only if you have a 3G phone). On the iPhone, an IM-over-TCP/IP app is "competing" only in that they both let you have short message-based conversations, and there are several IM apps for the iPhone (AIM, Yahoo! Messenger!, etc.), although none from Apple Inc. (no, I have no idea why iPhone OS doesn't include iChat).
NO! they do not "do the same thing".
Why then does the link the Cnet article links to say this "Not all the Wi-Fi finding apps have been removed however. There are still a couple of Wi-Fi finders, including JiWire's Free Wi-Fi Finder and WiFi Directory"?
Because, to quote an update to the Cult Of Mac article, "Perhaps the private framework is the iPhone’s built-in 802.11 radio? The remaining Wi-Fi finders in the App Store aren’t stumblers, but lists of free hotspots that are found using the iPhone’s GPS or network triangulation capabilities." (emphasis mine).
Why do they need to protect me from maintaining my app? If I use an API and they do something that breaks it, it's my responsibility to fix it or they pull the app.
If it's an officially documented API, that is not the case, at least not with Mac OS X (and, as far as I know, with other commercial UN*Xes and Windows). People generally get peeved if updating the OS breaks an app, and the first organization to which they complain is likely to be the OS vendor, so the OS vendor makes at least some effort not to break APIs. I think Raymond Chen has talked about this at Microsoft, and it's also an issue at Apple (try doing nm -p /usr/lib/libSystem.dylib | egrep '\$' on OS X - at least in newer versions, you'll find multiple versions of some APIs, so that the API can be changed without breaking binary compatibility with older apps).
Does the iPhone OS SDK say otherwise? Does it explicitly say that, if any app works on version N and fails to work on version N+1, it's ipso facto the app developer's fault?
What does it offer that any other *nix would not?
Among other things, iCal Server and Addressbook Server which, when combined with a *nix LDAP/IMAP/SMTP setup, become a credible replacement option for Exchange.
I'd be happy to be informed otherwise, but I don't think FOSS and *nix have applications that offer equivalent functionality.
Well, there's this open-source thing called Calendar and Contacts Server; it might offer similar capabilities to iCal Server and Addressbook Server. :-)
(...because the guts of iCal Server are Calendar Server, and the guts of Addressbook Server are Contacts Server. I don't know how hard it would be to make them work on other UN*Xes; they're mostly written in Python, using Twisted, and the Wikipedia page for Calendar Server says that "It is currently possible to install it on FreeBSD and several flavours of Linux." but that it "uses ... extended file attributes", so it might have some trouble on arbitrary UN*Xes. OS X Server might offer some GUI front-end stuff atop Calendar Server to make it iCal Server, and atop Contacts Server to make it Addressbook Server, but the underlying servers are open-source.)
It probably doesn't run the obscure vertical apps that you've never heard of but everyone seems to need.
Probably depends on that vertical app. According to Apple, "[As] an Open Brand UNIX 03 Registered Product, Mac OS X Server can compile and run all your existing UNIX code. So you can deploy it in environments that demand full conformance, complete with hooks to maintain compatibility with existing software."
He said "The Xserve might be able to handle the server backend part of such an app (like Linux) assuming it's supported. However, the frontend is going to be all WinDOS." Being an Open Brand UNIX 03 Registered Product does not significantly increase your ability to run Windows applications.
It also doesn't improve your ability to run binary-only applications that are offered for other Open Brand UNIX 03 Registered Products but not for your OS - or even binary-only applications offered for UN*Xes, such as Linux, that are not Open Brand UNIX 03 Registered Products, but not for your OS.
Minor note: PowerPC was the line of processors used in the Apple computers. POWER (as in Power7) is the server line of processors with it's roots in the as/400 servers back in the 90's.
The first POWER processor was in the first RS/6000 machines, back when the AS/400's were still IMPI machines. In any case, POWER/PowerPC/Power Architecture/etc. are all close cousins....
Assuming you've already sifted through the 140,000 apps and not found a text or spreadsheet editor
For example, a text editor/word processor such as Pages or a spreadsheet such as Numbers?
As much as I loved my macbook, it couldn't do basic tasks I need to do as an information security professional.
No promiscuous mode. Tools like wireshark, aircrack, fakeap, etc all didn't work properly due to issues with closed source wireless drivers.
Promiscuous mode is supported by the Ethernet drivers (using the same BIOCPROMISC ioctl as on other systems using BPF, and the libpcap is largely standard, so promiscuous mode works on Ethernet with tcpdump/Wireshark/etc. the same way it works elsewhere).
I haven't checked whether it works with Wi-Fi adapters. However, monitor mode does work, although, with Atheros-based adapters, going into monitor mode disassociates you from the network. In Tiger, you have to capture on the wlt1 device (and, on PowerBooks, you have to tweak the plist for the adapter and reboot; in Leopard, you have to request 802.11 headers with the -y flag (tcpdump, TShark, dumpcap) or the GUI (Wireshark). In Snow Leopard, you use -I (which, in OS X, requests 802.11 headers; on other platforms, libpcap 1.0.0/tcpdump 4.0.0 and later do whatever is necessary to get monitor mode with -I) with tcpdump - you still need the "request 802.11 headers" stuff with TShark/Wireshark/dumpcap (because nobody's changed them yet to use the new libpcap 1.0.0 APIs if available.
We could modify the GPL a little to demand that all FOSS and derivatives live by the GPL
And how do you propose to modify the GPL to require that all FOSS projects follow it? You could change the GPL to forbid "mere aggregation" of a GPLed project and a non-GPLed project, but that might just inspire non-GPL FOSS projects such as *BSD, and derivatives such as OS X, to come up with non-GPLed replacements for GPLed projects (or, rather, inspire them to do so to a greater degree than they're already working on that).
UNIX isn't a trademark, UNIX isn't a certification, UNIX is a design philosophy and one that OSX trashes utterly with its entire GUI.
Which UN*Xes have a GUI that does conform to that design philosophy?
Trying to find something in /etc? Good luck, it's probably in /Library in a different place with a different name than on EVERY OTHER UNIX.
If your putative-UN*X OS doesn't do at least one thing different from EVERY OTHER UNIX, it's not a real UN*X.
You're right. It was about the silly little certification you said no one cared about.
No, it was about the source code. The certification has nothing to do with the source code; you could have a certified system using none of the AT&T-derived source code, or an AT&T-source-code-derived OS that doesn't pass all the tests required for certification.
I love my Thinkpad. It is made out of freedom.
No, it's made out of plastic, metal, and doped silicon.
(And, if you're curious, my MacBook Pro is made out of plastic, metal, and doped silicon, too; it's not made out of Magic Apple Pixie Dust.)