I assume you mean MFS to HFS. There was also HFS to HFS+ in 8.1, which, again, required a reformat if you wanted to use the new features. There was a commercial conversion tool offered by a third party, however.
See what I mean?? I was so close, but yet so far...
Anyways, back then the drives were so much smaller, so the impact wasn't as great. However, with 250 GB drives, the amount of data and time lost can be extreme. Couldn't there be a way for Apple to make some sort of conversion tool to do this, or is there some sort of technical reason why this can't be done??
You don't need to buy them in order to hire away their engineers - sounds like a waste of money to me.
And you buy the stock, not the bonds, when you want to buy a company.
You can hire the engineers, but they aren't allowed to use any of the IP from the company they came from, even if it went out of business. Someone always buys the valuble IP, and is the legal sucessor. So, if Apple wanted that, they would have to pay for it one way or another.
Mike: there are many technical reasons why it can't be done, or rather, would be a tremendous waste of resources in doing so. If you were clever, you could re-partition your drive non-destructively, and copy files from HFS+ to ZFS.
Well maybe not. The main reason the HFS drives needed reformatting was the introduction of uniform small block sizes, rather than block sizes based on a percentage of the drive size. The percentage method was causing way too much space to be wasted in overly huge blocks. Since HFS+ used the assumption of the uniform block size a drive had to be reformatted to comply with that requirement. I remember gaining almost 25% of my drive capacity back after the reformat.
Since then HFS has undergone several updates and could be called HFS++ or HFS +++. How many of you even noticed these under the hood alteration during the reign of OSX? I would guess close to none unless you paid attention to WWDC or Apple developer mailings. This was all possible because 1) the fixed block sizes did not need to change; and 2) the HFS+ updates were mere plug-ins interfacing with the VFS layer of OS X.
As long as the physical block dimensions do not need to be changed, the needs to reformat the drives are greatly reduced. Then you are more reliant on whether the new driver will understand the partition and boot maps, or be able to re-lay them without a total reformat. Seeing as how it is all software driver magic, it is possible, whether it is likely or not is another matter.
You can hire the engineers, but they aren't allowed to use any of the IP from the company they came from, even if it went out of business. Someone always buys the valuble IP, and is the legal sucessor. So, if Apple wanted that, they would have to pay for it one way or another.
Often hiring the engineers is done because they know what they tried to do, but now know a better way to do it which the original company did not have the resources to attempt. This generally circumvents the IP issues because you are generating fundamentally different technology implementations. Sure, you get sued, then the case goes away later when all the facts are on the table. Big companies like Apple can survive those cycles.
Often hiring the engineers is done because they know what they tried to do, but now know a better way to do it which the original company did not have the resources to attempt. This generally circumvents the IP issues because you are generating fundamentally different technology implementations. Sure, you get sued, then the case goes away later when all the facts are on the table. Big companies like Apple can survive those cycles.
Not that simple, and very few companies are willing to take that risk.
Think as you may. I know of many instances of this working quite well.
Well, it's easy to make a statement like that. But if you look at the news, you will have seen many high level cases of one company suing another over those employment issues. The Microsoft Google situation is a recent example.
Here are the three points I made in the Ars WWDC thread, plus some comments at the end.
1. ZFS is being ported to Mac OS X. Apple has some involvement in this effort, but it's just that: a port. Lots of file systems have been ported to Mac OS X, both with and without Apple's involvement.
2. Apple will eventually replace HFS+ as the standard file system for Mac OS X. If that replacement happens in the Leopard time frame, the new file system will not be ZFS. The port will not be ready in time. (ZFS only just began shipping with Solaris 10.)
3. Apple tends to do its file system development in-house...
Quote:
How much 'space' does HFS have left for extension anyway? We've gone HFS, HFS+, HFS+J. Is there enough flexibility left to make 'HFS+JM'?
Sure, you can keep adding stuff to HFS+ for a while. But at some point, it's time to revisit basic design decisions like, say, the centralized Catalog File.
ZFS has taken Sun ~5 years from start to production release. How long has Apple been working on a new file system? The math makes Leopard at least a reasonable time frame for The New Hotness to make its debut.
Well, it's easy to make a statement like that. But if you look at the news, you will have seen many high level cases of one company suing another over those employment issues. The Microsoft Google situation is a recent example.
Exactly, I even mentioned the suing issue as it relates to IP.
The MS Google case is more an issue of a contracted executive and how far does the non-compete clause of that contract go. Washington state and California have very different laws on the legality of non-compete clauses in labor contracts. Engineers are not usually hired on contract, but at will, which completely eliminates the non-compete clause issues.
Back to the IP issue, what usually does not make the news about IP cases though is that the vast majority of patent cases get dismissed, dropped or settled for negligible sums. It is unusual for cases like the RIM one to end up in significant penalties when large corporations with their own R&D and legal teams are involved.
Exactly, I even mentioned the suing issue as it relates to IP.
The MS Google case is more an issue of a contracted executive and how far does the non-compete clause of that contract go. Washington state and California have very different laws on the legality of non-compete clauses in labor contracts. Engineers are not usually hired on contract, but at will, which completely eliminates the non-compete clause issues.
Non compete clauses can be demanded for any reason, though they are usually only required of someone who is involved in critical areas. Engineers are sometimes hired on contract. Most engineers work for the company as saleried employees.
But even contractual hirees can be required to sign forms limiting what work they do until some future date.
Quote:
Back to the IP issue, what usually does not make the news about IP cases though is that the vast majority of patent cases get dismissed, dropped or settled for negligible sums. It is unusual for cases like the RIM one to end up in significant penalties when large corporations with their own R&D and legal teams are involved.
Well, this is two seperate issues. Patents are not so much an individual contractual issue. Patents are an open database that anyone can access and do R&D on.
Non compete clauses can be demanded for any reason, though they are usually only required of someone who is involved in critical areas. Engineers are sometimes hired on contract. Most engineers work for the company as saleried employees.
But even contractual hirees can be required to sign forms limiting what work they do until some future date.
Well, this is two seperate issues. Patents are not so much an individual contractual issue. Patents are an open database that anyone can access and do R&D on.
Non-competes are illegal in California. Period. Big $$ lost by late '90s Silicon Valley companies for violations of state law ending in fines and the associated civil suits. Some companies still try to get away with them, but word is out and employees are getting more savvy.
Overall it makes the movement of intra-state employees much easier. It's also one of the main reasons Google thought they could get away with hiring the MS guy, despite his Washington State contract.
Non-competes are illegal in California. Period. Big $$ lost by late '90s Silicon Valley companies for violations of state law ending in fines and the associated civil suits. Some companies still try to get away with them, but word is out and employees are getting more savvy.
Overall it makes the movement of intra-state employees much easier. It's also one of the main reasons Google thought they could get away with hiring the MS guy, despite his Washington State contract.
Even if that is true in Cal., and I'm not so sure it is completely correct, it doesn't affect the basic argument that new employers are not allowed to benefit from the work done elsewhere, if that work was done under an NDA, which most work of this kind is, it is definitely excluded. Employees are simply not allowed to use the IP from one company to benefit another. That can mean letting a company know which avenues were looked at, and which did and didn't pan out.
They ARE allowed to use any greater understanding of basic technologies they used coming into the older firm, and other knowledge gained that was not directly related to the line of research and development of a specific area they were involved in.
An example would be if they had to learn any new math, or programming languages to further that work. They could use that knowledge in their new job. But, they would not be allowed to use any new algorithms or code specifically written for it.
Another example would be in materials technology. Any knowledge they gained about materials and techniques that would be needed for the job would be ok to use, but not any new information, or applications derived from that knowledge that was discovered during their work.
In other words, any knowledge needed to do their work that was obtainable from other sources would be ok to apply to the new job, but not any information that was obtained from the work itself.
This is pretty standard fare. It holds true anywhere.
What is the realistic chance that we will see this file system with Leopard? Basically null if you ask me.
Sun has reached out once to The Steve, albeit in a blog and kinda weak imho, it would be nice to see collaboration of some sort. Sun understands OS development and they really dig performance (almost to a fault). Apple understands hardware sytling and end-user end of use (most of the time). It almost makes sense.
Would it at least create a chance at seeing Apple Hardware supported on Solaris?
I doubt this would happen because I imagine this would mean another transition of some sort and "transition" is getting old, at least when it is at the level The Steve does it.
You've never heard the term "Slowlaris" coined, I guess.
Solaris exists on x86, so making it run using Boot Camp should be possible.
Yes, I have and it can be less than snappy at times.
There are several names for MS and Apple too but that doesn't mean too much (at least the Apple nick names are untrue ).
Apple hardware as in video and sound cards. That is the one problem with Solaris, being commercial doesn't give room to a big variety of hardware support.
All I know about this topic is that a long time ago Vista was going to have a new Filesystem and Apple was rumoured to be looking to best Vista in every conceivable way.
Thus, if The Jobs decided the Mac needed a new File System for Leopard, that work would have been started in-house a couple of years ago.
Which means that a new FS is a possibility for Leopard, but not ZFS.
Comments
Originally posted by Chucker
Er. AFS is a network file system.
I assume you mean MFS to HFS. There was also HFS to HFS+ in 8.1, which, again, required a reformat if you wanted to use the new features. There was a commercial conversion tool offered by a third party, however.
See what I mean?? I was so close, but yet so far...
Anyways, back then the drives were so much smaller, so the impact wasn't as great. However, with 250 GB drives, the amount of data and time lost can be extreme. Couldn't there be a way for Apple to make some sort of conversion tool to do this, or is there some sort of technical reason why this can't be done??
Originally posted by e1618978
You don't need to buy them in order to hire away their engineers - sounds like a waste of money to me.
And you buy the stock, not the bonds, when you want to buy a company.
You can hire the engineers, but they aren't allowed to use any of the IP from the company they came from, even if it went out of business. Someone always buys the valuble IP, and is the legal sucessor. So, if Apple wanted that, they would have to pay for it one way or another.
Since then HFS has undergone several updates and could be called HFS++ or HFS +++. How many of you even noticed these under the hood alteration during the reign of OSX? I would guess close to none unless you paid attention to WWDC or Apple developer mailings. This was all possible because 1) the fixed block sizes did not need to change; and 2) the HFS+ updates were mere plug-ins interfacing with the VFS layer of OS X.
As long as the physical block dimensions do not need to be changed, the needs to reformat the drives are greatly reduced. Then you are more reliant on whether the new driver will understand the partition and boot maps, or be able to re-lay them without a total reformat. Seeing as how it is all software driver magic, it is possible, whether it is likely or not is another matter.
Originally posted by melgross
You can hire the engineers, but they aren't allowed to use any of the IP from the company they came from, even if it went out of business. Someone always buys the valuble IP, and is the legal sucessor. So, if Apple wanted that, they would have to pay for it one way or another.
Often hiring the engineers is done because they know what they tried to do, but now know a better way to do it which the original company did not have the resources to attempt. This generally circumvents the IP issues because you are generating fundamentally different technology implementations. Sure, you get sued, then the case goes away later when all the facts are on the table. Big companies like Apple can survive those cycles.
Originally posted by Hiro
Often hiring the engineers is done because they know what they tried to do, but now know a better way to do it which the original company did not have the resources to attempt. This generally circumvents the IP issues because you are generating fundamentally different technology implementations. Sure, you get sued, then the case goes away later when all the facts are on the table. Big companies like Apple can survive those cycles.
Not that simple, and very few companies are willing to take that risk.
Originally posted by Hiro
Think as you may. I know of many instances of this working quite well.
Well, it's easy to make a statement like that. But if you look at the news, you will have seen many high level cases of one company suing another over those employment issues. The Microsoft Google situation is a recent example.
1. ZFS is being ported to Mac OS X. Apple has some involvement in this effort, but it's just that: a port. Lots of file systems have been ported to Mac OS X, both with and without Apple's involvement.
2. Apple will eventually replace HFS+ as the standard file system for Mac OS X. If that replacement happens in the Leopard time frame, the new file system will not be ZFS. The port will not be ready in time. (ZFS only just began shipping with Solaris 10.)
3. Apple tends to do its file system development in-house...
How much 'space' does HFS have left for extension anyway? We've gone HFS, HFS+, HFS+J. Is there enough flexibility left to make 'HFS+JM'?
Sure, you can keep adding stuff to HFS+ for a while. But at some point, it's time to revisit basic design decisions like, say, the centralized Catalog File.
ZFS has taken Sun ~5 years from start to production release. How long has Apple been working on a new file system? The math makes Leopard at least a reasonable time frame for The New Hotness to make its debut.
Originally posted by melgross
Well, it's easy to make a statement like that. But if you look at the news, you will have seen many high level cases of one company suing another over those employment issues. The Microsoft Google situation is a recent example.
Exactly, I even mentioned the suing issue as it relates to IP.
The MS Google case is more an issue of a contracted executive and how far does the non-compete clause of that contract go. Washington state and California have very different laws on the legality of non-compete clauses in labor contracts. Engineers are not usually hired on contract, but at will, which completely eliminates the non-compete clause issues.
Back to the IP issue, what usually does not make the news about IP cases though is that the vast majority of patent cases get dismissed, dropped or settled for negligible sums. It is unusual for cases like the RIM one to end up in significant penalties when large corporations with their own R&D and legal teams are involved.
Originally posted by Hiro
Exactly, I even mentioned the suing issue as it relates to IP.
The MS Google case is more an issue of a contracted executive and how far does the non-compete clause of that contract go. Washington state and California have very different laws on the legality of non-compete clauses in labor contracts. Engineers are not usually hired on contract, but at will, which completely eliminates the non-compete clause issues.
Non compete clauses can be demanded for any reason, though they are usually only required of someone who is involved in critical areas. Engineers are sometimes hired on contract. Most engineers work for the company as saleried employees.
But even contractual hirees can be required to sign forms limiting what work they do until some future date.
Quote:
Back to the IP issue, what usually does not make the news about IP cases though is that the vast majority of patent cases get dismissed, dropped or settled for negligible sums. It is unusual for cases like the RIM one to end up in significant penalties when large corporations with their own R&D and legal teams are involved.
Well, this is two seperate issues. Patents are not so much an individual contractual issue. Patents are an open database that anyone can access and do R&D on.
Originally posted by melgross
Non compete clauses can be demanded for any reason, though they are usually only required of someone who is involved in critical areas. Engineers are sometimes hired on contract. Most engineers work for the company as saleried employees.
But even contractual hirees can be required to sign forms limiting what work they do until some future date.
Well, this is two seperate issues. Patents are not so much an individual contractual issue. Patents are an open database that anyone can access and do R&D on.
Non-competes are illegal in California. Period. Big $$ lost by late '90s Silicon Valley companies for violations of state law ending in fines and the associated civil suits. Some companies still try to get away with them, but word is out and employees are getting more savvy.
Overall it makes the movement of intra-state employees much easier. It's also one of the main reasons Google thought they could get away with hiring the MS guy, despite his Washington State contract.
Originally posted by Hiro
Non-competes are illegal in California. Period. Big $$ lost by late '90s Silicon Valley companies for violations of state law ending in fines and the associated civil suits. Some companies still try to get away with them, but word is out and employees are getting more savvy.
Overall it makes the movement of intra-state employees much easier. It's also one of the main reasons Google thought they could get away with hiring the MS guy, despite his Washington State contract.
Even if that is true in Cal., and I'm not so sure it is completely correct, it doesn't affect the basic argument that new employers are not allowed to benefit from the work done elsewhere, if that work was done under an NDA, which most work of this kind is, it is definitely excluded. Employees are simply not allowed to use the IP from one company to benefit another. That can mean letting a company know which avenues were looked at, and which did and didn't pan out.
They ARE allowed to use any greater understanding of basic technologies they used coming into the older firm, and other knowledge gained that was not directly related to the line of research and development of a specific area they were involved in.
An example would be if they had to learn any new math, or programming languages to further that work. They could use that knowledge in their new job. But, they would not be allowed to use any new algorithms or code specifically written for it.
Another example would be in materials technology. Any knowledge they gained about materials and techniques that would be needed for the job would be ok to use, but not any new information, or applications derived from that knowledge that was discovered during their work.
In other words, any knowledge needed to do their work that was obtainable from other sources would be ok to apply to the new job, but not any information that was obtained from the work itself.
This is pretty standard fare. It holds true anywhere.
Sun has reached out once to The Steve, albeit in a blog and kinda weak imho, it would be nice to see collaboration of some sort. Sun understands OS development and they really dig performance (almost to a fault). Apple understands hardware sytling and end-user end of use (most of the time). It almost makes sense.
Would it at least create a chance at seeing Apple Hardware supported on Solaris?
I doubt this would happen because I imagine this would mean another transition of some sort and "transition" is getting old, at least when it is at the level The Steve does it.
Originally posted by aplnub
Sun [..] really dig performance (almost to a fault).
You've never heard the term "Slowlaris" coined, I guess.
Would it at least create a chance at seeing Apple Hardware supported on Solaris?
Solaris exists on x86, so making it run using Boot Camp should be possible.
Originally posted by Chucker
You've never heard the term "Slowlaris" coined, I guess.
Solaris exists on x86, so making it run using Boot Camp should be possible.
Yes, I have and it can be less than snappy at times.
There are several names for MS and Apple too but that doesn't mean too much (at least the Apple nick names are untrue
Apple hardware as in video and sound cards. That is the one problem with Solaris, being commercial doesn't give room to a big variety of hardware support.
Originally posted by aplnub
That is the one problem with Solaris, being commercial doesn't give room to a big variety of hardware support. [/B]
OpenSolaris isn't all that commercial.
Originally posted by Gene Clean
That thang is a pain to install.
This is, after all, Solaris we're talking about.
Thus, if The Jobs decided the Mac needed a new File System for Leopard, that work would have been started in-house a couple of years ago.
Which means that a new FS is a possibility for Leopard, but not ZFS.