That's pretty crazy. I've never noticed that before, but I've been keeping my Macs around too. I don't even use them at all, and some are definately too old to be used for anything practical.
Still...I just can't bring myself to throw them away, I don't know why...
We are stuck on PowerPC because of an old PowerPC only application, that all of our data is in
You should take a look at PPC emulators for x86. I've actually been playing with SheepShaver on my Windows box and it emulates a PPC well enough on my core 2 duo that I was able to pack up my old PPC Mac systems and run the software I need in there. I'm running Mac OS 9.2.2 though...I have no clue how well it would run OS X. IIRC PearPC was supposed to be better at running OS X when I was reading up on it.
It was a bit of a pain to get it setup initially. The Windows version of the emulator is available here. You also need a working Mac OS ROM image, which you have to find online or dump from one of your PPC Mac systems. There's an excellent torrent available called "Mac Emulation Kit" which contains a lot of good files you might want to get started.
I'm pretty sure either the IE 5 or 6 (or both) installers included Flash Player as one of the installable options which was visible under custom setup and enabled as part of the default IE install. Flash Player also does ship with non-OEM versions of Windows, I think XP ships with the Flash Player 8 ActiveX (check the "%WinDir%\Downloaded Program Files" directory). There are even Microsoft updates packages which update the Flash Player and are available on Windows Update. You might have seen the ActiveX notification to install the updated Flash Player ActiveX control, but could probably still view the Flash content if you don't install the update.
Microsoft has nothing against Flash Player. Before Silverlight, they had no competing product other than Liquid Motion (which was killed off a long time ago). Flash is a very popular format and IE looks better to the end user if they don't have to install it. They probably also have some kind of deal with Adobe.
There's no complex process involved in wiring a light fixture that is beyond the capabilities of an apprentice electrician. It's not beyond the capabilities of any guy who can follow directions and connect three wires to screws. There's also little or no risk of your house catching fire even if he wires it completely wrong. You should have a fire proof box, ground wire, and circuit breaker to prevent a fire from at various places where one might start from bad wiring.
It's overkill to hire a master electrician to wire a single light fixture, and he would probably send his apprentice to do it anyway.
It would be like hiring a Dell service tech at $200+/hr to install a stick of memory in your computer. Yes you might damage a component, but the process is simple enough that you know you won't.
RealBasic, like Delphi is a great product which is often overlooked. RealBasic supports full OO code, has a nice IDE and form designer, better implementations of most of the VB classes and function, and it compiles programs for Windows, Mac (OS X and Carbon), and Linux.
For some reason Real Software never really markets their product at all, and they seem to be putting less and less effort into it. Although the RB OO system is superior, the RB documentation is not. The level of detail and even up to date information is far below MSDN, and the online community sites are not much better. I think that is a huge blow for people who are trying to migrate to RB, especially VB programmers trying to grasp the OO model.
It's a shame that people put out excellent developer tools and have such poor marketing. Realbasic is much more powerful than VB, and probably would be a great solution for many people. But only if they hear about it...
That's because Nero and Roxio no longer try to market a streamlined product for burning buffs. Most of the people burning things these days have no clue about how it works and expect the burning software to do more than burn a disc. For example, burning a DIVX movie they downloaded to a disc they can play in their DVD player. They drag the movie onto the project in Nero and expect it to figure out the details, like converting the video/audio, settting up the disc layout and burning an SVCD disc. Roxio takes this a step further by monitoring and popping up the instant you put in a disc and attempting to figure out what you want to do with it.
Half of the tools that come with the full Nero package are things like a media center, media sharing server, photo manager, sound/video editor and numerous other apps that have nothing to do with burning a disc.
Tools like MagicISO or PowerISO have become the tools for people who just want to burn discs and work with image files. Nero and Roxio have become some sort of massive media suites that also happen to burn discs.
If you wanted the best performance for your new computer you should install MS-DOS. Naturally MS-DOS is somewhat lacking in features as you probably want to use things like multitasking, protected memory, a TCP/IP stack etc on your new computer.
My point is that computers are expected to do a lot more things and there is more abstraction between the software and the bare metal. MS-DOS was fast but programs had to do everything themselves. For example, to draw a line on the screen you would have to manually query the video adapter and determine how to write to it's memory so it does what you want. On modern systems there's usually a display driver and an API (like GDI) which separate the programmer from the hardware. The program can draw a line without knowing anything about the specific hardware or VESA screen modes.
VBA is just the macro language. Developing an Office application in VBA would be a project of gargantuan magnitude. that kind of project would be difficult even with full Visual Basic 5/6. I don't think VBA can be compiled into an application either. I would assume most of the Office apps are written in C++, and expose their VBA interfaces using COM.
People forget how heavily COM is used in Windows too. It hides the component's underlying implementation so components can be written in any language and used in any language that can query the component's interfaces. Of course, the layer where COM is implemented is far above the kernel, HAL and base subsystem libraries which are done in C.
The programming language has nothing to do with the security of the system, it's the quality of the programmers. They could code the entire thing in QBASIC and still have a secure and stable system if they know what they are doing. I doubt they are using a bunch of greenhorn C++ programmers, so it won't be like herding cats for them.
I don't know a lot about ADA, but I do hear that it is better suited for embedded systems, and (as you mentioned) is more proven in those scenarios. It also has a lot of built in checking which would probably make securing it easier. It doesn't mean it's the only choice however. There must be a reason for them to decide on C++ (I hope).
Windows btw is written mostly in C. C++ is awkward for writing operating system kernels and core API's, so it is generally not used for that (although it can be done). If you look at Charles Petzold's "Programming Windows 95" you will not see any C++ code in the whole book. All of the Win32 API's are built around C but are made easier to use with C++ wrappers like MFC.
Are you sure it's a true DOS application and not a Win32 Console App? I know it is entirely possible for someone to write a CGI in DOS but it seems really weird to me that they would use DOS since it didn't have anything that would server CGI, and coding a hand rolled database format would be a lot of extra work.
If it is using Win32 it might just be accessing a DAO database without using the mdb extension, which many companies do to make it look like a proprietary format you can't just open with MS Access. If you look at the raw data it might look crazy and unusable because JET databases use XOR to obfuscate the contents of the database file (and prevent you from extracting the strings inside).
I also have spent a long time dealing with FileMaker too and it can be a huge PITA. Be thankful you didn't have to maintain a FileMaker Pro Server or web server for many people!
It is very easy for non-tech savvy people to use to build a bunch of databases and start using them which is cool. The problem is that the databases have a very simple design and most people don't even know how to setup a relationship between two fields. They just drag and drop fields onto a form and let FileMaker figure out how to store and share the data.
Those databases then tend to evolve and as they get more complex they are harder to manage using the simple interface that FileMaker Pro tries to provide. One person's quick inventory tracking database suddenly becomes a massive asset database used by the whole company years down the road, and you're left struggling to keep it running.FileMaker Pro and Lotus Domino are the worst for this kind of thing.
IIRC there are a few ways to extract the data from FileMaker Pro databases. There is an ODBC driver that comes with the FileMaker Pro client (at least it did back in the 3.x and 4.x days). That would be the easiest way to extract the data for other applications to use. FileMaker Pro 4.0 used to also come with a web server plugin that would use CDML to generate dynamic web pages from the database (of course Claris HomePage was the best tool to nuild CDML apps at the time).
CGI works by having the server executes the program (passing the data to it from STDIN or the command line) and then retreiving the page's complete HTML code from STDOUT. You can use any file that can be executed and use STDIN/STDOUT in this manner that is located in a specified location(like cgi-bin). On Windows this would be any exe,com,pif,bat or cmd file, and the extension must be there for the operating system to determine that it is an executable. On Linux you can use any file that +x permissions, compiled binaries or scripts with a bang at the beginning, so it can have any extension you want (or none) for a CGI.
People used to write a lot of CGI applications in perl because of it's text processing capabilities, but there were many CGI's that were compiled programs (written in languages like C). At one point Microsoft was really pushing the idea of easily writing CGI applications in Visual Basic and hosting them with IIS.
CGI fell out of popularity in favor of embedded scripting like PHP and ASP which have much less overhead (they don't have to create a new process to service every user request and wait for it's output) and are much less complex for people to use (they don't require special directories or permissions).
I really like your idea of laying out the problems with IE6 to the end user and providing solutions for them to upgrade, but your other comments about people being spineless and greedy because they can't do the same makes you look like a fanatical asshole.
Your job as a developer is to develop code that meets the needs of your users and customers, not to dictate what you like to them and make an ideological stand. If you tell your boss or customers to fuck off because you don't like their browser then they find a developer who will do the job that they are fucking paying him to do. The end user doesn't give a shit about open standards or who follows them, they want to get shit done. Standards are nice but if they aren't laws, and we have to follow supply and demand if we want to feed our family and succeed in the real world.
Even Microsoft had to do shit like make sure Word could open WordPerfect documents and IE could open web pages built for Netscape. If they had told customers to fuck off because they wanted to do things the way they liked, no one would use their shit and they wouldn't be in the dominant position they are in today.
Yes you're comparing a string under a single thread in the same memory space. Now multiply the CPU time by the number of requests that probably go across the OpenID servers every second and also take shit like context switching and memory management into account. You can't assume a highly loaded server is the same as your workstation.
For example, on one of our Windows servers someone installed the J2RE which also runs an updater app when you login to your profile. It used 100MB of memory but it was almost entirely paged to disk so he thought it was ok. The problem was that it was a Citrix server which thousands of people logged to every day (each running a copy of the updater app). Pretty soon that 100MB of added up to gigabytes, consumed the entire size of the paging file, and the server started to run out of memory.
There were lots of games that didn't have the Nintendo seal of approval. Most games made by Tengen, Color dreams, and CodeMasters were unlicensed.
Yes but Nintendo restricted unlicensed cartridges with their 10NES protection scheme. Any NES built after 1987 would would continually reset itself if it couldn't authenticate with a 10NES chip which was only included in licensed cartridges.
First of all, when a hard drive is turned off and unplugged, the moving parts aren't moving. So the mechanical wear and stress of constant operation aren't really a problem.
Hard disk parts can also become seized and have trouble starting if the drive is inactive for a lengthy amount of time. I'm not sure how long it takes or how often it happens though.
In the real world the manager justifies his job by cutting costs wherever he can. I've never seen a manager get rewarded for being proactive and spending a lot of money. If anything they'll ask him to reduce the IT budget this quarter because none of them know what the IT guy actually does.
BREW is an API layer which sits above the phone's native API in order to provide a consistent programming interface across various phones. You write BREW apps with C or C++ and compile them into binaries. BREW is basically just a wrapper which translates the BREW APU calls to the phone's internal low level API calls. It would actually be stupid to code all your apps for the phone's native API because it will be different on every single model of phone, and you would have to re-write them every time.
Because it's professional to kick someone... because you don't like the way that they type
I haven't used IRC in a while but I don't ever remember it being very professional, and yes, anything the channel ops don't like gets you kicked (at least in the channels I used to hang out in). The fact that they gave him 30 minutes before kicking him from the channel is probably as professional as you can get.
He was typing weirdly, posting password hashes to main...he could be an RIAA agent in disguise, just some crazy guy threatening to hack them, he could be anybody. Channel operators aren't there to make friends with everyone in the channel, they are there to keep things in check.
There are some times when the underlying file system can matter, but the file sharing server must be aware of the limitations and deal with the problem transparently. If it doesn't, it can cause a lot of problems.
File streams are a pretty annoying problem when the underlying file system doesn't support them. Microsoft also stopped storing metadata in alternate data streams because people would copy them to file shares and would sometimes lose the ADS data. AppleShare is an even worse nightmare because many file systems strip the resource fork. Netatalk for Linux intelligently stores the streams as separate directories so they will work on file systems like ext2. Microsoft's Services for Macintosh doesn't do this kind of thing and will only work properly on NTFS which can store them directly in alternate data streams, which FAT doesn't support.
There are also various file permissions and attributes which depend on the file system. Newer versions of Windows file sharing supports NTFS style file/folder ACL's and Volume Shadow Copies which are not implemented the same on many other file systems. AppleTalk also expects all of the various bits of extra information stored on an HFS volume (like the file type and creator mappings).
It appears to me that the design and features of ZFS allow it to easily support the features of other file systems without a lot of extra work. If you had the NAS running something like ext3, I think the file servering services would probably have to do a lot more work translating those features to work correctly.
Whoa calm down! It doesn't matter if Linux actually infringes or not, corporations will still be leary about adoption as long as there are claims out there that it does. That it is the exact definition of encumbered, the adoption of Linux is impeded by a heavy load, that being the bad publicity from the SCO and Microsoft/Novell fiascos.
Do you remember this issue, when there was a BSD driver that was included in Linux and was re-licenced as GPL by mistake? Or how about this one, where the OpenBSD project stripped the comments from a GPL'd driver and re-licensed it as BSD? Obviously there are some copyright issues slipping through the cracks even among the different OSS projects. Since Linux has so many contributors from so many different places, it is easy for a company to start spreading claims that one piece, somewhere, might be infringing.
As soon as the corporate lawyers get wind of that kind of thing, they'll push to avoid adoption and to migrate solutions away from Linux. Look at the Unisys LZW patent in GIF files or the Fraunhofer patents in MP3 files. Companies were panicking because they might have an MP3 stored somewhere, without any understanding of the actual issue.
Are you kidding? Remember they have to go through US customs. Even the CIA wouldn't want to deal with those guys. They probably even give Obama the rough treatment!
Are you telling me that I can not run the MS Office I legally bought on WINE under linux?
Not if the MS Office license contains restrictions against it. When you legally bought MS Office all you really bought was a license that allows you to use the software. If you don't agree to the terms of the license, you can't install or use any of the software included on the Office disc. If Microsoft wanted to they could specify in the license that it can only be installed on Windows and that would be the end of using it (legally) under WINE.
Slashdot Mirror
That's pretty crazy. I've never noticed that before, but I've been keeping my Macs around too. I don't even use them at all, and some are definately too old to be used for anything practical.
Still...I just can't bring myself to throw them away, I don't know why...
You should take a look at PPC emulators for x86. I've actually been playing with SheepShaver on my Windows box and it emulates a PPC well enough on my core 2 duo that I was able to pack up my old PPC Mac systems and run the software I need in there. I'm running Mac OS 9.2.2 though...I have no clue how well it would run OS X. IIRC PearPC was supposed to be better at running OS X when I was reading up on it.
It was a bit of a pain to get it setup initially. The Windows version of the emulator is available here. You also need a working Mac OS ROM image, which you have to find online or dump from one of your PPC Mac systems. There's an excellent torrent available called "Mac Emulation Kit" which contains a lot of good files you might want to get started.
I'm pretty sure either the IE 5 or 6 (or both) installers included Flash Player as one of the installable options which was visible under custom setup and enabled as part of the default IE install. Flash Player also does ship with non-OEM versions of Windows, I think XP ships with the Flash Player 8 ActiveX (check the "%WinDir%\Downloaded Program Files" directory). There are even Microsoft updates packages which update the Flash Player and are available on Windows Update. You might have seen the ActiveX notification to install the updated Flash Player ActiveX control, but could probably still view the Flash content if you don't install the update.
Microsoft has nothing against Flash Player. Before Silverlight, they had no competing product other than Liquid Motion (which was killed off a long time ago). Flash is a very popular format and IE looks better to the end user if they don't have to install it. They probably also have some kind of deal with Adobe.
There's no complex process involved in wiring a light fixture that is beyond the capabilities of an apprentice electrician. It's not beyond the capabilities of any guy who can follow directions and connect three wires to screws. There's also little or no risk of your house catching fire even if he wires it completely wrong. You should have a fire proof box, ground wire, and circuit breaker to prevent a fire from at various places where one might start from bad wiring.
It's overkill to hire a master electrician to wire a single light fixture, and he would probably send his apprentice to do it anyway.
It would be like hiring a Dell service tech at $200+/hr to install a stick of memory in your computer. Yes you might damage a component, but the process is simple enough that you know you won't.
RealBasic, like Delphi is a great product which is often overlooked. RealBasic supports full OO code, has a nice IDE and form designer, better implementations of most of the VB classes and function, and it compiles programs for Windows, Mac (OS X and Carbon), and Linux.
For some reason Real Software never really markets their product at all, and they seem to be putting less and less effort into it. Although the RB OO system is superior, the RB documentation is not. The level of detail and even up to date information is far below MSDN, and the online community sites are not much better. I think that is a huge blow for people who are trying to migrate to RB, especially VB programmers trying to grasp the OO model.
It's a shame that people put out excellent developer tools and have such poor marketing. Realbasic is much more powerful than VB, and probably would be a great solution for many people. But only if they hear about it...
That's because Nero and Roxio no longer try to market a streamlined product for burning buffs. Most of the people burning things these days have no clue about how it works and expect the burning software to do more than burn a disc. For example, burning a DIVX movie they downloaded to a disc they can play in their DVD player. They drag the movie onto the project in Nero and expect it to figure out the details, like converting the video/audio, settting up the disc layout and burning an SVCD disc. Roxio takes this a step further by monitoring and popping up the instant you put in a disc and attempting to figure out what you want to do with it.
Half of the tools that come with the full Nero package are things like a media center, media sharing server, photo manager, sound/video editor and numerous other apps that have nothing to do with burning a disc.
Tools like MagicISO or PowerISO have become the tools for people who just want to burn discs and work with image files. Nero and Roxio have become some sort of massive media suites that also happen to burn discs.
If you wanted the best performance for your new computer you should install MS-DOS. Naturally MS-DOS is somewhat lacking in features as you probably want to use things like multitasking, protected memory, a TCP/IP stack etc on your new computer.
My point is that computers are expected to do a lot more things and there is more abstraction between the software and the bare metal. MS-DOS was fast but programs had to do everything themselves. For example, to draw a line on the screen you would have to manually query the video adapter and determine how to write to it's memory so it does what you want. On modern systems there's usually a display driver and an API (like GDI) which separate the programmer from the hardware. The program can draw a line without knowing anything about the specific hardware or VESA screen modes.
VBA is just the macro language. Developing an Office application in VBA would be a project of gargantuan magnitude. that kind of project would be difficult even with full Visual Basic 5/6. I don't think VBA can be compiled into an application either. I would assume most of the Office apps are written in C++, and expose their VBA interfaces using COM.
People forget how heavily COM is used in Windows too. It hides the component's underlying implementation so components can be written in any language and used in any language that can query the component's interfaces. Of course, the layer where COM is implemented is far above the kernel, HAL and base subsystem libraries which are done in C.
The programming language has nothing to do with the security of the system, it's the quality of the programmers. They could code the entire thing in QBASIC and still have a secure and stable system if they know what they are doing. I doubt they are using a bunch of greenhorn C++ programmers, so it won't be like herding cats for them.
I don't know a lot about ADA, but I do hear that it is better suited for embedded systems, and (as you mentioned) is more proven in those scenarios. It also has a lot of built in checking which would probably make securing it easier. It doesn't mean it's the only choice however. There must be a reason for them to decide on C++ (I hope).
Windows btw is written mostly in C. C++ is awkward for writing operating system kernels and core API's, so it is generally not used for that (although it can be done). If you look at Charles Petzold's "Programming Windows 95" you will not see any C++ code in the whole book. All of the Win32 API's are built around C but are made easier to use with C++ wrappers like MFC.
Are you sure it's a true DOS application and not a Win32 Console App? I know it is entirely possible for someone to write a CGI in DOS but it seems really weird to me that they would use DOS since it didn't have anything that would server CGI, and coding a hand rolled database format would be a lot of extra work.
If it is using Win32 it might just be accessing a DAO database without using the mdb extension, which many companies do to make it look like a proprietary format you can't just open with MS Access. If you look at the raw data it might look crazy and unusable because JET databases use XOR to obfuscate the contents of the database file (and prevent you from extracting the strings inside).
I also have spent a long time dealing with FileMaker too and it can be a huge PITA. Be thankful you didn't have to maintain a FileMaker Pro Server or web server for many people!
It is very easy for non-tech savvy people to use to build a bunch of databases and start using them which is cool. The problem is that the databases have a very simple design and most people don't even know how to setup a relationship between two fields. They just drag and drop fields onto a form and let FileMaker figure out how to store and share the data.
Those databases then tend to evolve and as they get more complex they are harder to manage using the simple interface that FileMaker Pro tries to provide. One person's quick inventory tracking database suddenly becomes a massive asset database used by the whole company years down the road, and you're left struggling to keep it running.FileMaker Pro and Lotus Domino are the worst for this kind of thing.
IIRC there are a few ways to extract the data from FileMaker Pro databases. There is an ODBC driver that comes with the FileMaker Pro client (at least it did back in the 3.x and 4.x days). That would be the easiest way to extract the data for other applications to use. FileMaker Pro 4.0 used to also come with a web server plugin that would use CDML to generate dynamic web pages from the database (of course Claris HomePage was the best tool to nuild CDML apps at the time).
CGI works by having the server executes the program (passing the data to it from STDIN or the command line) and then retreiving the page's complete HTML code from STDOUT. You can use any file that can be executed and use STDIN/STDOUT in this manner that is located in a specified location(like cgi-bin). On Windows this would be any exe,com,pif,bat or cmd file, and the extension must be there for the operating system to determine that it is an executable. On Linux you can use any file that +x permissions, compiled binaries or scripts with a bang at the beginning, so it can have any extension you want (or none) for a CGI.
People used to write a lot of CGI applications in perl because of it's text processing capabilities, but there were many CGI's that were compiled programs (written in languages like C). At one point Microsoft was really pushing the idea of easily writing CGI applications in Visual Basic and hosting them with IIS.
CGI fell out of popularity in favor of embedded scripting like PHP and ASP which have much less overhead (they don't have to create a new process to service every user request and wait for it's output) and are much less complex for people to use (they don't require special directories or permissions).
I really like your idea of laying out the problems with IE6 to the end user and providing solutions for them to upgrade, but your other comments about people being spineless and greedy because they can't do the same makes you look like a fanatical asshole.
Your job as a developer is to develop code that meets the needs of your users and customers, not to dictate what you like to them and make an ideological stand. If you tell your boss or customers to fuck off because you don't like their browser then they find a developer who will do the job that they are fucking paying him to do. The end user doesn't give a shit about open standards or who follows them, they want to get shit done. Standards are nice but if they aren't laws, and we have to follow supply and demand if we want to feed our family and succeed in the real world.
Even Microsoft had to do shit like make sure Word could open WordPerfect documents and IE could open web pages built for Netscape. If they had told customers to fuck off because they wanted to do things the way they liked, no one would use their shit and they wouldn't be in the dominant position they are in today.
Yes you're comparing a string under a single thread in the same memory space. Now multiply the CPU time by the number of requests that probably go across the OpenID servers every second and also take shit like context switching and memory management into account. You can't assume a highly loaded server is the same as your workstation.
For example, on one of our Windows servers someone installed the J2RE which also runs an updater app when you login to your profile. It used 100MB of memory but it was almost entirely paged to disk so he thought it was ok. The problem was that it was a Citrix server which thousands of people logged to every day (each running a copy of the updater app). Pretty soon that 100MB of added up to gigabytes, consumed the entire size of the paging file, and the server started to run out of memory.
While it may sound strange to you, most people aren't interested in writing scripts and compiling source code on their iPhone.
Yes but Nintendo restricted unlicensed cartridges with their 10NES protection scheme. Any NES built after 1987 would would continually reset itself if it couldn't authenticate with a 10NES chip which was only included in licensed cartridges.
Hard disk parts can also become seized and have trouble starting if the drive is inactive for a lengthy amount of time. I'm not sure how long it takes or how often it happens though.
In the real world the manager justifies his job by cutting costs wherever he can. I've never seen a manager get rewarded for being proactive and spending a lot of money. If anything they'll ask him to reduce the IT budget this quarter because none of them know what the IT guy actually does.
BREW is an API layer which sits above the phone's native API in order to provide a consistent programming interface across various phones. You write BREW apps with C or C++ and compile them into binaries. BREW is basically just a wrapper which translates the BREW APU calls to the phone's internal low level API calls. It would actually be stupid to code all your apps for the phone's native API because it will be different on every single model of phone, and you would have to re-write them every time.
I haven't used IRC in a while but I don't ever remember it being very professional, and yes, anything the channel ops don't like gets you kicked (at least in the channels I used to hang out in). The fact that they gave him 30 minutes before kicking him from the channel is probably as professional as you can get.
He was typing weirdly, posting password hashes to main...he could be an RIAA agent in disguise, just some crazy guy threatening to hack them, he could be anybody. Channel operators aren't there to make friends with everyone in the channel, they are there to keep things in check.
There are some times when the underlying file system can matter, but the file sharing server must be aware of the limitations and deal with the problem transparently. If it doesn't, it can cause a lot of problems.
File streams are a pretty annoying problem when the underlying file system doesn't support them. Microsoft also stopped storing metadata in alternate data streams because people would copy them to file shares and would sometimes lose the ADS data. AppleShare is an even worse nightmare because many file systems strip the resource fork. Netatalk for Linux intelligently stores the streams as separate directories so they will work on file systems like ext2. Microsoft's Services for Macintosh doesn't do this kind of thing and will only work properly on NTFS which can store them directly in alternate data streams, which FAT doesn't support.
There are also various file permissions and attributes which depend on the file system. Newer versions of Windows file sharing supports NTFS style file/folder ACL's and Volume Shadow Copies which are not implemented the same on many other file systems. AppleTalk also expects all of the various bits of extra information stored on an HFS volume (like the file type and creator mappings).
It appears to me that the design and features of ZFS allow it to easily support the features of other file systems without a lot of extra work. If you had the NAS running something like ext3, I think the file servering services would probably have to do a lot more work translating those features to work correctly.
Whoa calm down! It doesn't matter if Linux actually infringes or not, corporations will still be leary about adoption as long as there are claims out there that it does. That it is the exact definition of encumbered, the adoption of Linux is impeded by a heavy load, that being the bad publicity from the SCO and Microsoft/Novell fiascos.
Do you remember this issue, when there was a BSD driver that was included in Linux and was re-licenced as GPL by mistake? Or how about this one, where the OpenBSD project stripped the comments from a GPL'd driver and re-licensed it as BSD? Obviously there are some copyright issues slipping through the cracks even among the different OSS projects. Since Linux has so many contributors from so many different places, it is easy for a company to start spreading claims that one piece, somewhere, might be infringing.
As soon as the corporate lawyers get wind of that kind of thing, they'll push to avoid adoption and to migrate solutions away from Linux. Look at the Unisys LZW patent in GIF files or the Fraunhofer patents in MP3 files. Companies were panicking because they might have an MP3 stored somewhere, without any understanding of the actual issue.
Are you kidding? Remember they have to go through US customs. Even the CIA wouldn't want to deal with those guys. They probably even give Obama the rough treatment!
You forgot about Chuck Norris.
Not if the MS Office license contains restrictions against it. When you legally bought MS Office all you really bought was a license that allows you to use the software. If you don't agree to the terms of the license, you can't install or use any of the software included on the Office disc. If Microsoft wanted to they could specify in the license that it can only be installed on Windows and that would be the end of using it (legally) under WINE.