The advantages of ZFS are the built-in volume management (or "volume-like management," depending on your perspective), and the data integrity.
The disadvantage is... the data integrity. Every byte of data gets checksummed. This is going to affect performance -- HFS+ will normally write large chunks of data with as little copying as possible, and there are non-standard ways to get no copying (other than to/from the disk). ZFS doesn't have that; the data are always examined. And this slows things down. Sun doesn't have so much of a problem with this, as their machines have enough CPUs, and enough bus, to effectively dedicate a CPU to the filesystem. Macs, not so much.
Don't get me wrong... ZFS is really cool, and I'd love to see it on Mac OS X. But it's not a panacaea.
The tuatara isn't actually a lizard (any more than a crocodile is). They're pretty neat reptiles -- as a poster notes below, they have a "third eye" (they're not unique in this regard, some iguana species do as well, but not as well-developed as the tuatara's) -- and they require cold temperatures. Non-New Zealand zoos that get tuatara have to have triple cooling methods.
Sorry, but your description of the lookup process isn't right.
First: lookup depends on the way directory entries are store. On UFS, it's a non-sorted array; in order to do a lookup, you need to (worst case) scan the entire directory. On VxFS, they use a hash, so first you hash the input, and then do run through the entries that have a matching hash. On HFS+, the catalog is stored as a B-tree, so you do compares to get to the right node, and then look through the node until you either find it or reach the end of the node.
Second: None of those is affected by case-insensitivity. You simply do a case-insensitive compare each time. This is the difference between HFS+ and HFSX on Mac OS X: in the former, the key-compare function is a Unicode case-insensitive comparator; on the latter, it's just a memcmp.
Third: your comment about "i" is a glyphing issue, not a character issue.
Apple has a pretty good technote up on their HFS+ impelementation, and it describes the way the case insensitivity works. I recommend reading it.
The stuff H&B worked on for MGM was high-quality, high-cost, low-frequency work. (That is, they'd make only a few shorts a year, and that'd be it; it still cost a lot of money.)
H&B's real claim to fame is that they came up with cheap animation, suitable for the lower television budgets, and capable of being produced quickly enough for a TV series.
They did this through some animation tricks (only drawing a partial cell, for example, instead of the whole cell -- think MPEG2 compression), but, yes, they also put less effort into it, creatively.
But they paved the way for every cartoon that is on TV now. For better or worse:).
Worse, he seems to be saying that the "detail-oriented" presentation -- in which Jobs talked about and demonstrated what the device could do -- would leave consumers disappointed... that it can do what was claimed it could do?
While he may have some valid points, it does seem to reek of "jumping on the attack-SJ-dogpile."
If Hans Reiser were less well-known -- or were involved in a non-Linux project -- maybe the story would have made Slashdot when his wife first disappeared, rather than when he was arrested for her murder.
(Obvious disclaimer here: I still hope she's alive and all right; I hope he wasn't involved in anything nefarious; and I hope everything works out for the best as soon as possible, and the children do not end up traumatized.)
Although I agree he could have stated it better: the issue is that if we, as a nation, believe these weapons are in fact non-lethal, then why are we not using them domestically?
It's a valid, debatable point. And extremely different from "let's test it on civilians!"
The only difference here is that Apple users are so goddamn fanatical that they'll rabidly attack anybody who says their platform is any less than perfect.
That may be the case... but in the circles I hang out in, the big question has been "Is this real?" Having them demonstrate using a hardware combination that is extremely unlikely to be encountered in the practicality -- that uses non-vendor drivers! -- while they imply (and nothing more) worse... is not very compelling.
Mac users are in for a rude shock.
No doubt. But how does what continues to reek of being a false alarm help in any way? Right now, this whole incident has conveyed nothing but a sense of, "Well, they had an axe to grind, so they used some other vendor's code, and then lied about how Mac OS X was insecure."
It very well may be the case that the Apple driver is vulnerable. But they've honestly done everything they possibly can to convince the multitudes that it isn't.
And that is a huge disservice to the community they claim they are trying to help.
And speaking from a technical aspect, here is the question I asked before: if the Apple driver is vulnerable... how do they get a network-connected shell from the kernel? It is not easy -- at the very least, it would involve having a process be created, from the kernel. And that is a significant amount of code, as you could tell by looking how the first process is created during boot.
(Again, I am trying to give them the benefit of the doubt, that the vulnerability is real. But they're doing what they can to imply otherwise.)
That's not strictly true in this case: On Mac OS X, USB drivers live in user space. My original thought was that this is why they used a third-party card -- it's a lot easier to get a shell process from a USB user-land driver than it is from a kernel-land driver. (Oh, it can be done... but it's nowhere close to being easy. Much easier to just change some file, or change the security level of an existing process.)
Slashdot Mirror
The advantages of ZFS are the built-in volume management (or "volume-like management," depending on your perspective), and the data integrity.
The disadvantage is... the data integrity. Every byte of data gets checksummed. This is going to affect performance -- HFS+ will normally write large chunks of data with as little copying as possible, and there are non-standard ways to get no copying (other than to/from the disk). ZFS doesn't have that; the data are always examined. And this slows things down. Sun doesn't have so much of a problem with this, as their machines have enough CPUs, and enough bus, to effectively dedicate a CPU to the filesystem. Macs, not so much.
Don't get me wrong... ZFS is really cool, and I'd love to see it on Mac OS X. But it's not a panacaea.
The tuatara isn't actually a lizard (any more than a crocodile is). They're pretty neat reptiles -- as a poster notes below, they have a "third eye" (they're not unique in this regard, some iguana species do as well, but not as well-developed as the tuatara's) -- and they require cold temperatures. Non-New Zealand zoos that get tuatara have to have triple cooling methods.
Yes, you are confusing glyphing with characters. Take a look at the Unicode character set some time.
Sorry, but your description of the lookup process isn't right. First: lookup depends on the way directory entries are store. On UFS, it's a non-sorted array; in order to do a lookup, you need to (worst case) scan the entire directory. On VxFS, they use a hash, so first you hash the input, and then do run through the entries that have a matching hash. On HFS+, the catalog is stored as a B-tree, so you do compares to get to the right node, and then look through the node until you either find it or reach the end of the node. Second: None of those is affected by case-insensitivity. You simply do a case-insensitive compare each time. This is the difference between HFS+ and HFSX on Mac OS X: in the former, the key-compare function is a Unicode case-insensitive comparator; on the latter, it's just a memcmp. Third: your comment about "i" is a glyphing issue, not a character issue. Apple has a pretty good technote up on their HFS+ impelementation, and it describes the way the case insensitivity works. I recommend reading it.
The stuff H&B worked on for MGM was high-quality, high-cost, low-frequency work. (That is, they'd make only a few shorts a year, and that'd be it; it still cost a lot of money.)
H&B's real claim to fame is that they came up with cheap animation, suitable for the lower television budgets, and capable of being produced quickly enough for a TV series.
They did this through some animation tricks (only drawing a partial cell, for example, instead of the whole cell -- think MPEG2 compression), but, yes, they also put less effort into it, creatively.
But they paved the way for every cartoon that is on TV now. For better or worse :).
Worse, he seems to be saying that the "detail-oriented" presentation -- in which Jobs talked about and demonstrated what the device could do -- would leave consumers disappointed... that it can do what was claimed it could do?
While he may have some valid points, it does seem to reek of "jumping on the attack-SJ-dogpile."
If Hans Reiser were less well-known -- or were involved in a non-Linux project -- maybe the story would have made Slashdot when his wife first disappeared, rather than when he was arrested for her murder.
(Obvious disclaimer here: I still hope she's alive and all right; I hope he wasn't involved in anything nefarious; and I hope everything works out for the best as soon as possible, and the children do not end up traumatized.)
Although I agree he could have stated it better: the issue is that if we, as a nation, believe these weapons are in fact non-lethal, then why are we not using them domestically?
It's a valid, debatable point. And extremely different from "let's test it on civilians!"
That may be the case... but in the circles I hang out in, the big question has been "Is this real?" Having them demonstrate using a hardware combination that is extremely unlikely to be encountered in the practicality -- that uses non-vendor drivers! -- while they imply (and nothing more) worse... is not very compelling.
No doubt. But how does what continues to reek of being a false alarm help in any way? Right now, this whole incident has conveyed nothing but a sense of, "Well, they had an axe to grind, so they used some other vendor's code, and then lied about how Mac OS X was insecure."
It very well may be the case that the Apple driver is vulnerable. But they've honestly done everything they possibly can to convince the multitudes that it isn't.
And that is a huge disservice to the community they claim they are trying to help.
And speaking from a technical aspect, here is the question I asked before: if the Apple driver is vulnerable... how do they get a network-connected shell from the kernel? It is not easy -- at the very least, it would involve having a process be created, from the kernel. And that is a significant amount of code, as you could tell by looking how the first process is created during boot.
(Again, I am trying to give them the benefit of the doubt, that the vulnerability is real. But they're doing what they can to imply otherwise.)
That's not strictly true in this case: On Mac OS X, USB drivers live in user space. My original thought was that this is why they used a third-party card -- it's a lot easier to get a shell process from a USB user-land driver than it is from a kernel-land driver. (Oh, it can be done... but it's nowhere close to being easy. Much easier to just change some file, or change the security level of an existing process.)