Bundles and resource forks have nothing in common.
Incorrect, resource forks and bundles have one /big/ thing in common: To take resources that an app or library uses, and bundle them together in a way that is opaque or 'hidden' to the end user. Strings, UI elements, images, and more are stored by resource forks in the old OS 9 world, and in bundles in the OS X world. They serve the same purpose, with the exception that bundles are FS-neutral.
A variant available under a license other than the GPL is a big one. As XNU isn't under the GPL, there are plenty of legal issues of mixing GPL drivers with ASPL drivers and kernel. This is really what prevents competent FSes from showing up on OS X from the OSS world.
But beyond that, you look at what is available under a BSD license that is more compatible with the ASPL, and there isn't a whole lot. Apple pretty much already supports it, unless the version under BSD is extremely old.
But technically, I suppose there isn't a whole lot of difference these days. Ext3, ReiserFS, and HFS+ all are optimized towards different problems, but essentially offer the same thing. The only thing HFS+ has over them is resource fork support, and a slightly different list of unacceptable filename characters.
Nothing in the default OS X install's BSD layer is resource fork aware. The cpmac and mvmac commands talked about in the post I responded to was included in XCode, and only if you set your path because you needed it. Apple has been pushing people to move from CFM+Resource Fork apps for awhile and towards Mach-O executables in bundles... but companies like Adobe and Microsoft take awhile to migrate.
Things like the resource fork aware ZIP archives are done above the zip command. zip itself is not resource fork aware.
If you are familiar enough with how the BSD guys do things, you already know what VFS is. It is BSD's own method of abstracting FS drivers away from the general FS logic of the OS. The catch here is that Apple has modified this so resource forks can still function. But in the end, VFS is brand new for 10.4.
It has? An example please.
SVN, Apache, OpenSSH/OpenSSL, and even mainline GCC (rather than Apple's fork which contains all their patches) all build out of the box on 10.4 without patches. The trick to getting these apps to install is dealing with version dependancies on 10.4, which is a much simpler problem than the incomplete POSIX implementation of 10.3 and earlier. 10.4 is still incomplete, but complete enough for most applications.
1. It isn't even released yet.
2. Linux isn't certified. I doubt FreeBSD is certified.
3. Parts of versions of Microsoft Windows are certified.
4. That certification means nothing.
True that neither Linux or FreeBSD are certified, mostly because neither project would dare spend that sort of money on a certification.
But the certification doesn't mean nothing, what it does mean is that if you have an app written against POSIX, using compliant versions of make/etc... you should be able to take it to any certified platform and just build it.
It exaggerates the problem by claiming the problem is more widespread than it is. It acts like Apple customizes every little thing that comes across, when they don't. However, there is a problem with these long release cycles using OSS software that moves extremely fast compared to the big box software devs.
Yes we know. X is Not Unix. But that's not a requirement - it's a mistake.
Maybe they should change the name, X is Unix now.
That's their problem - not the users' problem. If they want to do things that way they have to accept the consequences. Users shouldn't have to suffer.
Which they should be addressing with prompt patches, yes... but the cost of boxed software releases and QA means they have to recoup on it. OSS uses an entirely different release model than any commercial software. Both have advantages and disadvantages, but your subtle claim that one is always better than the other is false.
This sounds like a really lame excuse for the iPhone exploit. Shame on you.
I wasn't aware the iPhone exploit used Perl... explain further.
But really, it is a fact of development on closed platforms. Developers do NOT like the rug being pulled out from under them on patch updates. This is something Microsoft knows, and takes to an extreme. While I agree that patches must get issued, upgrading software that is part of the platform also has the chance to break software. With how apps broke at 10.3, or 10.4... do we want to have that same experience at 10.3.3, or 10.4.2?
Patch, yes... jump major revisions? That major revision BETTER work just like the previous one or it is just gonna be disaster.
Yup, you are right on this one... While I see some things that appear to be in common, one is not a superset of the other.
But again: that is APPLE's problem. You're trying to encourage people to have pity on Apple for this.
Please don't put words in my mouth. I am explaining the situation as I see it. People can take it or leave it as they see fit. I am just tired of evangelicalism that Apple isn't going far enough in adopting the holy OSS path, or that Apple is an evil devil out to consume our souls.
They are a group of programmers working for a goal. They will make mistakes... as does the OSS crowd. If we want to get into what makes Apple piss /me/ off, it is the sheer lack of transparency that bugs me. Microsoft does a better job being transparent to developers than Apple by a huge long-shot.
You mean like the Leffler/Atheros drivers? Yes they do. Apple's driver is remarkably similar to the Leffler/Atheros driver, isn't it? Just a few missing buffer overrun tests...
I was referring to that particular driver... but without an accurate disassembly/etc, it is impossible to know when it forked from the original source, and if it was the fault of an Apple engineer in writing the driver, or maintaining it after the fork.
The root cause of this particular problem is that IOKit, while a really, really nice driver development platform, isn't compatible with BSD/etc. So Apple was negligent in their duties on forking a driver, not that they intentionally removed code from a driver.
Truth is lame. Everyone screws up somewhere when writing code. The trick is to fix it quickly when someone (including yourself) finds it. OSS is completely transparent about this process, Apple isn't. People like transparency, and so while OSS looks good for being transparent on this... Apple looks like a demon because they won't say anything or tell you when they patched it without digging through KB notes.
Both are just as human. Humans make mistakes... but better ones /do/ own up to it.
But there are more installations of FreeBSD than Linux. Add the other BSDs to that. The FreeBSD people do this and only this. That's what's so good about it. But Apple do it too - that's reinventing the wheel for reasons you can't enumerate evidently - much less defend.
I can't enumerate or defend decisions I didn't make except for what I see as good aspects for it. However, as someone who has tried to develop a driver at one point in OS X... I like IOKit over what is available elsewhere. That combined with the Mach back-end are arguably strengths of the platform, rather than weaknesses, especially as we go into an SMP world. However, from your definition of what makes a strong platform they probably aren't in your eyes.
Every approach has strengths and weaknesses, and if your priorities are different than Apple's, then you will see Apple's approach in a different light. Not that this is a bad thing, but it isn't like Apple took their approach out of incompetence either. They had goals which their design grew from. Plus, XNU isn't entirely reinventing the wheel when it is a tweaked Mach kernel with a BSD personality on top provided by FreeBSD.
Right. So it makes a LOT of sense to just use the FreeBSD layer like NeXT always did - unless of course you can come up with a REALLY GOOD REASON to not do it?
No good reason /not/ to do it. I like the approach. But as you yourself try to point out, you still have to maintain it. It isn't as if Apple would get a free pass if XNU was replaced with OpenBSD's kernel, would it?
You're looking at it backwards. You're assuming they'd otherwise build their own OS. History lesson: they already tried that. It was called Copland. It tanked. Like a BOMB.
Waste is being calculated as compared to alternatives. Apple when making OS X had the requirement of being backwards compatible to /some/ extent with OS 9. It isn't like their alternative was to use an uncustomized kernel and BSD environment... their alternative /was/ to write it from scratch.
The big problem with Copland is not that Apple tried to write it, but they had a big dream fantasy pitched to execs who bought into it and didn't realize how unrealistic the plan was. The plan was to take System 7 and create Copland from it, with FULL backwards compatibility. The failure was that: 1) System 7 could not be extended in the way they planned, 2) Backwards compatibility while moving to a fully multitasked environment is /hard/. Especially when these apps are running natively.
Rhapsody's Blue Box, Carbon, and other technologies present in Tiger are partially a result of learning from the mistakes of Copland.
