The "leading IP lawyer in Australia" has obviously not actually studied the document:
"'I would be very surprised to see this upheld. It was a nice try on the part of (the FSF), but at this stage, I'd say it's not going to be an effective strategy. It will be tough to hold up in court.' In this case, she said, Microsoft never acted -- never 'entered' into the agreement, and the terms and conditions can only apply to new actions by Microsoft, not older ones. She said: 'Their actions so far are not enough to say that they are bound.'"
That is: Microsoft's *existing* agreement is immune to the GPL3 because it took place before the GPL3 was finalized.
Yes. That's correct. So what? WE ALREADY KNOW THIS. That's why the GPL3 contains THIS language: "You may not convey a covered work if you are a party to an arrangement with a third party that is in the business of distributing software, under which you make payment to the third party based on the extent of your activity of conveying the work, and under which the third party grants, to any of the parties who would receive the covered work from you, a discriminatory patent license (a) in connection with copies of the covered work conveyed by you (or copies made from those copies), or (b) primarily for and in connection with specific products or compilations that contain the covered work, unless you entered into that arrangement, or that patent license was granted, prior to 28 March 2007."
Not only that, but the GPL3 doesn't actually cover any of the software that Novell is currently shipping... it's all GPL2.
The "great insight" here is that the GPLs can't do something that it explicitly does not try and do, regarding software it doesn't even cover!
If Apple and AT&T OK this (and having it show up in Google Code is no evidence of that) that's great. It means a native SDK and the iPhone will become a real smartphone.
If not, it's going to be an arms race between the wily hackers (in the good sense) wedging apps into the beast, and AT&T detecting them and disabling user's accounts for quote-hacking-unquote (in the media sense).
"It almost certainly took them more effort to disable the feature than it would have to fix the broken code."
Leaving out a module? It's questionable whether they should be trying to hack some kind of limited uPnP compatibility into Zeroconf in the first place, especially if (as alleged) they're using it for "legacy NAT traversal"... this just screams "bad idea" to me.
They brag about how little they know compared to what it takes to keep a Windows machine happy
They brag about how little they NEED TO KNOW compared to what Windows users NEED TO KNOW.
The problem is that most Windows users are no better informed. They brag about how people who really do keep track of that stuff are "dumber" than the "dumb" users they want to be. They don't think they should have as much training as you need for a driver's license... even though they're operating a machine thousands of times more complex. This willful ignorance is not limited to Mac users by any means, and the gap between what Windows users DO know and what they NEED to know is vastly greater.
So they won't have the first idea of what to do when iChat suddenly breaks for no apparent reason.
"I mean, imagine the fallout if there was a bug that allowed malformed MS word documents being loaded by Office 2007 to result in security issues, and Microsoft responded by disabling the load feature."
Apple didn't disable Bonjour, they disabled one of the components of Bonjour. That's not like disabling loading, it's like refusing to load certain files.
There was a bug that allowed autoexec macros in MS Word documents being loaded by Office 97 to result in security issues, so Microsoft responded by making it impossible for a user to simply deactivate autoexec and forcing them to make the choice of completely disabling macros (to the point where it was impossible to even inspect the macros to see if they were safe), or leaving them all open.
This resulted in an increase in the incidence of infections.
Somehow Microsoft manages to avoid the kind of bad press that this kind of user abuse deserves.
Now will Apple disable "Open Safe Files after Downloading" in Safari, or at the very least stop treating SOFTWARE INSTALLERS, ZIP ARCHIVES, and DISK IMAGES as "Safe" files? OK, this isn't a Mack Truck sized hole like ActiveX (you can only drive *small* trucks through it) but it's still vastly dumb.
Now that Apple has disabled uPnP compatibility will the original anonymous extortionist reveal the hole that he claims he didn't want to reveal lest Apple come up with some excuse for not disabling whatever his hole was, or will we hear more FUD from him?
The serial console on the iPhone does not get you a shell, it gets you something akin to Open Firmware... something Apple has had since long before they were running UNIX. You also get the same interface from most routers and other network equipment, most minicomputers, many microcomputers other than Powermacs, gas pumps, automobile engine computers, and coffee machines. In fact, the kind of "serial based terminal interface" you' get from the iPhone is about as "not UNIX" as you can get over a serial port. To get a shell you have to install additional software on the iPhone to make the shell available. Apple goes to great lengths to make this impossible, and doing it violates your contract with AT&T and voids your warranty.
If you are willing to give up cellphone service (and even if you can manage to do this without being detected for the moment, don't bet on keeping that capability) then you can turn your iPhone into a UNIX handheld. You can also turn your iPaq and half a dozen other handhelds into UNIX handhelds by installing NetBSD or Linux on them, and you've been able to do this for years.
The fact that the iPhone has UNIX under the hood is irrelevant because you can not get to it without making your iPhone not an iPhone. To the typical user it's no more relevant that the fact that they can install Linux on their iPaq. They're not going to do it, and anyone who *is* going to do it doesn't need an iPhone to get to the same place. An old iPaq or a Zaurus is cheaper and you can actually get software for them. Hacking your iPhone is a party trick, not a useful tool.
Please read for content, goofball. You can't legitimately do anything with that command line. I'm better off with Linux on an iPaq plus a separate cellphone than you are with the bootleg debug console or ssh server that you voided your warranty and put your cellphone contract in jeopardy over.
But the Zaurus is also UNIX.
The Zaurus is *supported* UNIX.
The iPhone is *unsupported* UNIX, and that's nothing new... I've had unsupported UNIX on a handheld for years.
Yes, Mac OS X is more complex than the Classic Mac OS. Thank the Lord
I disagree. Classic Mac OS was built around an unnecessarily complex file system. NeXT came up with a superior solution to the problem that Mac OS file system was attempting to solve, a solution that worked on any OS, on even the most basic hierarchical file system... even FAT32. And if Apple had stuck with that solution and mapped the Classic dual-fork files into bundles then we wouldn't be faced with the current situation.
Other than complaining about some very well hidden filesystem bugs in HFS+ it doesn't seem like you've added anything to the conversation.
They're not "bugs in HFS+", they're design flaws in classic Mac OS that have been copied unnecessarily to OSX, and well, the bottom line is they really do cause problems:
I'm sure that making a bootable disk from a single-partition Linux system is technically just as easy as it is in Mac OS X. It's just that nobody ever took the time to make a tool that made it easy for normal people to actually do it, from beginning to end, with one click.
I've used CarbonCopyCloner, and that is not the tool you think it is. It can be rocket science to recover from a CCC image... I had to do it on my Macbook and it took a couple of software updates before Finder was behaving properly again. I never found exactly WHAT CCC had left undone, and in this situation I *do* qualify as a "rocket scientist".
Using some of the other recommended tools for cloning OSX produced even worse results. I didn't find out about SuperDuper until after it was too late, so I don't know if that would have done a better job or not... but given that there's several dozen tools available for OSX that claim they'll do this thing for you and all but *possibly* one of them don't get it right, I think you're giving it way too much credit. On FreeBSD I could have done "disklabel -B" and "cp -pR" and been guaranteed that the resulting system would boot and work, no ifs, ands, or buts. On OSX, Carbon Copy Cloner has to run a dozen separate "ditto" or (on Tiger or later) "cp -pR" commands... followed by "bless"... and you're still not guaranteed you'll be able to boot and use the resulting system.
So in actuality, it's close to impossible to accomplish this task with Linux without being a command-line guru.
And on OSX it's not certain that you'll accomplish it even if you ARE a command line guru, unless you're lucky enough to pick the *one* tool that is alleged to work reliably, *or* you're willing to try it half a dozen times.
It's really that simple, folks. I defy anyone to show me a way to do any of this so easily with Windows or Linux.
Carbon Copy Cloner is a wrapper around a command to make a disk bootable, plus a recursive copy.
That's all cloning *any* single-partition UNIX system takes. Linux is a bit more complex because they don't support single-stage booting so you need to run *two* commands to make a disk bootable, not just one.
The only reason you need a GUI program on OSX is because getting that "recursive copy" bit right is way too complex and tricky compared with the same operation on any other UNIX.
And it's a MAJOR step back from doing the same thing on classic Mac OS... *that* was a matter of a single drag in Finder, because they built that "make the disk bootable" operation into Finder. And they *still* haven't been able to make Finder copy all the fiddly metadata they keep whacking onto the side of HFS like a tumor.
Once I pick one OS I'm stuck, and moving is as hard as going to any other OS.
A little while back I took a program I wrote on Version 7 UNIX, on a 16-bit PDP-11, 25 years ago. I unpacked it on a 64-bit Alpha running Tru64, and it compiled and ran. Copied it to a 32-bit Sparc, big-endian, compiled, and it ran. Works fine on OSX and FreeBSD and Linux as well.
That was 25 years after I wrote it, and almost 20 years years since I'd last touched it... submitting it to a Usenet archive and forgetting about it for a couple of decades. Portable software isn't all that tough.
Not saying that the UNIX label is useful, mind, but the UNIX *design* works pretty damn well.
Linux didn't even exist when NeXTSTeP was developed, and the GPL would pretty much make Apple's business model impossible even if it had been around back then.
It's got nothing to do with Newton, Palm, Pocket PC, Symbian/EPOC devices, or any other smartphone or PDA, because you can't run anything but Apple's software on it.
It's basically a canned email/browser device like WebTV in a pocket form factor, with a handful of common organizer applications baked into the image, like Royal's old line of organizers.
The one thing that's always bugged me about the Mac and about NeXTstep is the way they make a fetish of making menus hard for the user.
Apple sticks the menus up at the top of the screen like we were all still on 9" Compact Macs. On a 30" monitor, or with two monitors, it's frustrating.
NeXTstep made the menus a vertical box that looked like another window and had all the charm of Apple's other bag-on-the-side-of-a-winow interface, the shelf.
Neither is ideal. I'd like to either make them a context menu on the title bar, or something like a menu bar on the window edge (one that can be dragged to any edge).
First, overlapping windows are often undesirable, users either maximize the current window or tile them.
I only typically find myself maximizing on small screens (less than 1024x768), or in UI environments that encourage tiling (Windows). On X11 or OSX I typically have a cluster of tiled Xterms, yes, but with other application windows overlapping all over the place. On X11, the window I'm working on often has other application's windows hovering over it, unfortunately Apple doesn't let you do that.
It's a shame that Apple's unable to get away from the click-to-focus/raise-on-focus model. I much prefer focus-follows-mouse and explicit-raise. If someone would come up with a hack to make the menu bar just a place to dock menu extras, and attach menus to the title bar of the application (but not the way NeXT did it, keep it a *bar*) or make them come up under the mouse (Fitt's Law notwithstanding... the easiest place to move the mouse to is where it already is!)... then you could change the focus and raise behaviour...
The other thing that I find useful is to make my windows slightly (maybe 10%) transparent, so I can see changes beneath them. So the window in the back with a download progress in it isn't actually hidden by the one in front. Extending this to real 3d is an obvious next step.
I've never used a MAC but have tried the various UI customisation packs available (for fun and because I was bored). I don't think that Etoile should be taken as a Mac-like Environment but more like a Mac UI customization package.
In fact that's exactly what it isn't. Not only can you not get a "mac-like" environment by changing the details of the UI, you can't even really get a "windows-like" environment that way... despite both KDE and Gnome borrowing so much from Windows. To get a real NeXT/Mac environment you need your applications to use GNUstep, so they inherit everything from Services on down from it. And to do that, you need people using it so there's a demand for it, and for that, you need someone to package the whole thing up in a cool and friendly way.
Making something "cool" around GNUstep is something I've been hoping would happen for some time.
Objective C is not the best OOPL, and NeXTstep is not the best class library, but the competition that's actually got wide use is so appallingly bad that they shine like costume jewelry in a pile of muck. Being able to write code that will compile and run natively on OS X and X11 polishes it up a treat.
The looks and theme aren't the point. NeXTstep was awfully drab too but it developed a devoted following not because it looked cool, but because it worked well and consistently across all applications, and that was a result of the language and libraries as much as Steve Jobs' legendary attitude.
There are a variety of cross-OS file systems out there.
This is also about a file system that sucks less.
ZFS certainly has many advantages, but then so do NTFS, HFS+, Ext*FS, ReiserFS, AdvFS, and so on. Of all the alternatives, UFS has proven itself less likely to gnaw its own guts out for one reason or another than just about anything else I've used over the almost 30 years that I've been in this racket. That's worth a little patching.
I believe that the same voices that have been calling for Microsoft products to better interoperate with open source products would voice their approval should the Open Source Initiative itself open up to more of the IT industry.
I think they'd voice their approval much quicker should Microsoft make a concerted effort to actually interoperate better with other products, open source or not. It's interoperation that is really the key... for example: back in the early '80s the yet-to-be-named open source community embraced UNIX not because it was open source - in fact at the time it wasn't - but because it was designed to be easy to interoperate with at every level.
It's not good enough to provide open source components that only actually work on top of your API, or to provide libraries that allow people to talk to your protocols through the cut-out of your system software, you need to open the black box and commit to supporting documented and non-proprietary wire protocols and file formats.
Otherwise what you've got is better described as an "open pit-trap".
Something Eric Allman wrote many moons ago. I found it and modified it to support "native" command line syntax on MS-DOS, VMS, and AmigaDOS, and added some support for improved self-documentation... and then Brad Appleton saw it and rapidly enhanced it to support a plethora of shells and interfaces until it took up 10 posts in comp.sources.misc.
The following two directories should bring it up to the latest version I know of.
This is not efficient, mind you. Command line parsing doesn't generally need to be efficient, even by my miserly standards, honed when a PDP-11 was something you hoped to upgrade to... some day...
Slashdot Mirror
Yes. That's correct. So what? WE ALREADY KNOW THIS. That's why the GPL3 contains THIS language: "You may not convey a covered work if you are a party to an arrangement with a third party that is in the business of distributing software, under which you make payment to the third party based on the extent of your activity of conveying the work, and under which the third party grants, to any of the parties who would receive the covered work from you, a discriminatory patent license (a) in connection with copies of the covered work conveyed by you (or copies made from those copies), or (b) primarily for and in connection with specific products or compilations that contain the covered work, unless you entered into that arrangement, or that patent license was granted, prior to 28 March 2007."
Not only that, but the GPL3 doesn't actually cover any of the software that Novell is currently shipping... it's all GPL2.
The "great insight" here is that the GPLs can't do something that it explicitly does not try and do, regarding software it doesn't even cover!
Sheesh.
What is this actually used for? Compatibility with uPNP or simply as a hack for NAT traversal of Bonjour by piggybacking on router uPNP support?
I'm not sure how Pierson v. Post applies here.
If Apple and AT&T OK this (and having it show up in Google Code is no evidence of that) that's great. It means a native SDK and the iPhone will become a real smartphone.
If not, it's going to be an arms race between the wily hackers (in the good sense) wedging apps into the beast, and AT&T detecting them and disabling user's accounts for quote-hacking-unquote (in the media sense).
This lesson here isn't "the webmail client was hacked, don't use gmail".
It was "unencrypted network connections are insecure, use SSL or SSH".
Using POP3 with Thunderbird would have simply made it easier for them, unless you used SSL.
Which you could do with gmail as well.
"It almost certainly took them more effort to disable the feature than it would have to fix the broken code."
Leaving out a module? It's questionable whether they should be trying to hack some kind of limited uPnP compatibility into Zeroconf in the first place, especially if (as alleged) they're using it for "legacy NAT traversal"... this just screams "bad idea" to me.
They brag about how little they know compared to what it takes to keep a Windows machine happy
They brag about how little they NEED TO KNOW compared to what Windows users NEED TO KNOW.
The problem is that most Windows users are no better informed. They brag about how people who really do keep track of that stuff are "dumber" than the "dumb" users they want to be. They don't think they should have as much training as you need for a driver's license... even though they're operating a machine thousands of times more complex. This willful ignorance is not limited to Mac users by any means, and the gap between what Windows users DO know and what they NEED to know is vastly greater.
So they won't have the first idea of what to do when iChat suddenly breaks for no apparent reason.
You didn't read the advisory, did you?
"I mean, imagine the fallout if there was a bug that allowed malformed MS word documents being loaded by Office 2007 to result in security issues, and Microsoft responded by disabling the load feature."
Apple didn't disable Bonjour, they disabled one of the components of Bonjour. That's not like disabling loading, it's like refusing to load certain files.
There was a bug that allowed autoexec macros in MS Word documents being loaded by Office 97 to result in security issues, so Microsoft responded by making it impossible for a user to simply deactivate autoexec and forcing them to make the choice of completely disabling macros (to the point where it was impossible to even inspect the macros to see if they were safe), or leaving them all open.
This resulted in an increase in the incidence of infections.
Somehow Microsoft manages to avoid the kind of bad press that this kind of user abuse deserves.
Now will Apple disable "Open Safe Files after Downloading" in Safari, or at the very least stop treating SOFTWARE INSTALLERS, ZIP ARCHIVES, and DISK IMAGES as "Safe" files? OK, this isn't a Mack Truck sized hole like ActiveX (you can only drive *small* trucks through it) but it's still vastly dumb.
Now that Apple has disabled uPnP compatibility will the original anonymous extortionist reveal the hole that he claims he didn't want to reveal lest Apple come up with some excuse for not disabling whatever his hole was, or will we hear more FUD from him?
The serial console on the iPhone does not get you a shell, it gets you something akin to Open Firmware... something Apple has had since long before they were running UNIX. You also get the same interface from most routers and other network equipment, most minicomputers, many microcomputers other than Powermacs, gas pumps, automobile engine computers, and coffee machines. In fact, the kind of "serial based terminal interface" you' get from the iPhone is about as "not UNIX" as you can get over a serial port. To get a shell you have to install additional software on the iPhone to make the shell available. Apple goes to great lengths to make this impossible, and doing it violates your contract with AT&T and voids your warranty.
If you are willing to give up cellphone service (and even if you can manage to do this without being detected for the moment, don't bet on keeping that capability) then you can turn your iPhone into a UNIX handheld. You can also turn your iPaq and half a dozen other handhelds into UNIX handhelds by installing NetBSD or Linux on them, and you've been able to do this for years.
The fact that the iPhone has UNIX under the hood is irrelevant because you can not get to it without making your iPhone not an iPhone. To the typical user it's no more relevant that the fact that they can install Linux on their iPaq. They're not going to do it, and anyone who *is* going to do it doesn't need an iPhone to get to the same place. An old iPaq or a Zaurus is cheaper and you can actually get software for them. Hacking your iPhone is a party trick, not a useful tool.
Serial port through the dock.
Please read for content, goofball. You can't legitimately do anything with that command line. I'm better off with Linux on an iPaq plus a separate cellphone than you are with the bootleg debug console or ssh server that you voided your warranty and put your cellphone contract in jeopardy over.
But the Zaurus is also UNIX.
The Zaurus is *supported* UNIX.
The iPhone is *unsupported* UNIX, and that's nothing new... I've had unsupported UNIX on a handheld for years.
Yes, Mac OS X is more complex than the Classic Mac OS. Thank the Lord
I disagree. Classic Mac OS was built around an unnecessarily complex file system. NeXT came up with a superior solution to the problem that Mac OS file system was attempting to solve, a solution that worked on any OS, on even the most basic hierarchical file system... even FAT32. And if Apple had stuck with that solution and mapped the Classic dual-fork files into bundles then we wouldn't be faced with the current situation.
Other than complaining about some very well hidden filesystem bugs in HFS+ it doesn't seem like you've added anything to the conversation.
They're not "bugs in HFS+", they're design flaws in classic Mac OS that have been copied unnecessarily to OSX, and well, the bottom line is they really do cause problems:
I'm sure that making a bootable disk from a single-partition Linux system is technically just as easy as it is in Mac OS X. It's just that nobody ever took the time to make a tool that made it easy for normal people to actually do it, from beginning to end, with one click.
I've used CarbonCopyCloner, and that is not the tool you think it is. It can be rocket science to recover from a CCC image... I had to do it on my Macbook and it took a couple of software updates before Finder was behaving properly again. I never found exactly WHAT CCC had left undone, and in this situation I *do* qualify as a "rocket scientist".
Using some of the other recommended tools for cloning OSX produced even worse results. I didn't find out about SuperDuper until after it was too late, so I don't know if that would have done a better job or not... but given that there's several dozen tools available for OSX that claim they'll do this thing for you and all but *possibly* one of them don't get it right, I think you're giving it way too much credit. On FreeBSD I could have done "disklabel -B" and "cp -pR" and been guaranteed that the resulting system would boot and work, no ifs, ands, or buts. On OSX, Carbon Copy Cloner has to run a dozen separate "ditto" or (on Tiger or later) "cp -pR" commands... followed by "bless"... and you're still not guaranteed you'll be able to boot and use the resulting system.
So in actuality, it's close to impossible to accomplish this task with Linux without being a command-line guru.
And on OSX it's not certain that you'll accomplish it even if you ARE a command line guru, unless you're lucky enough to pick the *one* tool that is alleged to work reliably, *or* you're willing to try it half a dozen times.
It's the end result that counts.
Yep. It's the end result that counts.
Not how many clicks it takes.
It's really that simple, folks. I defy anyone to show me a way to do any of this so easily with Windows or Linux.
Carbon Copy Cloner is a wrapper around a command to make a disk bootable, plus a recursive copy.
That's all cloning *any* single-partition UNIX system takes. Linux is a bit more complex because they don't support single-stage booting so you need to run *two* commands to make a disk bootable, not just one.
The only reason you need a GUI program on OSX is because getting that "recursive copy" bit right is way too complex and tricky compared with the same operation on any other UNIX.
And it's a MAJOR step back from doing the same thing on classic Mac OS... *that* was a matter of a single drag in Finder, because they built that "make the disk bootable" operation into Finder. And they *still* haven't been able to make Finder copy all the fiddly metadata they keep whacking onto the side of HFS like a tumor.
Once I pick one OS I'm stuck, and moving is as hard as going to any other OS.
A little while back I took a program I wrote on Version 7 UNIX, on a 16-bit PDP-11, 25 years ago. I unpacked it on a 64-bit Alpha running Tru64, and it compiled and ran. Copied it to a 32-bit Sparc, big-endian, compiled, and it ran. Works fine on OSX and FreeBSD and Linux as well.
That was 25 years after I wrote it, and almost 20 years years since I'd last touched it... submitting it to a Usenet archive and forgetting about it for a couple of decades. Portable software isn't all that tough.
Not saying that the UNIX label is useful, mind, but the UNIX *design* works pretty damn well.
Linux didn't even exist when NeXTSTeP was developed, and the GPL would pretty much make Apple's business model impossible even if it had been around back then.
Yeah, what a bummer it's just UNIX in a small form factor.
If you can't get a command line (legitimately), it's not UNIX in any meaningful sense.
Why don't you go rain all over the Zaurus user parade while you're at it?
Why should I? The iPhone's not a Zaurus either.
It's got nothing to do with Newton, Palm, Pocket PC, Symbian/EPOC devices, or any other smartphone or PDA, because you can't run anything but Apple's software on it.
It's basically a canned email/browser device like WebTV in a pocket form factor, with a handful of common organizer applications baked into the image, like Royal's old line of organizers.
The one thing that's always bugged me about the Mac and about NeXTstep is the way they make a fetish of making menus hard for the user.
Apple sticks the menus up at the top of the screen like we were all still on 9" Compact Macs. On a 30" monitor, or with two monitors, it's frustrating.
NeXTstep made the menus a vertical box that looked like another window and had all the charm of Apple's other bag-on-the-side-of-a-winow interface, the shelf.
Neither is ideal. I'd like to either make them a context menu on the title bar, or something like a menu bar on the window edge (one that can be dragged to any edge).
A pox on Apple for selling the iPhone with a sealed case that requires a technician to replace the battery.
A pox on anyone who didn't research the iPhone before spending six hundred bucks on it.
First, overlapping windows are often undesirable, users either maximize the current window or tile them.
I only typically find myself maximizing on small screens (less than 1024x768), or in UI environments that encourage tiling (Windows). On X11 or OSX I typically have a cluster of tiled Xterms, yes, but with other application windows overlapping all over the place. On X11, the window I'm working on often has other application's windows hovering over it, unfortunately Apple doesn't let you do that.
It's a shame that Apple's unable to get away from the click-to-focus/raise-on-focus model. I much prefer focus-follows-mouse and explicit-raise. If someone would come up with a hack to make the menu bar just a place to dock menu extras, and attach menus to the title bar of the application (but not the way NeXT did it, keep it a *bar*) or make them come up under the mouse (Fitt's Law notwithstanding... the easiest place to move the mouse to is where it already is!)... then you could change the focus and raise behaviour...
The other thing that I find useful is to make my windows slightly (maybe 10%) transparent, so I can see changes beneath them. So the window in the back with a download progress in it isn't actually hidden by the one in front. Extending this to real 3d is an obvious next step.
I've never used a MAC but have tried the various UI customisation packs available (for fun and because I was bored). I don't think that Etoile should be taken as a Mac-like Environment but more like a Mac UI customization package.
In fact that's exactly what it isn't. Not only can you not get a "mac-like" environment by changing the details of the UI, you can't even really get a "windows-like" environment that way... despite both KDE and Gnome borrowing so much from Windows. To get a real NeXT/Mac environment you need your applications to use GNUstep, so they inherit everything from Services on down from it. And to do that, you need people using it so there's a demand for it, and for that, you need someone to package the whole thing up in a cool and friendly way.
Which is where Etoile comes in.
Making something "cool" around GNUstep is something I've been hoping would happen for some time.
Objective C is not the best OOPL, and NeXTstep is not the best class library, but the competition that's actually got wide use is so appallingly bad that they shine like costume jewelry in a pile of muck. Being able to write code that will compile and run natively on OS X and X11 polishes it up a treat.
The looks and theme aren't the point. NeXTstep was awfully drab too but it developed a devoted following not because it looked cool, but because it worked well and consistently across all applications, and that was a result of the language and libraries as much as Steve Jobs' legendary attitude.
There are a variety of cross-OS file systems out there.
This is also about a file system that sucks less.
ZFS certainly has many advantages, but then so do NTFS, HFS+, Ext*FS, ReiserFS, AdvFS, and so on. Of all the alternatives, UFS has proven itself less likely to gnaw its own guts out for one reason or another than just about anything else I've used over the almost 30 years that I've been in this racket. That's worth a little patching.
I believe that the same voices that have been calling for Microsoft products to better interoperate with open source products would voice their approval should the Open Source Initiative itself open up to more of the IT industry.
I think they'd voice their approval much quicker should Microsoft make a concerted effort to actually interoperate better with other products, open source or not. It's interoperation that is really the key... for example: back in the early '80s the yet-to-be-named open source community embraced UNIX not because it was open source - in fact at the time it wasn't - but because it was designed to be easy to interoperate with at every level.
It's not good enough to provide open source components that only actually work on top of your API, or to provide libraries that allow people to talk to your protocols through the cut-out of your system software, you need to open the black box and commit to supporting documented and non-proprietary wire protocols and file formats.
Otherwise what you've got is better described as an "open pit-trap".
The following two directories should bring it up to the latest version I know of.
This is not efficient, mind you. Command line parsing doesn't generally need to be efficient, even by my miserly standards, honed when a PDP-11 was something you hoped to upgrade to... some day...
ftp://ftp.uu.net/usenet/comp.sources.misc/volume2
ftp://ftp.uu.net/usenet/comp.sources.misc/volume3
http://www.cmcrossroads.com/bradapp/ftp/src/libs/
http://www.cmcrossroads.com/bradapp/ftp/src/libs/