When BeOS came along I looked at it and said "they're trying to be Amiga, and they've got less going for them".
Amiga had two things that will probably never be repeated:
1. The OS was generations ahead of its peers. The real competition was a bunch of file loaders that weren't significantly different from early '60s program loaders for punch card systems... you load a program, it takes over the system, and calls simple utility routines that must run to completion before returning to the application. The other GUI systems were basically GUI libraries that maintained some graphic system state and ran on top of the same kind of simple file loader. AmigaOS was exceptional because it was actually pretty close to professional realtime systems... the only other personal computer with anything close even as an option was the Radio Shack color computer with the optional OS/9.
2. The hardware could do something significantly better than any of its peers. The Amiga graphics coprocessors weren't insanely great, but they gave it a wedge that got people to take it seriously enough to give it a chance. If the Color Computer had a 68000 and a blitter instead of a 6809 and a raster buffer, Commodore would have had more of a problem.
10 years later, everyone except Apple had real operating systems in place or in the works, and BeOS wasn't that far ahead of the pack in any area... and not necessarily ahead of any of them - there's some real design problems in BeOS that have bugged me every time I looked at it. And their hardware wasn't a killer box in any respect either.
So to me, the Amiga was already doomed, and BeOS was born doomed. It was trying to pull an Amiga, with less money, fewer resources, and no footholds to let it get started even if they HAD gotten a completed system and OS with everything working (networking never became stable) before they flamed out.
I'm not talking about a failure related to me inserting the iPhone into my anus. Its a bad battery, and they should honor their warranty.
And I'm not talking about what they SHOULD do. If the device is defective, they probably SHOULD repair or replace it.
That doesn't mean they MUST repair or replace it.
They aren't required to do anything they haven't agreed to do, and if they haven't agreed to perform any warranty work at all on devices that have been physically damaged by the customer, they aren't actually required to.
This doesn't mean that something other than the warranty might not come into play. Product recalls, for example, are not warranty support. And there are specific and fairly narrow legal restrictions about what warranties are allowed to exclude. Whether this situation is one of those cases or not is going to have to be decided in the courts.
But since there's no anal insertion exception, nor is there an iPhone battery recall in place, that wouldn't apply in the hypothetical situation that the OP presented. If you've voided your iPhone, and Apple has said that voids your warranty, then you're entitled to consider their warranty support inadequate but you can't actually compel them to honor it.
(1) They wouldn't be going to a "plain filesystem". They've already extended UFS for multiple forks, so the argument that they need HFS+ because a traditional UNIX file system isn't "good enough" is moot.
(2) The fact that people are using HFS+ for demanding tasks doesn't mean that HFS+ is needed for those tasks or even that HFS+ is necessarily well suited to them.
(3) Historically, embedding application level metadata in the file system has had at best mixed results. It's occasionally good for OS manufacturers if applications are dependent on OS-specific features, but it's not necessarily good for the users or developers, and it makes it hard to adapt to new technologies. There's a reason that complex file types have increasingly been replaced by UNIX flat files and "smarts" get moved back to the applications.
So while there may well be technical advantages to staying with HFS+ to maintain application-level metadata in the file system, that doesn't mean it's necessary or that maintaining application-level metadata there is even the right thing to do. Given that the cost of using HFS+ is that the file system is unstable in the face of normal file activity... you don't even need to have hardware problems or hack on the file system below the driver level to trash the catalog... I think that Apple needs to either fix HFS+ properly or abandon it. There is nothing they could write that would justify retaining it in its current form, because there's no justification for ignoring a known flaw that can so easily lead to irrecoverable file system corruption.
Finally, regarding this article, let us say that it's entirely possible for competent people of good will to disagree on issues such as this, and this particular one has proven particularly polarizing.
I mean, if after I buy it I can do whatever I want, even use it in an unforeseen way... they shouldn't care.
They don't care. Right up to the point where you try and get them to pick up the tab for fixing it after you do whatever you do with it.
That's all warranty support means, after all. You're entitled to smash your iPhone with a hammer, but don't expect them to replace it afterwards.
Some companies have great warranty support. I prefer to patronize Sears after a couple of cases where they went WAY out of their way for me... far beyond what I'd ever expect... and there's companies I won't name that I will never do business with again after they went out of their way to get OUT of supporting a defective product.
Apple's warranty support hasn't been great, but it's been adequate, and I'm glad I got Applecare for my Macbook.
The question of whether Apple's deliberately bricked people's iPhones and whether that's legal is a whole different matter from whether your anally inserted iPhone is entitled to warranty support.
The point is that in the UFS extensions they've already done, and in the vnode layer, they already have the tools to perform all the transitions necessary to make the underlying file system behave the same way whether it's UFS, HFS+, or ZFS underneath.
They have chosen not to do so.
That is, they don't consider the problems in HFS+ sufficient to make it worth the effort of even making it possible to switch away from it.
I've had this bite me three times already, so I hope you understand why I don't agree with them.
Can I suggest not filling your drive up completely with porn and movies and music or whatever else you are filling up the drive with
You can suggest it, and I can suggest that you keep your damn hands off my porn.
HFS+ has a problem when more blocks need to be allocated for the catalog and there are no blocks which can be used, it ends up with files and catalog sharing blocks and the catalog getting destroyed catastrophically.
I know. I consider that completely unacceptable behavior from a file system.
It could be fixed but it looks sufficiently annoying that they would rather have it occasionally fail instead of messing with it.
Which is why I would rather use a file system designed by people who give a damn about file system reliability.
In 20 years working with Unix and Unix-like systems I have had several UFS filesystems be unrecoverable with fsck.
I've never had that happen for a file system that wasn't so trashed it couldn't even be mounted readonly. If there's a file system there, FSCK will get everything out of it that it can, and it'll put everything it can't link into lost+found, and when it's done that file system is clean.
I'm not saying that other file systems (like ZFS) can't be as good, I'm saying that there WAS a legitimate reason to go to UFS if Apple had actually cared about file system stability and reliability. As you noted, they don't.
Which brings me back to my original point, that just because Apple's providing support for ZFS, don't assume that they'll actually make it into something that can be used as a replacement for HFS+ on the desktop.
My point wasn't "UFS pwns ZFS"... that was an aside. It's "there's a legitimate reason to want to use UFS on a desktop or laptop Mac, and Apple made a big deal about the improved UFS support in Panther, and they ended up not going anywhere with its, so don't depend on them going anywhere with ZFS either".
BTW, and this is (still) just an aside... I know about the difference between log based file systems and journalled file systems... I read the Sprite papers, I've installed several NetAPPs, and I know the advantages of treating the journal/log as the primary storage and checkpointing references to active metadata. I would still like to know that the file system has a tool to dig through that mess and rebuild all the metadata that it can and actually repair the thing if worst comes to worst.
Don't know, mate, I'm not the one moaning that I need insane resolution and screen size from an eBook reader. If you need a frigging laptop screen before you're willing to read digital books, I don't think you really need an eBook reader at all.
Meanwhile there's enough people like me to keep Fictionwise and Webscriptions in business.
Most 'Pocket'books don't fit in my pockets either.
If you wear tight-fitting trendy jeans, no, but it can be a challenge carrying a cellphone in jeans pockets sometimes.
If you wear slacks, or a jacket, or any other kind of clothes designed for comfort, you can easily fit a standard paperback in your pocket. This doesn't mean you carry them there all the time, but it means that if you ARE carrying a book you can stick it in your pocket when you need two hands for other things, instead of juggling it under your arm.
So that means you simply never read plain-paper books?
Actually, there's a germ of reality there. It means that I can read something other than price tags when I'm waiting in line, and in an office I don't have to put up with a choice of "Sports Illustrated" or "Weekly Accounting Adventures" or "Embarassing Photographs of Medical Problems Daily" like I used to.
Maybe it's the way raytracing is mysteriously "within a few years" every year?
Except it isn't. Real Time raytracing was "at least 20 years off" when the first raytraced images showed up in the late '70s (and took 10 hours per frame on a VAX), and they were "at least 20 years off" throughout the '90s, and even this century, right up to, oh, about 2005... when Philipp Slusallek at Saarland University demonstrated real-time raytracing on a 66 MHz FPGA with about 1% of the gate budget of a modern video card at SigGraph 2005.
So do you mean it's been "within a few years" for the last couple of years? I mean, now even Intel and ATI and nVidia are talking about real-time raytracing and working on putting raytracing accelerators in video cards. They're not going to a full SaarCOR-style RPUs yet, but it's only a matter of time.
I assume the better the rasterizer gets, the more rays and more bounces you'd have to trace to get a better image so it's a moving target.
That's just it... as the scene gets more complicated raytracers scale up much more efficiently than rasterizers. Raytracing is much less sensitive to absolute polygon counts than rasterizers, and some actually operate directly on NURBs instead of a mesh.
Are you certain about [the spotlight hooks being in HFS+]?
Pretty certain.
They use the fsevent mechanism in the vnode layer for some of it, and the application-level stuff should work on any file system because that's not actually in the file system... it's in the.Spotlight-V100 subdirectory along with the indexes created by mdimport, but the extensions they created to speed up searching and indexing by tracking metadata in file system reads and writes is apparently all inside HFS itself.
I thought they they'd work off vnode operations too, esecially since the indexes are in a regular file tree, and I speculated that they'd be doing that before release... and got "authoritatively corrected".:)
Is their support for UFS better now? The last time I used OS X (v10.2) their support for UFS was crap.
It got a lot better in Panther with the import of FreeBSD's latest UFS, though they never implemented even as much metadata support as they fake in foreign network filesystems. They didn't go anywhere with it, either.
Like you I wanted to use UFS to get away from the "PC-quality" HFS+, but no dice... so I'm really dubious about them doing anything for desktop users with ZFS. I suspect it's only going to be useful, if at all, for folks using XServes.:(
I don't think UFS using community would be happy about Spotlight anyway.
I'm an old-school UNIX guy who qualifies as part of "the UFS-using community" and Spotlight is Tiger's "killer app" for me.
Apple already implemented support for resource forks and almost all the other metadata in HFS+ in arbitrary file systems. Yes, if you go down to the command line you can see some of that metadata exposed at that level. But that's the way it should be... if you're working at that level you need all the data to be enumerable through the normal file system operations. At the Finder and application level, you don't see any of that... you don't see the "._" files and you don't see ".rtfd" and ".app" and ".pages" bundles as directories.
Apple's even using these tricks to apparently add features to HFS+: most spotlight metadata, for example, is stored in a regular file, and bundles are still implemented as folders. They even implement aliases in HFS+ on OSX using a real secondary directory tree, presumably because the vnode layer in UNIX won't work any other way!
They've also extended UFS to handle the most critical parts of their dual-fork model inside the file system... but they've stopped short of completing the job. They could do the rest of it, for UFS or for ZFS, if they wanted to... after all, HFS+ on OSX really *is* using these tricks too.
True, but the capabilities of UFS don't really exceed HFS+
In one way, at least, UFS is far better than HFS+.
The internal redundancy in UFS means that so long as the basic file system structures (directories, inodes, and indirect blocks) are intact, it can be repaired. The idea of having file system damage in a bootable file system that can't be repaired by FSCK is all but inconceivable for UFS or any of its precursor file systems. In nearly 30 years working with UNIX, once FSCK was introduced I *never* had a file system so damaged that FSCK couldn't completely restore the structure to working order. Three times now I've had HFS+ file systems require a backup and restore because of some obscure damage that even rebuilding the catalog wouldn't fix. A friend of mine is currently booting his Mac Pro off the second drive because the original installed file system was trashed.
ZFS claims "you'll never have to fsck again". That's what every journalled file system proponent says. That's what they said about XFS... until they came back with tools to do repair and you still had to reinstall to recover sometimes. I'll believe it when I've seen it in practice for a decade or so. What does ZFS do when it hits unrecoverable data in the file system structure itself?
UFS's fsck deals with it by rebuilding the file system structures so that they're valid, and tells you what you lost.
HFS+ tells you that you have some obscure catalog problem and you go out and buy DiskWarrior and hope your backups are in good shape.
XFS apparently gives you a chance to do a final backup.
What does ZFS do? The write-ups on ZFS indicate that they stop short of testing that case, and that's the most important one.
They made a big deal about the import of the latest UFS from FreeBSD in Panther, and their support for UFS was actually reduced in Tiger because they put the Spotlight hooks into HFS+ instead of using the hooks already in the vnode layer in Darwin.
So don't do anything that would depend on them supporting ZFS.
Most PDA's don't have the high-resolution displays of good dedicated eBook readers or the XO
Most dedicated eBook readers are bigger than a hardcover, far too big to slip into your pocket. And my Clie has at least the same resolution as the good eBook readers I've seen, it just has a smaller screen... about half the size of a page of a paperback.
IMO, most PDA's don't make good e-Book readers.
IMO, most eBook readers don't make as good eBook readers as PDAs do. Being able to fit into my pocket is for me a non-negotiable feature, and something the size of a hardback book doesn't qualify.
A lot of the "improvements" are things that the game is doing differently in the DX9 and DX10 versions. Some of them, like the "litter objects" in one of the games, or gun movement effects in another, have nothing to do with DX10... it's like the game developers simply put more polish in the DX10 versions because they wanted the punters to "get their money's worth".
That said... let me contradict myself a bit.. what does a Mac have that Linux does not?
Applications.
What I want to know is why are you presenting this as Mac vs Linux?
UNIX is UNIX is UNIX. Linux is UNIX. OS X is UNIX. You get on any UNIX box, you have the same basic environment, you have all the open source software, you have the timesharing system developed in a hostile environment where security matters (when you have CS students and CS professors on the same computer, and you have to keep the students out of the professor's files, and the professor's grants are paying your salary, you take security seriously). It's the same system.
Free UNIX is cheaper and more versatile. Macs have the apps. Use whichever you want. Use both. They do the same stuff.
I switched to Mac from free UNIX because I was tired of being mister system administrator at home as well as at work, and tired of dual-booting Windows to run apps. And I didn't give up anything when I did it. But my home server is still the same open source box, because that's not the Mac's strength. It's a win win situation... why fight?
Who cares about cool special effects to fake optical accuracy? Within a few years we'll have real-time ray tracing and everything using rasterized graphics will look so fake.
get a solid, first part DirectX compatibility layer of some sort into OS X.
Not only "no" but "hell no".
DirectX only exists because Microsoft wanted a graphics standard they controlled that wasn't OpenGL, so they could use it to bone competitors. If you think OpenGL is a problem for Apple, having to implement DirectX to Microsoft's satisfaction would let Microsoft feed them the bone harder than you can possibly imagine.
You mean the CPU that's in the XBox 360? That doesn't seem to be hurting Microsoft. Next ?
Those crappy intel GMA950 chips Apple is so enamored with don't even support all of the shaders the GUI needs
Now that one's a legitimate complaint... but all the PPC-era Macs had full 3d-capable video cards, while PC motherboards and Wintel laptops usually didn't.
I'm just saying that stallman is right with his distinction between "open" and "free"
You're spreading FUD about open source, playing on some slashdotter's mistake..nets source may be "opened"
Because.NET SOURCE IS NOT "OPENED", and it's not "FREED" either, even though the person who wrote the headline could have written ".NET libraries are 'freed'" with about as much justification.
Slashdot Mirror
Your mirrors seem to be 404 compliant.
When BeOS came along I looked at it and said "they're trying to be Amiga, and they've got less going for them".
Amiga had two things that will probably never be repeated:
1. The OS was generations ahead of its peers. The real competition was a bunch of file loaders that weren't significantly different from early '60s program loaders for punch card systems... you load a program, it takes over the system, and calls simple utility routines that must run to completion before returning to the application. The other GUI systems were basically GUI libraries that maintained some graphic system state and ran on top of the same kind of simple file loader. AmigaOS was exceptional because it was actually pretty close to professional realtime systems... the only other personal computer with anything close even as an option was the Radio Shack color computer with the optional OS/9.
2. The hardware could do something significantly better than any of its peers. The Amiga graphics coprocessors weren't insanely great, but they gave it a wedge that got people to take it seriously enough to give it a chance. If the Color Computer had a 68000 and a blitter instead of a 6809 and a raster buffer, Commodore would have had more of a problem.
10 years later, everyone except Apple had real operating systems in place or in the works, and BeOS wasn't that far ahead of the pack in any area... and not necessarily ahead of any of them - there's some real design problems in BeOS that have bugged me every time I looked at it. And their hardware wasn't a killer box in any respect either.
So to me, the Amiga was already doomed, and BeOS was born doomed. It was trying to pull an Amiga, with less money, fewer resources, and no footholds to let it get started even if they HAD gotten a completed system and OS with everything working (networking never became stable) before they flamed out.
I'm not talking about a failure related to me inserting the iPhone into my anus. Its a bad battery, and they should honor their warranty.
And I'm not talking about what they SHOULD do. If the device is defective, they probably SHOULD repair or replace it.
That doesn't mean they MUST repair or replace it.
They aren't required to do anything they haven't agreed to do, and if they haven't agreed to perform any warranty work at all on devices that have been physically damaged by the customer, they aren't actually required to.
This doesn't mean that something other than the warranty might not come into play. Product recalls, for example, are not warranty support. And there are specific and fairly narrow legal restrictions about what warranties are allowed to exclude. Whether this situation is one of those cases or not is going to have to be decided in the courts.
But since there's no anal insertion exception, nor is there an iPhone battery recall in place, that wouldn't apply in the hypothetical situation that the OP presented. If you've voided your iPhone, and Apple has said that voids your warranty, then you're entitled to consider their warranty support inadequate but you can't actually compel them to honor it.
(1) They wouldn't be going to a "plain filesystem". They've already extended UFS for multiple forks, so the argument that they need HFS+ because a traditional UNIX file system isn't "good enough" is moot.
(2) The fact that people are using HFS+ for demanding tasks doesn't mean that HFS+ is needed for those tasks or even that HFS+ is necessarily well suited to them.
(3) Historically, embedding application level metadata in the file system has had at best mixed results. It's occasionally good for OS manufacturers if applications are dependent on OS-specific features, but it's not necessarily good for the users or developers, and it makes it hard to adapt to new technologies. There's a reason that complex file types have increasingly been replaced by UNIX flat files and "smarts" get moved back to the applications.
So while there may well be technical advantages to staying with HFS+ to maintain application-level metadata in the file system, that doesn't mean it's necessary or that maintaining application-level metadata there is even the right thing to do. Given that the cost of using HFS+ is that the file system is unstable in the face of normal file activity... you don't even need to have hardware problems or hack on the file system below the driver level to trash the catalog... I think that Apple needs to either fix HFS+ properly or abandon it. There is nothing they could write that would justify retaining it in its current form, because there's no justification for ignoring a known flaw that can so easily lead to irrecoverable file system corruption.
Finally, regarding this article, let us say that it's entirely possible for competent people of good will to disagree on issues such as this, and this particular one has proven particularly polarizing.
I mean, if after I buy it I can do whatever I want, even use it in an unforeseen way... they shouldn't care.
They don't care. Right up to the point where you try and get them to pick up the tab for fixing it after you do whatever you do with it.
That's all warranty support means, after all. You're entitled to smash your iPhone with a hammer, but don't expect them to replace it afterwards.
Some companies have great warranty support. I prefer to patronize Sears after a couple of cases where they went WAY out of their way for me... far beyond what I'd ever expect... and there's companies I won't name that I will never do business with again after they went out of their way to get OUT of supporting a defective product.
Apple's warranty support hasn't been great, but it's been adequate, and I'm glad I got Applecare for my Macbook.
The question of whether Apple's deliberately bricked people's iPhones and whether that's legal is a whole different matter from whether your anally inserted iPhone is entitled to warranty support.
I've been there and got the t-shirt too.
The point is that in the UFS extensions they've already done, and in the vnode layer, they already have the tools to perform all the transitions necessary to make the underlying file system behave the same way whether it's UFS, HFS+, or ZFS underneath.
They have chosen not to do so.
That is, they don't consider the problems in HFS+ sufficient to make it worth the effort of even making it possible to switch away from it.
I've had this bite me three times already, so I hope you understand why I don't agree with them.
Can I suggest not filling your drive up completely with porn and movies and music or whatever else you are filling up the drive with
You can suggest it, and I can suggest that you keep your damn hands off my porn.
HFS+ has a problem when more blocks need to be allocated for the catalog and there are no blocks which can be used, it ends up with files and catalog sharing blocks and the catalog getting destroyed catastrophically.
I know. I consider that completely unacceptable behavior from a file system.
It could be fixed but it looks sufficiently annoying that they would rather have it occasionally fail instead of messing with it.
Which is why I would rather use a file system designed by people who give a damn about file system reliability.
In 20 years working with Unix and Unix-like systems I have had several UFS filesystems be unrecoverable with fsck.
I've never had that happen for a file system that wasn't so trashed it couldn't even be mounted readonly. If there's a file system there, FSCK will get everything out of it that it can, and it'll put everything it can't link into lost+found, and when it's done that file system is clean.
I'm not saying that other file systems (like ZFS) can't be as good, I'm saying that there WAS a legitimate reason to go to UFS if Apple had actually cared about file system stability and reliability. As you noted, they don't.
Which brings me back to my original point, that just because Apple's providing support for ZFS, don't assume that they'll actually make it into something that can be used as a replacement for HFS+ on the desktop.
My point wasn't "UFS pwns ZFS"... that was an aside. It's "there's a legitimate reason to want to use UFS on a desktop or laptop Mac, and Apple made a big deal about the improved UFS support in Panther, and they ended up not going anywhere with its, so don't depend on them going anywhere with ZFS either".
BTW, and this is (still) just an aside... I know about the difference between log based file systems and journalled file systems... I read the Sprite papers, I've installed several NetAPPs, and I know the advantages of treating the journal/log as the primary storage and checkpointing references to active metadata. I would still like to know that the file system has a tool to dig through that mess and rebuild all the metadata that it can and actually repair the thing if worst comes to worst.
I think the answer would be "yes", if they decide that inserting it where the sun don't shine voids their warranty because of customer abuse.
Would they BE right? I don't know, but they certainly HAVE the right.
But... why do you think we care?
Don't know, mate, I'm not the one moaning that I need insane resolution and screen size from an eBook reader. If you need a frigging laptop screen before you're willing to read digital books, I don't think you really need an eBook reader at all.
Meanwhile there's enough people like me to keep Fictionwise and Webscriptions in business.
Most 'Pocket'books don't fit in my pockets either.
If you wear tight-fitting trendy jeans, no, but it can be a challenge carrying a cellphone in jeans pockets sometimes.
If you wear slacks, or a jacket, or any other kind of clothes designed for comfort, you can easily fit a standard paperback in your pocket. This doesn't mean you carry them there all the time, but it means that if you ARE carrying a book you can stick it in your pocket when you need two hands for other things, instead of juggling it under your arm.
So that means you simply never read plain-paper books?
Actually, there's a germ of reality there. It means that I can read something other than price tags when I'm waiting in line, and in an office I don't have to put up with a choice of "Sports Illustrated" or "Weekly Accounting Adventures" or "Embarassing Photographs of Medical Problems Daily" like I used to.
Maybe it's the way raytracing is mysteriously "within a few years" every year?
Except it isn't. Real Time raytracing was "at least 20 years off" when the first raytraced images showed up in the late '70s (and took 10 hours per frame on a VAX), and they were "at least 20 years off" throughout the '90s, and even this century, right up to, oh, about 2005... when Philipp Slusallek at Saarland University demonstrated real-time raytracing on a 66 MHz FPGA with about 1% of the gate budget of a modern video card at SigGraph 2005.
So do you mean it's been "within a few years" for the last couple of years? I mean, now even Intel and ATI and nVidia are talking about real-time raytracing and working on putting raytracing accelerators in video cards. They're not going to a full SaarCOR-style RPUs yet, but it's only a matter of time.
I assume the better the rasterizer gets, the more rays and more bounces you'd have to trace to get a better image so it's a moving target.
That's just it... as the scene gets more complicated raytracers scale up much more efficiently than rasterizers. Raytracing is much less sensitive to absolute polygon counts than rasterizers, and some actually operate directly on NURBs instead of a mesh.
Are you certain about [the spotlight hooks being in HFS+]?
.Spotlight-V100 subdirectory along with the indexes created by mdimport, but the extensions they created to speed up searching and indexing by tracking metadata in file system reads and writes is apparently all inside HFS itself.
:)
Pretty certain.
They use the fsevent mechanism in the vnode layer for some of it, and the application-level stuff should work on any file system because that's not actually in the file system... it's in the
I thought they they'd work off vnode operations too, esecially since the indexes are in a regular file tree, and I speculated that they'd be doing that before release... and got "authoritatively corrected".
Is their support for UFS better now? The last time I used OS X (v10.2) their support for UFS was crap.
:(
It got a lot better in Panther with the import of FreeBSD's latest UFS, though they never implemented even as much metadata support as they fake in foreign network filesystems. They didn't go anywhere with it, either.
Like you I wanted to use UFS to get away from the "PC-quality" HFS+, but no dice... so I'm really dubious about them doing anything for desktop users with ZFS. I suspect it's only going to be useful, if at all, for folks using XServes.
I don't think UFS using community would be happy about Spotlight anyway.
I'm an old-school UNIX guy who qualifies as part of "the UFS-using community" and Spotlight is Tiger's "killer app" for me.
Apple already implemented support for resource forks and almost all the other metadata in HFS+ in arbitrary file systems. Yes, if you go down to the command line you can see some of that metadata exposed at that level. But that's the way it should be... if you're working at that level you need all the data to be enumerable through the normal file system operations. At the Finder and application level, you don't see any of that... you don't see the "._" files and you don't see ".rtfd" and ".app" and ".pages" bundles as directories.
Apple's even using these tricks to apparently add features to HFS+: most spotlight metadata, for example, is stored in a regular file, and bundles are still implemented as folders. They even implement aliases in HFS+ on OSX using a real secondary directory tree, presumably because the vnode layer in UNIX won't work any other way!
They've also extended UFS to handle the most critical parts of their dual-fork model inside the file system... but they've stopped short of completing the job. They could do the rest of it, for UFS or for ZFS, if they wanted to... after all, HFS+ on OSX really *is* using these tricks too.
True, but the capabilities of UFS don't really exceed HFS+
In one way, at least, UFS is far better than HFS+.
The internal redundancy in UFS means that so long as the basic file system structures (directories, inodes, and indirect blocks) are intact, it can be repaired. The idea of having file system damage in a bootable file system that can't be repaired by FSCK is all but inconceivable for UFS or any of its precursor file systems. In nearly 30 years working with UNIX, once FSCK was introduced I *never* had a file system so damaged that FSCK couldn't completely restore the structure to working order. Three times now I've had HFS+ file systems require a backup and restore because of some obscure damage that even rebuilding the catalog wouldn't fix. A friend of mine is currently booting his Mac Pro off the second drive because the original installed file system was trashed.
ZFS claims "you'll never have to fsck again". That's what every journalled file system proponent says. That's what they said about XFS... until they came back with tools to do repair and you still had to reinstall to recover sometimes. I'll believe it when I've seen it in practice for a decade or so. What does ZFS do when it hits unrecoverable data in the file system structure itself?
UFS's fsck deals with it by rebuilding the file system structures so that they're valid, and tells you what you lost.
HFS+ tells you that you have some obscure catalog problem and you go out and buy DiskWarrior and hope your backups are in good shape.
XFS apparently gives you a chance to do a final backup.
What does ZFS do? The write-ups on ZFS indicate that they stop short of testing that case, and that's the most important one.
They made a big deal about the import of the latest UFS from FreeBSD in Panther, and their support for UFS was actually reduced in Tiger because they put the Spotlight hooks into HFS+ instead of using the hooks already in the vnode layer in Darwin.
So don't do anything that would depend on them supporting ZFS.
I can't even see my preferences link in at all with this system, the floaters do not work in Safari 3. I had to go straight to my user page by URL.
In addition, what's the point of having a checkbox "to turn off the excesses of the user interface" if it doesn't actually DO that?
Most PDA's don't have the high-resolution displays of good dedicated eBook readers or the XO
Most dedicated eBook readers are bigger than a hardcover, far too big to slip into your pocket. And my Clie has at least the same resolution as the good eBook readers I've seen, it just has a smaller screen... about half the size of a page of a paperback.
IMO, most PDA's don't make good e-Book readers.
IMO, most eBook readers don't make as good eBook readers as PDAs do. Being able to fit into my pocket is for me a non-negotiable feature, and something the size of a hardback book doesn't qualify.
A lot of the "improvements" are things that the game is doing differently in the DX9 and DX10 versions. Some of them, like the "litter objects" in one of the games, or gun movement effects in another, have nothing to do with DX10... it's like the game developers simply put more polish in the DX10 versions because they wanted the punters to "get their money's worth".
That said... let me contradict myself a bit.. what does a Mac have that Linux does not?
Applications.
What I want to know is why are you presenting this as Mac vs Linux?
UNIX is UNIX is UNIX. Linux is UNIX. OS X is UNIX. You get on any UNIX box, you have the same basic environment, you have all the open source software, you have the timesharing system developed in a hostile environment where security matters (when you have CS students and CS professors on the same computer, and you have to keep the students out of the professor's files, and the professor's grants are paying your salary, you take security seriously). It's the same system.
Free UNIX is cheaper and more versatile. Macs have the apps. Use whichever you want. Use both. They do the same stuff.
I switched to Mac from free UNIX because I was tired of being mister system administrator at home as well as at work, and tired of dual-booting Windows to run apps. And I didn't give up anything when I did it. But my home server is still the same open source box, because that's not the Mac's strength. It's a win win situation... why fight?
Who cares about dedicated eBook readers. Any PDA does as good a job, and you're not locked in to DRMed formats.
Who cares about cool special effects to fake optical accuracy? Within a few years we'll have real-time ray tracing and everything using rasterized graphics will look so fake.
get a solid, first part DirectX compatibility layer of some sort into OS X.
Not only "no" but "hell no".
DirectX only exists because Microsoft wanted a graphics standard they controlled that wasn't OpenGL, so they could use it to bone competitors. If you think OpenGL is a problem for Apple, having to implement DirectX to Microsoft's satisfaction would let Microsoft feed them the bone harder than you can possibly imagine.
Well, for starters Apple stayed on PPC too long
You mean the CPU that's in the XBox 360? That doesn't seem to be hurting Microsoft. Next ?
Those crappy intel GMA950 chips Apple is so enamored with don't even support all of the shaders the GUI needs
Now that one's a legitimate complaint... but all the PPC-era Macs had full 3d-capable video cards, while PC motherboards and Wintel laptops usually didn't.
I'm just saying that stallman is right with his distinction between "open" and "free"
.nets source may be "opened"
.NET SOURCE IS NOT "OPENED", and it's not "FREED" either, even though the person who wrote the headline could have written ".NET libraries are 'freed'" with about as much justification.
You're spreading FUD about open source, playing on some slashdotter's mistake.
Because
Sheesh.