Yeah, we may well be thinking of different laws. Especially at oh-god-this-is-too-early o'clock.:)
Though that quote... "if the content is otherwise legal." I suspect the issue is that what they have been pointed at are incest or pedophilia type stuff, and while the fiction is probably legal, I suspect they just plain are not really reviewing things well. If the content is legal they are not obligated to remove it, but what is or is not legal on the Internet (even in the US, given differing state laws) is probably a matter for debate.
So while I think SixApart are handling this about as poorly as a company possibly can, I *can* also see where they might feel some legitimate concern (or some concern with the illusion of legitimacy) over their legal liability. Especially when a group who quite clearly would intend to pressure them in other ways (such as legal) start pointing out the supposed issues.
I am not sure they actually WOULD be liable in such a case. But I can see, given past publicized cases, where they might think they would be. If that makes sense. (Not, granted, that much to do with the Internet and law ever does make sense.)
IANAL, but I believe the section you are thinking of is:
(1) Treatment of publisher or speaker No provider or user of an interactive computer service shall be treated as the publisher or speaker of any information provided by another information content provider.
...provided by ANOTHER information content provider. As I understand it, if I am one of these 'Think of the Children' types, and I am with Comcast, and my child goes and finds a porn site, Comcast cannot be held responsible for the porn site. The company/hosting/ the porn site can still be held responsible.
(2) Civil liability
No provider or user of an interactive computer service shall be
held liable on account of -
(A) any action voluntarily taken in good faith to restrict
access to or availability of material that the provider or user
considers to be obscene, lewd, lascivious, filthy, excessively
violent, harassing, or otherwise objectionable, whether or not
such material is constitutionally protected; or
(B) any action taken to enable or make available to
information content providers or others the technical means to
restrict access to material described in paragraph (1)
So my understanding of this is that it is intended to say basically 'you cannot sue your ISP for the content of the Internet,' and 'you cannot prosecute people as restricting speech if they are making good-faith efforts to block inappropriate material they host, OR to provide filtering mechanisms which rate and block inappropriate material.'
I may be misreading it, but I do not think the law (even any of the other sections, at least as best I can read it) protects a website from being liable for offensive user-posted content once informed of the existence of such content. I believe, though again I may be wrong, that liability issues are actually why many ISPs will just shut down hosted sites when sent a DMCA takedown notice.
Realistically, no OS is completely secure. This is hardly the first security issue in OS X, nor will it be the last. Linux has had its share of security flaws, too.
In the modern world, there are simply too many protocols and systems popping up; no operating system exists in a vacuum, and many vulnerabilities may be in services, subsystems and so on. And with the pressure to get things out and shave off extra CPU cycles, there are too many situations where someone simply goes 'oh, well, I checked that this data is valid up HERE, so I don't need to check again down here in this function I call later,' and then later another piece of code goes, 'oh, look, here is a function that does what I need, I will just reuse it' and assumes that function does its own error-checking, so does not check the data before passing into it. And thus, you create a pathway where unvalidated data gets passed down and can cause buffer overflows or whatever.
No operating system or development team is somehow inherently immune to this.
The thing is that Windows not only has kept large chunks of legacy code -- which makes it hard to really break down and restrict user permissions without breaking older programs -- but spent some time really pushing the Active X technology, which then proved to create a lot of problems. Apple, on the other hand, went off the tracks entirely and threw out their operating system; that was a risky move which could have killed them off entirely, but in the end they got an operating system which was built atop a multi-user system with better permissions.
That does not mean that Apple somehow writes inherently better code than Microsoft; I happen to like OS X, but Apple's engineers are not necessarily smarter or more careful in the actual lines of code they write. The difference as I see it is that Microsoft is bogged down by hard-to-debug and support legacy code, while Apple got to make a cleaner start... and then on top of that, many bits of OS X (CUPS, zeroconf/Bonjour, WebKit, etc.) are open source.
Apple contributes funds and engineering to these projects (and in some cases such as zeroconf, came up with the original specifications), but as they are open source things tend to get found and fixed faster in community review. That is why OS X, while not bulletproof, tends to be at least a bit more secure than Windows.
There are Cocoa-based apps which do not make use of the extended frameworks (such as CoreGraphics, CoreAnimation, CoreData, etc.), and other frameworks (such as Bonjour) are based on open source technologies, and could be recreated as part of GnuStep. Many things that are still compatible with Panther don't take advantage of those frameworks, for instance. (I will, however, agree that such apps are becoming increasingly rare as people move to take advantage of Tiger's technologies and prepare for Leopard.)
I think binary compatibility is likely to be a pipe dream without a project dedicating the amount of effort that has been put into Wine. And I agree that even source compatibility is not easily reached. But I think it is still quite possible to get GnuStep to a place that simpler Panther-compatible OS X apps will compile natively.
I think it is not necessarily the best way to port -- see previous posts I have made about 'designing the UI for your target system' -- but I was trying to address the original poster's point. Namely, that I think that porting Cocoa apps to Linux is a far more attainable goal than either binary emulation or porting Carbonized apps.:)
Carbon is a sort of bizarre chimera library, which was intended to provide a compatible set of APIs between classic Mac OS and Mac OS X. So that once OS X was on the way, you could carbonize an app under Classic and have it just work on OS X. Brilliant idea, but it means Carbon isn't a close relative of anything. It's a huge library and framework (since it spanned multiple operating systems), and would basically have to be engineered from scratch.
In contrast, Cocoa is what used to be OPENSTEP; it's just been renamed. GnuStep thus provides the same stuff Cocoa does, but tends to be several years behind. (Also, GnuStep provides source-level compatibility with a given revision of Cocoa, not binary-level.)
The iPhone battery lasts a good few hundred charge cycles -- i.e., being fully drained and charged -- before it stops holding a charge as effectively. It does not die, it just does not hold as complete a charge as it used to.
Yeah, that is lousy... but this is not an iPhone-specific issue. It is the major drawback of all Li-ion batteries (including those in other cellular phones).
The advantage of Li-ion is that unlike most other rechargeable batteries, they will not self-discharge (i.e. lose power when not in use) nearly so badly, but the cost of that is a battery which does 'age' and lose efficiency the more charge cycles you go through, and which is temperature sensitive. There's a good article on lithium-ion battery limitations on Wikipedia, or you can just google Li-ion to find other various battery FAQs on the net.
I find it sort of telling that Apple decided they'd be up-front about this general limitation of the lithium-ion rechargable batteries in phones and laptops -- a limitation all Li-ion batteries share -- and they've taken nothing but flack for it, as if it were all their fault. No wonder companies don't like to tell consumers that sort of thing.
It is unfortunate that an iPhone user cannot replace a dead battery themselves, sure. And the battery price is kinda high; most smartphones, the battery tends to be around $50. Though they also tend only to last about 3-4 hours under full use; Apple's battery is larger capacity, so I'm not surprised it costs a little more. Though I think double the cost is a bit pricy, even including the battery replacement labor. So, yeah, the iPhone maybe deserves a bit of razzing over their battery situation for the high cost.
But the battery charge limitations are not in any way unique to Apple's batteries. And I know I am getting a little tired of people throwing stuff at Apple as if they are responsible for a limitation which exists in the battery technology in pretty much all the mobile devices I have. Including my Dell laptop, my Panasonic cordless phone, my Canon digital camera, my old HTC handhelds, and so on... none of which came from Apple.
You own the software to an extent. You can download the source code for several parts (albeit, not all) of the TiVo system directly from TiVo, including many of their tools (and their modified PowerPC Linux kernel, obviously, to be fully GPL compliant). And there are plenty of user-provided modifications out there to do things like make a TiVo pull from xmltv (so that a TiVo can work in places where TiVo listings are not available) and so on.
Here is a decent list of TiVo hacking resources. Sure, you invalidate your warranty, but if you rip apart something and rebuild it, it's not really rational to expect the company -- who have no way of knowing what you have done, how you have done it, and so on -- to still provide support for it or a replacement.
Oh, no, I agree that porting will cause these problems; believe me, I've posted on that topic on here myself enough times. As a developer, this is a pet peeve of mine!:)
In my opinion, if you want to target cross-platform you're better off designing applications in two stages: the actual functional backend, and the GUI layer. Write all your core functionality as portably as you can, but divorce that functionality from most UI. Then write the UI from scratch for each system; use a drawer on OS X, use an MDI window on Windows, whatever. Have your popup notifications done as toasts on Windows, Growl notifications on OS X, etc. There are ported apps that approach it that way, and consequently/feel/ right and work solidly on each system they're hosted on. Not many, but they do exist, and they feel like they were designed properly for each system they run on.
Apple did not, unfortunately, and so while their software is wonderful under OS X, the ports are cringe-worthy.
As much an Apple fan as I am, I also hate Apple software on Windows. Not only does it look out of place, it Just Does Not Work. We share that particular boat; I use Mac OS X for my personal stuff -- web-browsing, e-mail, music, writing and so on -- and Windows for work and gaming. I love Apple's work on OS X, but I find their Windows software nauseating. When it comes down to it, I think anyone who likes Apple for *sensible* reasons (as opposed to just being a blind fan) hates Apple's approach to Windows software.
Those ports violate everything Apple supposedly stands for, such as software that 'just works.' Software 'just working' requires it to work/in context/ with the operating system, and everything else on the system. Apple's cross-system ports do not by/any/ stretch of the imagination; they attempt to shoehorn bits of OS X into Windows, and they do so poorly. (Also, whatever framework they used to port iTunes to Windows is horrible, and I want to find whoever wrote iPodService, hunt them down, and garrote them with a Firewire cable. WTF, Apple?)
This is actually a pet peeve for me. This same stupid shortcut approach to cross-platform development is why things developed on Windows and ported directly to OS X look mildly schizophrenic and get complaints about 'not being well-designed for OS X' from Mac users. It's also why a lot of cross-platform software ported from Linux using GTK+ for Windows or running under X11.app on OS X doesn't 'fit in' either. Why would Apple think this braindead approach to cross-platform development would work any better for them?
If you're going to do something cross-platform, bloody well develop it cross-platform instead of designing it just for one platform and then taking shortcuts to port it without thinking whether or not your design works in the new context.
Also, I'm reasonably certain enabling an automatic password fill on Opera would produce the same behavior. It's not as if Opera uses a different DOM for web-forms, or else we'll hear unending whining about how Opera doesn't work on standard Ajax sites. This isn't a code flaw in any one browser, it is a flaw in the philosophy that you can trust any Javascript code on a web page with any and all content on the same page; it's simply not accurate, because of things like Ajax xmlHttpRequest calls which allow any data on a page to be sent somewhere without even having to trick a user into some form of interaction.
But it's the same philosophy everything is based on, because it's how advanced Javascript and Ajax and so on actually work. Any browser that supports automatically filling a login form when you hit a page will be vulnerable to this. So it seems to me that what would make more sense is to put in a hotkey to 'auto-fill login forms' and only do so when the hotkey is pressed; the problem is that browsers blindly fill auto-login forms for a site without asking the user.
Why on earth do so many Slashdot posters seem to think it's about Mac fandom?
It is far from impossible that there's a vulnerability in OS X; there have been vulnerabilities before, after all, and there will be again. Just because OS X is more secure in its out-of-box configuration than Windows is in its own out-of-box does not mean that OS X is completely invulnerable to all future threats. Heck,/Linux/ isn't immune to all threats past and present, after all... why should OS X somehow mystically be,/especially/ when some vulnerabilities can come from software (OpenSSH, Apache, etc.) which both operating systems share? Heck, if the vulnerability is in mDNSResponder, it may be in the UNIX implementations of zeroconf. (It's not as if the guy has given any information for someone to determine whether it is or not!)
Anyone who thinks OS X is somehow immune to all threats is a fool, or deliberately blinding themselves. But the issue people criticizing the guy generally seem to be pointing out is that regardless of the OS involved, this researcher has handled the vulnerability disclosure in an extremely unprofessional manner.
This 'researcher' makes a claim providing no proof. No details. He expects to be lauded for it, however, without providing any proof. Instead he finds himself criticized for not acting as an actual security researcher and handling the exploit disclosure in a professional manner; after all, he gave no details, he allowed no peer review, and he also said he wasn't releasing details or an exploit to Apple to look into fixing until he finished 'testing' it (which, at best, means he didn't even have the exploit confirmed for himself before he trumpeted it everywhere). So when he finds his claim challenged and he's told to send the info to Apple to fix it, or to at least reveal a little further info? Suddenly he claims he was getting death threats... equally unsubstantiated... and takes his ball to go home.
I'm not saying some devoted Mac fans might not have mailed nasty stuff to the guy; there are some crazy Mac fans. Though they're far from the only fanatics in the tech world. (The GPL diehards who attack other open-source licenses like rabid pit bulls, for instance, are definitely their spiritual kindred as far as fanaticism goes.)
But imagine this was with some other system:
Some guy posts, "I found an exploit in Ubuntu. It affects all current versions of Ubuntu, and can allow me to do some bad things. There's no current defense against it. Bow down before me!" Followed by a later post of, "No, I am not going report the exploit to the Ubuntu team. Or anyone else. Because I haven't finished testing it. Just shut up and marvel at my awesomeness for finding a difficult exploit." People would be up in arms, howling for the guy's blood about why he announced it if it's not confirmed, how it's probably a violation of some source license for him to not actually report the exploit to Ubuntu to be fixed if it's real, or whatever. If then a few days later he posted, "Oh, now I'm getting death threats, so this isn't worth it. I'm just not going to tell ANYONE what it is." people would be convinced he'd been faking it and was 'running away' to avoid having to actually produce something. (And no doubt some people would also still be posting 'Oh, you Ubuntu fanboys, why can't you believe there might be a vulnerability? Why do you have to send him death threats?')
It would be equally irresponsible to handle an exploit report in, say, Vista the same way. Though admittedly, there'd probably be less outcry, as we've become sort of inured to those reports. ("Huh. A vulnerability in Windows. Okay, whatever. Right, let's go for coffee.")
All most sensible folks are saying in this discussion is that if he's legit, this guy handled his situation Poorly. And given that there have been several poorly-handled exploit reports lately which turned out to either be hugely inaccurate ("Okay, this is only actually v
Oh, please. Most sensible Mac users recognize that while OS X is/more/ secure out-of-the-box than your average XP installation, and segments permissions better, there's still plenty of ways for things to mess up an OS X box. It's stupid to think any OS is invulnerable; Linux isn't, FreeBSD isn't, Mac OS X isn't, Windows sure as heck isn't. It's just harder to target an out-of-box configuration, and so people generally don't bother. (Which, I grant, doesn't mean some Mac users won't be up in arms and claiming this is impossible. They're wrong, if they do, but still.)
HOWEVER, you don't have to be a fan of any specific platform to find the way the guy handles this to be extremely unprofessional.
The/proper/ way to handle a vulnerability -- on ANY platform -- is to report it to the vendor/developer in a timely manner before trumpeting it to the world. Exploits should be released (not leastwise because developers can learn from each others' mistakes), but they should be reported first. This
Meanwhile, this guy is proclaiming a vulnerability (but disclosing no details for anyone to learn from or judge the severity of), while simultaneously saying he has not yet -- and does not yet plan to -- report the vulnerability to the vendor. It's basically a shameless grab for publicity with vague information, rather than someone demonstrating that they take security research seriously.
The nature of the exploit, or the platform it affects, is not relevant to the guy's behavior; it's just plain irresponsible of any security researcher to act this way. It would be equally irresponsible to find some serious, significant exploit in Linux and trumpet 'ZOMG, I just discovered that there's a way for any program to steal root through a specific exploit in the current version of KDE! But I'm not going to tell the KDE folks anything about it until I've finished testing.' (Also, the guy would get eaten ALIVE by the Slashdot community for pulling a stunt like that, but I digress.)
Security researches are respected and taken seriously by vendors and developers (rather than being thought of as malicious hackers) specifically/because/ they handle exploit information in a professional and cooperative manner. This guy is not doing so, and THAT is the problem. Not what OS he's claiming an exploit in.
But it's not registering a domain name. The service that supposedly handles seamlessly swapping you between unlimited-use VoIP and your GSM cell plan/without even dropping calls/ as you switch is a service. It doesn't just work once, or even just (like dyndns) periodically get updated. It's an actual service you're using.
Without knowing how that specific phone works, we can't really know whether or not it supports doing direct IP-based SIP connections (or even if it uses SIP behind the scenes). Just that it does WiFi-hosted VoIP when there's a hotspot.
That said, if you have a generic free-service VoIP phone that also works as a GSM cellular phone, I can't imagine you COULDN'T use it. T-Mobile's never stopped people from using unlocked O2 handsets or whatever, so a GSM/generic-SIP-VoIP phone would presumably work fine. It's not like T-Mobile controls all WiFi, after all! It just wouldn't do the seamless hopping between spots, or integrate with the new T-Mobile-supported routers from D-Link and LinkSys (which will automatically prioritize VoIP data when a call is going on, and which do a single WiFi ping rather than making the handset drain battery finding the WiFi network).
From what I've read on T-Mobile's plan, you're not somehow paying for otherwise-freely-available VoIP. You're paying for a system they engineered, which their handset supports. Nothing's stopping you from using some other VoIP WiFi handset.:)
My guess is some cell company might decide to charge for unlimited wifi calls, even though you're not using they're network. I'm cheating 'cause I already saw the t-mobile ad. As I understand it, though, the T-Mobile WiFi handset actually does have a fairly significant added value over most generic WiFi SIP or Skype handsets.
With T-Mobile's proposed service, if you find a WiFi hotspot it automatically logs into a VoIP service provided by/T-Mobile/, and your cellular number suddenly becomes your VoIP number. People call the same number, but it now rings over your WiFi connection and you talk without using minutes. Plus, the report I read on it suggested you could transition seamlessly between WiFi and GSM; walk out into cellular coverage, and it switches back to GSM and the handset and T-Mobile's network handle seamlessly moving the call from VoIP to GSM cellular without even hanging up.
The idea is that you just have one number, and those calling you don't need to know or care whether you're on a WiFi hotspot or out in cellular service areas. What you're paying for in their proposed service is not the network bandwidth, but a flat service fee for their VoIP system and related services.
I don't know where Apple finds it's GUI guys Vat-grown to purpose, and indoctrinated in the Apple Way from day one, no doubt!;)
Seriously, though, I think it's mostly just corporate philosophy. Windows looks primarily for scientists, engineers, and so on; a friend who was an artist/graphic designer at Microsoft said they felt very much a second-class citizen, and recommendations often didn't get really listened to. For years, Apple has recruited artists and creative sorts right alongside devs.
In fairness, I think this is changing a bit; Microsoft's learning that the front-end is as important as the back-end, and is rethinking things and has done things like hiring artists and photographers, or even more importantly, building XAML so that artists can actually design real UI instead of just mockups. Whether XAML changes the UI playing field as much as Microsoft hopes remains to be seen, though.
I agree that the phone is the main advantage from a technical standpoint. My point was more that different form-factors work differently for different people.:)
I like what I've seen of the N800 for mobile browsing from a technical standpoint, but despite the beauty of the large screen, it's too bulky for me. I have smaller hands than many gadgeteers do, and the N800 doesn't fit my hand nicely. Nor does it fit well into the pocket of any of my jackets, and so I have to admit if I had one, it would probably get left at the house most times. The iPhone, for instance, doesn't do nearly as wide a variety of things as the N800 does, but I/could/ stuff it into a pocket of a jacket or purse, and it would handle both basic browsing/and/ phone in one device.
The N800 has far more impressive capabilities technically; it's just not a package that would be as-useful to me and my style of mobile computing, personally, as an iPhone-type device would be. (Whether or not that's the iPhone itself is not necessarily relevant to my point.)
Re:Yeah make it worthless, then I can afford one!!
on
Free the iPhone from AT&T
·
· Score: 3, Informative
I admit, from toying with one that a friend picked up, the N700/800 tablets look quite nicely usable. They do not, however, look like something I can slip into my purse, or the pocket of my jacket, for easy transport as a phone. (Especially as they need a Bluetooth phone to use for GPRS connectivity, and don't do normal GSM calling.)
I haven't taken the plunge and enslaved myself to AT&T for an iPhone, but I know that my desire for it is a tradeoff of several things. Windows Mobile just plain feels like I'm fighting with my PDA most of the times (I will spare you my rant on the astonishingly poor UI design of the Connection management screen in WM5), and most of the more-usable PDA-type devices are, like the N700, just too darn BIG to carry around conveniently for me, especially if I also have to carry a phone with me.
So all flashy 'woo' factor aside, the iPhone seems to have a very usable interface, do most of what I actually want from my PDA-phone (with, alas, the exception of IM... what were you THINKING, Apple?) and would fit in my jacket pocket much more conveniently. It's just that (ugh) AT&T requirement that's kept me from taking the plunge; T-Mobile's been fairly good to me.
I think no 'cross-platform' widget system will ever be a first-class citizen of the target OS beyond what it was developed for. Why?
Because things just simply work too differently. Look at Thunderbird; it's a great mail/news client... but on OS X, it does not integrate with the OS X system address book, nor does it support the system spellchecker's dictionary. There's a certain 'way' of doing things on any given OS, and if you try to write one single cross-platform UI (and I refer to overall user interaction here, such as the aforementioned spellcheck integration, not just the graphical aspect of the widgets), it will always feel a tiny bit 'wrong.'
I'm with a previous poster on this; you're better off separating the front-end from the back-end processing, and writing a native, OS-specific UI layer.
True, but the issue here is not GPL'd code, but LGPL'd (Limited GPL, or Library GPL) code. GPL means all your code must be open/released, or you cannot use the GPL'd code in your project; that's the situation you describe above. LGPL'd code can be linked in proprietary projects where the source is not available, but any *changes* you make to the LGPL'd code must be released/contributed back. The LGPL was originally created for libraries that should be usable in proprietary software, but which you don't want closed/proprietary forks of, but it's been used for other things as well.
In this case, it sounds as though SWSoft has taken LGPL'd code, modified it to do more stuff in some way and then used that for the 3d accleration support in Parallels 3.0... that's all fine, and Parallels itself doesn't need the source opened. But they have not contributed those changes to the actual LGPL code -- their own modifications, bugfixes, etc. -- back to Wine, and that is *not* okay under the license. So Wine wants the code contributed back, and SWSoft is stalling, which is the problem.
Even still, you can get a fair amount of noise if, say, you're doing concert photography or other no-flash-allowed low-light photography with a DSLR. My EOS 400D is a great camera, but it's a pain to shoot ISO 1600 with it unless I either have my f/1.8 wide-aperture lens on there or plan to spend a lot of time in post removing noise artifacts. My friend's EOS 5D, unsurprisingly, handles low-light shots far better than my 400D does, no doubt in part because of its own sensor being larger than that on the 400D.
So there's still room for improvement in DSLR sensors... though as to whether or not this is some magical miracle solution to low-light photography remains to be seen.:)
Not having heard the keynote itself but just poking through summaries, as I understand it the/underlying frameworks/ and various tools have been made both 32-bit and 64-bit. Thus, if you have 64-bit hardware, then you can use 64-bit addressing and thus handle a great deal more memory without issue, while hybrid binaries would still work on 32-bit.
So it sounds to me like what they are giving is one install for all the different hardware, which will take advantage of 64-bit stuff if you have it (for allowing media programs to work with far more memory than they can if kept purely 32-bit) without making the consumers worry about which version of Leopard or which version of a binary they need. I've seen nothing to imply that binaries built for a purely 64-bit-architecture will magically work on 32-bit hardware.
Offtopic here, but that's generally a really severe pressure that game developers get from their publishers, unfortunately. It's particularly severe there; it is not as if you have 'Electronic Wordprocessor Monthly' grading the latest import productivity apps, and raising the hype on them all.
("Capcom ExpenseBlaster 3 Turbo gets an 8/10 for the blazing next-generation way it lets me balance my checkbook!" "I'm sorry, but this one felt lacking to me. It was anemic in terms of features, especially compared to other contenders like Rockstar's 'Grand Theft Accounting,' and the money-laundering options. Only a 4/10.")
That doesn't stop people from proclaiming doom and gloom and trying to point out alternative software if non-game products slip, of course. Which means more than game developers get the market pressure to just 'get a 1.0 app out there, and patch it later,' albeit a bit less than game developers do. Which sucks, but... the cause of this one unfortunately lies with both the developers and consumers, I think.
Let's say there's something built atop an open source library. Hey, there's plenty of them out there... let's pick OpenSSL as an example. It's open source and it's used in other projects, some of which are commercial or proprietary systems. Now assume that some company makes a proprietary, closed product built on that project as the core, but continue to contribute changes -- a heck of a lot of changes -- back to the original project as the develop. And then they release this as a beta.
Finally, let's say that someone finds a vulnerability in the proprietary project, a security issue with implications for the open source project. And instead of reporting the vulnerability to the proprietary folks (who would probably promptly generate a patch for both their tool and the underlying library, the person refuses to report the vulnerability to anyone and just says 'I found vulnerabilities, but I'm not telling you what they are.'
That's basically how WebKit/KHTML and Safari are tied together. Safari's just a UI atop an open source framework, WebKit, which Apple is the primary contributor to but which other people also contribute to, and which other projects (besides Safari and OS X) use. WebKit is used on Symbian OS, on Linux, and various other operating systems. And this guy is claiming to have found vulnerabilities which, given where they occur, seem to have implications for WebKit as well as Safari... and is refusing to give the details to either Apple, or to the WebKit development community.
You don't have to be an Apple 'fanboi' (or fangirl) to see that's not the way to handle security disclosures. If someone found several bugs in Firefox and said 'ZOMG I can crash Firefox or anything which uses the Gecko HTML engine. I can do it 100% of the time. But I'm not going to report the details to the Firefox team, so, nyah!' people would be up in arms about it.
Professional, good security researchers report things to the responsible parties, giving them the details necessary to fix it. Going, "Ha ha, I found a way to break your stuff but I'm not going to tell you how" is not only unprofessional, it's just downright immature.
Sure, lambaste Apple for releasing a beta/preview of something with bugs if you feel you must. But, please, don't bother trying to defend someone who basically makes a mockery of the entire security field.
Not to mention that aside from WebKit, which the parent poster points to, or the zeroconf standard (which Apple helped to write), they've also contributed a lot of code to another open source project in particular. It's called the GNU Compiler Collection, or GCC for short. You might have seen it around on a Linux box or two, even.;)
Slashdot Mirror
Yeah, we may well be thinking of different laws. Especially at oh-god-this-is-too-early o'clock. :)
Though that quote... "if the content is otherwise legal." I suspect the issue is that what they have been pointed at are incest or pedophilia type stuff, and while the fiction is probably legal, I suspect they just plain are not really reviewing things well. If the content is legal they are not obligated to remove it, but what is or is not legal on the Internet (even in the US, given differing state laws) is probably a matter for debate.
So while I think SixApart are handling this about as poorly as a company possibly can, I *can* also see where they might feel some legitimate concern (or some concern with the illusion of legitimacy) over their legal liability. Especially when a group who quite clearly would intend to pressure them in other ways (such as legal) start pointing out the supposed issues.
I am not sure they actually WOULD be liable in such a case. But I can see, given past publicized cases, where they might think they would be. If that makes sense. (Not, granted, that much to do with the Internet and law ever does make sense.)
So my understanding of this is that it is intended to say basically 'you cannot sue your ISP for the content of the Internet,' and 'you cannot prosecute people as restricting speech if they are making good-faith efforts to block inappropriate material they host, OR to provide filtering mechanisms which rate and block inappropriate material.'
I may be misreading it, but I do not think the law (even any of the other sections, at least as best I can read it) protects a website from being liable for offensive user-posted content once informed of the existence of such content. I believe, though again I may be wrong, that liability issues are actually why many ISPs will just shut down hosted sites when sent a DMCA takedown notice.
Realistically, no OS is completely secure. This is hardly the first security issue in OS X, nor will it be the last. Linux has had its share of security flaws, too.
In the modern world, there are simply too many protocols and systems popping up; no operating system exists in a vacuum, and many vulnerabilities may be in services, subsystems and so on. And with the pressure to get things out and shave off extra CPU cycles, there are too many situations where someone simply goes 'oh, well, I checked that this data is valid up HERE, so I don't need to check again down here in this function I call later,' and then later another piece of code goes, 'oh, look, here is a function that does what I need, I will just reuse it' and assumes that function does its own error-checking, so does not check the data before passing into it. And thus, you create a pathway where unvalidated data gets passed down and can cause buffer overflows or whatever.
No operating system or development team is somehow inherently immune to this.
The thing is that Windows not only has kept large chunks of legacy code -- which makes it hard to really break down and restrict user permissions without breaking older programs -- but spent some time really pushing the Active X technology, which then proved to create a lot of problems. Apple, on the other hand, went off the tracks entirely and threw out their operating system; that was a risky move which could have killed them off entirely, but in the end they got an operating system which was built atop a multi-user system with better permissions.
That does not mean that Apple somehow writes inherently better code than Microsoft; I happen to like OS X, but Apple's engineers are not necessarily smarter or more careful in the actual lines of code they write. The difference as I see it is that Microsoft is bogged down by hard-to-debug and support legacy code, while Apple got to make a cleaner start... and then on top of that, many bits of OS X (CUPS, zeroconf/Bonjour, WebKit, etc.) are open source.
Apple contributes funds and engineering to these projects (and in some cases such as zeroconf, came up with the original specifications), but as they are open source things tend to get found and fixed faster in community review. That is why OS X, while not bulletproof, tends to be at least a bit more secure than Windows.
That is my take on it, anyway.
There are Cocoa-based apps which do not make use of the extended frameworks (such as CoreGraphics, CoreAnimation, CoreData, etc.), and other frameworks (such as Bonjour) are based on open source technologies, and could be recreated as part of GnuStep. Many things that are still compatible with Panther don't take advantage of those frameworks, for instance. (I will, however, agree that such apps are becoming increasingly rare as people move to take advantage of Tiger's technologies and prepare for Leopard.)
:)
I think binary compatibility is likely to be a pipe dream without a project dedicating the amount of effort that has been put into Wine. And I agree that even source compatibility is not easily reached. But I think it is still quite possible to get GnuStep to a place that simpler Panther-compatible OS X apps will compile natively.
I think it is not necessarily the best way to port -- see previous posts I have made about 'designing the UI for your target system' -- but I was trying to address the original poster's point. Namely, that I think that porting Cocoa apps to Linux is a far more attainable goal than either binary emulation or porting Carbonized apps.
Carbon is a sort of bizarre chimera library, which was intended to provide a compatible set of APIs between classic Mac OS and Mac OS X. So that once OS X was on the way, you could carbonize an app under Classic and have it just work on OS X. Brilliant idea, but it means Carbon isn't a close relative of anything. It's a huge library and framework (since it spanned multiple operating systems), and would basically have to be engineered from scratch.
In contrast, Cocoa is what used to be OPENSTEP; it's just been renamed. GnuStep thus provides the same stuff Cocoa does, but tends to be several years behind. (Also, GnuStep provides source-level compatibility with a given revision of Cocoa, not binary-level.)
The iPhone battery lasts a good few hundred charge cycles -- i.e., being fully drained and charged -- before it stops holding a charge as effectively. It does not die, it just does not hold as complete a charge as it used to.
Yeah, that is lousy... but this is not an iPhone-specific issue. It is the major drawback of all Li-ion batteries (including those in other cellular phones).
The advantage of Li-ion is that unlike most other rechargeable batteries, they will not self-discharge (i.e. lose power when not in use) nearly so badly, but the cost of that is a battery which does 'age' and lose efficiency the more charge cycles you go through, and which is temperature sensitive. There's a good article on lithium-ion battery limitations on Wikipedia, or you can just google Li-ion to find other various battery FAQs on the net.
I find it sort of telling that Apple decided they'd be up-front about this general limitation of the lithium-ion rechargable batteries in phones and laptops -- a limitation all Li-ion batteries share -- and they've taken nothing but flack for it, as if it were all their fault. No wonder companies don't like to tell consumers that sort of thing.
It is unfortunate that an iPhone user cannot replace a dead battery themselves, sure. And the battery price is kinda high; most smartphones, the battery tends to be around $50. Though they also tend only to last about 3-4 hours under full use; Apple's battery is larger capacity, so I'm not surprised it costs a little more. Though I think double the cost is a bit pricy, even including the battery replacement labor. So, yeah, the iPhone maybe deserves a bit of razzing over their battery situation for the high cost.
But the battery charge limitations are not in any way unique to Apple's batteries. And I know I am getting a little tired of people throwing stuff at Apple as if they are responsible for a limitation which exists in the battery technology in pretty much all the mobile devices I have. Including my Dell laptop, my Panasonic cordless phone, my Canon digital camera, my old HTC handhelds, and so on... none of which came from Apple.
You own the software to an extent. You can download the source code for several parts (albeit, not all) of the TiVo system directly from TiVo, including many of their tools (and their modified PowerPC Linux kernel, obviously, to be fully GPL compliant). And there are plenty of user-provided modifications out there to do things like make a TiVo pull from xmltv (so that a TiVo can work in places where TiVo listings are not available) and so on.
Here is a decent list of TiVo hacking resources. Sure, you invalidate your warranty, but if you rip apart something and rebuild it, it's not really rational to expect the company -- who have no way of knowing what you have done, how you have done it, and so on -- to still provide support for it or a replacement.
Oh, no, I agree that porting will cause these problems; believe me, I've posted on that topic on here myself enough times. As a developer, this is a pet peeve of mine! :)
/feel/ right and work solidly on each system they're hosted on. Not many, but they do exist, and they feel like they were designed properly for each system they run on.
In my opinion, if you want to target cross-platform you're better off designing applications in two stages: the actual functional backend, and the GUI layer. Write all your core functionality as portably as you can, but divorce that functionality from most UI. Then write the UI from scratch for each system; use a drawer on OS X, use an MDI window on Windows, whatever. Have your popup notifications done as toasts on Windows, Growl notifications on OS X, etc. There are ported apps that approach it that way, and consequently
Apple did not, unfortunately, and so while their software is wonderful under OS X, the ports are cringe-worthy.
Those ports violate everything Apple supposedly stands for, such as software that 'just works.' Software 'just working' requires it to work
This is actually a pet peeve for me. This same stupid shortcut approach to cross-platform development is why things developed on Windows and ported directly to OS X look mildly schizophrenic and get complaints about 'not being well-designed for OS X' from Mac users. It's also why a lot of cross-platform software ported from Linux using GTK+ for Windows or running under X11.app on OS X doesn't 'fit in' either. Why would Apple think this braindead approach to cross-platform development would work any better for them?
If you're going to do something cross-platform, bloody well develop it cross-platform instead of designing it just for one platform and then taking shortcuts to port it without thinking whether or not your design works in the new context.
Also, I'm reasonably certain enabling an automatic password fill on Opera would produce the same behavior. It's not as if Opera uses a different DOM for web-forms, or else we'll hear unending whining about how Opera doesn't work on standard Ajax sites. This isn't a code flaw in any one browser, it is a flaw in the philosophy that you can trust any Javascript code on a web page with any and all content on the same page; it's simply not accurate, because of things like Ajax xmlHttpRequest calls which allow any data on a page to be sent somewhere without even having to trick a user into some form of interaction.
But it's the same philosophy everything is based on, because it's how advanced Javascript and Ajax and so on actually work. Any browser that supports automatically filling a login form when you hit a page will be vulnerable to this. So it seems to me that what would make more sense is to put in a hotkey to 'auto-fill login forms' and only do so when the hotkey is pressed; the problem is that browsers blindly fill auto-login forms for a site without asking the user.
Why on earth do so many Slashdot posters seem to think it's about Mac fandom?
/Linux/ isn't immune to all threats past and present, after all... why should OS X somehow mystically be, /especially/ when some vulnerabilities can come from software (OpenSSH, Apache, etc.) which both operating systems share? Heck, if the vulnerability is in mDNSResponder, it may be in the UNIX implementations of zeroconf. (It's not as if the guy has given any information for someone to determine whether it is or not!)
It is far from impossible that there's a vulnerability in OS X; there have been vulnerabilities before, after all, and there will be again. Just because OS X is more secure in its out-of-box configuration than Windows is in its own out-of-box does not mean that OS X is completely invulnerable to all future threats. Heck,
Anyone who thinks OS X is somehow immune to all threats is a fool, or deliberately blinding themselves. But the issue people criticizing the guy generally seem to be pointing out is that regardless of the OS involved, this researcher has handled the vulnerability disclosure in an extremely unprofessional manner.
This 'researcher' makes a claim providing no proof. No details. He expects to be lauded for it, however, without providing any proof. Instead he finds himself criticized for not acting as an actual security researcher and handling the exploit disclosure in a professional manner; after all, he gave no details, he allowed no peer review, and he also said he wasn't releasing details or an exploit to Apple to look into fixing until he finished 'testing' it (which, at best, means he didn't even have the exploit confirmed for himself before he trumpeted it everywhere). So when he finds his claim challenged and he's told to send the info to Apple to fix it, or to at least reveal a little further info? Suddenly he claims he was getting death threats... equally unsubstantiated... and takes his ball to go home.
I'm not saying some devoted Mac fans might not have mailed nasty stuff to the guy; there are some crazy Mac fans. Though they're far from the only fanatics in the tech world. (The GPL diehards who attack other open-source licenses like rabid pit bulls, for instance, are definitely their spiritual kindred as far as fanaticism goes.)
But imagine this was with some other system:
Some guy posts, "I found an exploit in Ubuntu. It affects all current versions of Ubuntu, and can allow me to do some bad things. There's no current defense against it. Bow down before me!" Followed by a later post of, "No, I am not going report the exploit to the Ubuntu team. Or anyone else. Because I haven't finished testing it. Just shut up and marvel at my awesomeness for finding a difficult exploit." People would be up in arms, howling for the guy's blood about why he announced it if it's not confirmed, how it's probably a violation of some source license for him to not actually report the exploit to Ubuntu to be fixed if it's real, or whatever. If then a few days later he posted, "Oh, now I'm getting death threats, so this isn't worth it. I'm just not going to tell ANYONE what it is." people would be convinced he'd been faking it and was 'running away' to avoid having to actually produce something. (And no doubt some people would also still be posting 'Oh, you Ubuntu fanboys, why can't you believe there might be a vulnerability? Why do you have to send him death threats?')
It would be equally irresponsible to handle an exploit report in, say, Vista the same way. Though admittedly, there'd probably be less outcry, as we've become sort of inured to those reports. ("Huh. A vulnerability in Windows. Okay, whatever. Right, let's go for coffee.")
All most sensible folks are saying in this discussion is that if he's legit, this guy handled his situation Poorly. And given that there have been several poorly-handled exploit reports lately which turned out to either be hugely inaccurate ("Okay, this is only actually v
Ballmer would probably do the dirty work cheap ... just for the thrill of it all.
It's all about the assassins, assassins, assassins, assassins, assassins, assassins, assassins... assassins, assassins, assassins...
Oh, please. Most sensible Mac users recognize that while OS X is /more/ secure out-of-the-box than your average XP installation, and segments permissions better, there's still plenty of ways for things to mess up an OS X box. It's stupid to think any OS is invulnerable; Linux isn't, FreeBSD isn't, Mac OS X isn't, Windows sure as heck isn't. It's just harder to target an out-of-box configuration, and so people generally don't bother. (Which, I grant, doesn't mean some Mac users won't be up in arms and claiming this is impossible. They're wrong, if they do, but still.)
/proper/ way to handle a vulnerability -- on ANY platform -- is to report it to the vendor/developer in a timely manner before trumpeting it to the world. Exploits should be released (not leastwise because developers can learn from each others' mistakes), but they should be reported first. This
/because/ they handle exploit information in a professional and cooperative manner. This guy is not doing so, and THAT is the problem. Not what OS he's claiming an exploit in.
HOWEVER, you don't have to be a fan of any specific platform to find the way the guy handles this to be extremely unprofessional.
The
Meanwhile, this guy is proclaiming a vulnerability (but disclosing no details for anyone to learn from or judge the severity of), while simultaneously saying he has not yet -- and does not yet plan to -- report the vulnerability to the vendor. It's basically a shameless grab for publicity with vague information, rather than someone demonstrating that they take security research seriously.
The nature of the exploit, or the platform it affects, is not relevant to the guy's behavior; it's just plain irresponsible of any security researcher to act this way. It would be equally irresponsible to find some serious, significant exploit in Linux and trumpet 'ZOMG, I just discovered that there's a way for any program to steal root through a specific exploit in the current version of KDE! But I'm not going to tell the KDE folks anything about it until I've finished testing.' (Also, the guy would get eaten ALIVE by the Slashdot community for pulling a stunt like that, but I digress.)
Security researches are respected and taken seriously by vendors and developers (rather than being thought of as malicious hackers) specifically
That's my $0.02, anyway.
But it's not registering a domain name. The service that supposedly handles seamlessly swapping you between unlimited-use VoIP and your GSM cell plan /without even dropping calls/ as you switch is a service. It doesn't just work once, or even just (like dyndns) periodically get updated. It's an actual service you're using.
:)
Without knowing how that specific phone works, we can't really know whether or not it supports doing direct IP-based SIP connections (or even if it uses SIP behind the scenes). Just that it does WiFi-hosted VoIP when there's a hotspot.
That said, if you have a generic free-service VoIP phone that also works as a GSM cellular phone, I can't imagine you COULDN'T use it. T-Mobile's never stopped people from using unlocked O2 handsets or whatever, so a GSM/generic-SIP-VoIP phone would presumably work fine. It's not like T-Mobile controls all WiFi, after all! It just wouldn't do the seamless hopping between spots, or integrate with the new T-Mobile-supported routers from D-Link and LinkSys (which will automatically prioritize VoIP data when a call is going on, and which do a single WiFi ping rather than making the handset drain battery finding the WiFi network).
From what I've read on T-Mobile's plan, you're not somehow paying for otherwise-freely-available VoIP. You're paying for a system they engineered, which their handset supports. Nothing's stopping you from using some other VoIP WiFi handset.
I'm cheating 'cause I already saw the t-mobile ad. As I understand it, though, the T-Mobile WiFi handset actually does have a fairly significant added value over most generic WiFi SIP or Skype handsets.
With T-Mobile's proposed service, if you find a WiFi hotspot it automatically logs into a VoIP service provided by
The idea is that you just have one number, and those calling you don't need to know or care whether you're on a WiFi hotspot or out in cellular service areas. What you're paying for in their proposed service is not the network bandwidth, but a flat service fee for their VoIP system and related services.
Seriously, though, I think it's mostly just corporate philosophy. Windows looks primarily for scientists, engineers, and so on; a friend who was an artist/graphic designer at Microsoft said they felt very much a second-class citizen, and recommendations often didn't get really listened to. For years, Apple has recruited artists and creative sorts right alongside devs.
In fairness, I think this is changing a bit; Microsoft's learning that the front-end is as important as the back-end, and is rethinking things and has done things like hiring artists and photographers, or even more importantly, building XAML so that artists can actually design real UI instead of just mockups. Whether XAML changes the UI playing field as much as Microsoft hopes remains to be seen, though.
I agree that the phone is the main advantage from a technical standpoint. My point was more that different form-factors work differently for different people. :)
/could/ stuff it into a pocket of a jacket or purse, and it would handle both basic browsing /and/ phone in one device.
I like what I've seen of the N800 for mobile browsing from a technical standpoint, but despite the beauty of the large screen, it's too bulky for me. I have smaller hands than many gadgeteers do, and the N800 doesn't fit my hand nicely. Nor does it fit well into the pocket of any of my jackets, and so I have to admit if I had one, it would probably get left at the house most times. The iPhone, for instance, doesn't do nearly as wide a variety of things as the N800 does, but I
The N800 has far more impressive capabilities technically; it's just not a package that would be as-useful to me and my style of mobile computing, personally, as an iPhone-type device would be. (Whether or not that's the iPhone itself is not necessarily relevant to my point.)
I admit, from toying with one that a friend picked up, the N700/800 tablets look quite nicely usable. They do not, however, look like something I can slip into my purse, or the pocket of my jacket, for easy transport as a phone. (Especially as they need a Bluetooth phone to use for GPRS connectivity, and don't do normal GSM calling.)
I haven't taken the plunge and enslaved myself to AT&T for an iPhone, but I know that my desire for it is a tradeoff of several things. Windows Mobile just plain feels like I'm fighting with my PDA most of the times (I will spare you my rant on the astonishingly poor UI design of the Connection management screen in WM5), and most of the more-usable PDA-type devices are, like the N700, just too darn BIG to carry around conveniently for me, especially if I also have to carry a phone with me.
So all flashy 'woo' factor aside, the iPhone seems to have a very usable interface, do most of what I actually want from my PDA-phone (with, alas, the exception of IM... what were you THINKING, Apple?) and would fit in my jacket pocket much more conveniently. It's just that (ugh) AT&T requirement that's kept me from taking the plunge; T-Mobile's been fairly good to me.
I think no 'cross-platform' widget system will ever be a first-class citizen of the target OS beyond what it was developed for. Why?
Because things just simply work too differently. Look at Thunderbird; it's a great mail/news client... but on OS X, it does not integrate with the OS X system address book, nor does it support the system spellchecker's dictionary. There's a certain 'way' of doing things on any given OS, and if you try to write one single cross-platform UI (and I refer to overall user interaction here, such as the aforementioned spellcheck integration, not just the graphical aspect of the widgets), it will always feel a tiny bit 'wrong.'
I'm with a previous poster on this; you're better off separating the front-end from the back-end processing, and writing a native, OS-specific UI layer.
True, but the issue here is not GPL'd code, but LGPL'd (Limited GPL, or Library GPL) code. GPL means all your code must be open/released, or you cannot use the GPL'd code in your project; that's the situation you describe above. LGPL'd code can be linked in proprietary projects where the source is not available, but any *changes* you make to the LGPL'd code must be released/contributed back. The LGPL was originally created for libraries that should be usable in proprietary software, but which you don't want closed/proprietary forks of, but it's been used for other things as well.
In this case, it sounds as though SWSoft has taken LGPL'd code, modified it to do more stuff in some way and then used that for the 3d accleration support in Parallels 3.0... that's all fine, and Parallels itself doesn't need the source opened. But they have not contributed those changes to the actual LGPL code -- their own modifications, bugfixes, etc. -- back to Wine, and that is *not* okay under the license. So Wine wants the code contributed back, and SWSoft is stalling, which is the problem.
Even still, you can get a fair amount of noise if, say, you're doing concert photography or other no-flash-allowed low-light photography with a DSLR. My EOS 400D is a great camera, but it's a pain to shoot ISO 1600 with it unless I either have my f/1.8 wide-aperture lens on there or plan to spend a lot of time in post removing noise artifacts. My friend's EOS 5D, unsurprisingly, handles low-light shots far better than my 400D does, no doubt in part because of its own sensor being larger than that on the 400D.
:)
So there's still room for improvement in DSLR sensors... though as to whether or not this is some magical miracle solution to low-light photography remains to be seen.
Not having heard the keynote itself but just poking through summaries, as I understand it the /underlying frameworks/ and various tools have been made both 32-bit and 64-bit. Thus, if you have 64-bit hardware, then you can use 64-bit addressing and thus handle a great deal more memory without issue, while hybrid binaries would still work on 32-bit.
So it sounds to me like what they are giving is one install for all the different hardware, which will take advantage of 64-bit stuff if you have it (for allowing media programs to work with far more memory than they can if kept purely 32-bit) without making the consumers worry about which version of Leopard or which version of a binary they need. I've seen nothing to imply that binaries built for a purely 64-bit-architecture will magically work on 32-bit hardware.
Offtopic here, but that's generally a really severe pressure that game developers get from their publishers, unfortunately. It's particularly severe there; it is not as if you have 'Electronic Wordprocessor Monthly' grading the latest import productivity apps, and raising the hype on them all.
("Capcom ExpenseBlaster 3 Turbo gets an 8/10 for the blazing next-generation way it lets me balance my checkbook!" "I'm sorry, but this one felt lacking to me. It was anemic in terms of features, especially compared to other contenders like Rockstar's 'Grand Theft Accounting,' and the money-laundering options. Only a 4/10.")
That doesn't stop people from proclaiming doom and gloom and trying to point out alternative software if non-game products slip, of course. Which means more than game developers get the market pressure to just 'get a 1.0 app out there, and patch it later,' albeit a bit less than game developers do. Which sucks, but... the cause of this one unfortunately lies with both the developers and consumers, I think.
No. But put it this way...
Let's say there's something built atop an open source library. Hey, there's plenty of them out there... let's pick OpenSSL as an example. It's open source and it's used in other projects, some of which are commercial or proprietary systems. Now assume that some company makes a proprietary, closed product built on that project as the core, but continue to contribute changes -- a heck of a lot of changes -- back to the original project as the develop. And then they release this as a beta.
Finally, let's say that someone finds a vulnerability in the proprietary project, a security issue with implications for the open source project. And instead of reporting the vulnerability to the proprietary folks (who would probably promptly generate a patch for both their tool and the underlying library, the person refuses to report the vulnerability to anyone and just says 'I found vulnerabilities, but I'm not telling you what they are.'
That's basically how WebKit/KHTML and Safari are tied together. Safari's just a UI atop an open source framework, WebKit, which Apple is the primary contributor to but which other people also contribute to, and which other projects (besides Safari and OS X) use. WebKit is used on Symbian OS, on Linux, and various other operating systems. And this guy is claiming to have found vulnerabilities which, given where they occur, seem to have implications for WebKit as well as Safari... and is refusing to give the details to either Apple, or to the WebKit development community.
You don't have to be an Apple 'fanboi' (or fangirl) to see that's not the way to handle security disclosures. If someone found several bugs in Firefox and said 'ZOMG I can crash Firefox or anything which uses the Gecko HTML engine. I can do it 100% of the time. But I'm not going to report the details to the Firefox team, so, nyah!' people would be up in arms about it.
Professional, good security researchers report things to the responsible parties, giving them the details necessary to fix it. Going, "Ha ha, I found a way to break your stuff but I'm not going to tell you how" is not only unprofessional, it's just downright immature.
Sure, lambaste Apple for releasing a beta/preview of something with bugs if you feel you must. But, please, don't bother trying to defend someone who basically makes a mockery of the entire security field.
Not to mention that aside from WebKit, which the parent poster points to, or the zeroconf standard (which Apple helped to write), they've also contributed a lot of code to another open source project in particular. It's called the GNU Compiler Collection, or GCC for short. You might have seen it around on a Linux box or two, even. ;)