I haven't seen anyone (save a few Slashdot trolls) seriously argue that binary-only software is inherently more secure, either in theory or in practice. So at first it sounds like Mr Diffie is setting up a straw man at the beginning of his article. But then you realize that the 'opponents' are not serious arguments but, on the whole, vague FUD wafting about that may be swallowed by less-technical people. So his article is an attempt to explain to the rest of the world what the security industry already knew.
Just to clarify: I meant that mozilla itself is not a derivative work of Slashdot merely because it _can_ contact the Slashdot site and download some HTML. Whereas in the opinion of the FSF and others, a program which can and does load (say) the Qt library at run time is a derivative work of Qt. The difference is between calling a published 'external' interface (such as http) and making the other program directly part of your own code (such as by linking it into a single executable, whether at compile time or dynamically).
In a way I agree with what some other posters said, even though they are getting away from the original point: if you loaded up ggv and viewed a PDF file, then did a core dump of the ggv process viewing the PDF, this code dump would be a derivative work of both ggv and the document. However ggv itself, as an executable or whatever, is not a derivative work of the PDF document just because it _can_ load and display the file.
Your difficulty is not that you don't understand the GPL; it's that you don't understand what a derivative work is. That is defined by copyright law (statue and, mostly, precedent) and it's not really the GPL's fault that it is unclear.
There is the language in the GPL about 'mere aggregation' not counting as a derivative work, and I guess this could cover your two-classes-in-the-same-jar example.
The FSF's opinion, I think, is that linking (whether run-time or compile-time) makes a derived work, but calling via an XML-RPC interface or similar does not. (Otherwise my web browser would be a derivative work of Slashdot.) In the worst case, you can ask the software's copyright holder for clarification of what he or she counts as a derivative work.
If the two languages are almost identical can't you just use a bunch of sed scripts to turn nb into some kind of nn? Maybe not the best literary nn but good enough to get around the law.
In principle a version control system doesn't need to use diff at all. It could just store each revision of each file in full. That's probably what I would do if I implemented a VCS myself. Then if disk space gets tight, there can be a daemon which converts some of the complete copies into diffs against the latest version. But that doesn't need to happen on every checkin.
An interesting alternative to storing diffs, but still saving disk space, is to use compression such as bzip2 to squeeze redundancy between the different versions. If you concatenate all the different revisions in a single file and then compress it, you'll probably use just as little space as compressing an RCS file or other collection of diffs. But it might be too slow to do this in practice.
You can get atomic checkins with CVS: just lock the repository before making the commit and unlock it afterwards. Karl Fogel's book explains somewhere how to do this. You don't get rollback though.
In an ideal world I would want to run the whole test suite before each checkin. (Whether or not I was using Aegis or some other version control system). But running a complete set of tests involves doing a complete build, perhaps even more than one build, and it would take far too long to wait for tests to run before your changes are checked in.
It would be great to have some kind of automated testing system that watches the checkins and runs tests 24 hours a day. Instead of running the test suite for every single checkin, it picks the current head revision of the project, tags it, and runs the tests. If they all pass then this revision is marked as the 'last known good' - there may have been other checkins in the meantime. Then repeat with the current head revision.
If a test fails, then it might not be immediately possible to work out what change set was responsible. There might have been a whole load of stuff committed between the last known good version and the version currently being tested. But the testing tool can work forwards from the good revision one change set at a time to find the guilty party, and send them mail about the problem. Or to be a bit quicker, use binary search to find the point where one of the tests broke.
Why does it matter what kind of diff the version control system uses internally - 'crude' or otherwise? You shouldn't need to care about such details.
The disk space argument is valid I suppose. But what would _really_ save disk space is a way to compress the source repository, either everything or just the older revisions. My $CVSROOT directory is huge and most of that is stuff I will probably never need to access.
Or if space is really tight, a way to selectively forget about older revisions. I have a bunch of very large text files under version control, in fact they are word lists for ispell(1) and similar programs. An operation like sorting the list into alphabetical order generates a huge diff, but the log message is entirely sufficient to describe the change. I'd like to cut out some of the version history so that only log messages are preserved for older versions - you wouldn't be able to check them out, but I wouldn't want to anyway. So far the only way I can see to do this is to hack the RCS files by hand.
Let me respond to your posting and try to work out a list of sites. As you say, gnusoftware.org is down and has been for quite some time. The links on opensource.org aren't a great deal of use but I did find O'Reilly OSDir's Windows section with 18 apps listed, and BerliOS's Windows category with 11 projects. OSSBlacksheep is just a CD you can buy with some free software for Windows - similar to some mentioned on Slashdot recently.
More useful than these is the old favourite Cygwin, a Unix-on-Win32 layer with gcc and tools, and its offshoot Mingw (aka Ming, Mingw32, Minimalist GNU-Win32) which is a native gcc and toolchain, without a Unix emulation layer. You can use Cygwin to port lots of Unix apps, and you can use Mingw to build the Win32 ports of things like perl and Mozilla. Actually I don't think you need both since Cygwin's gcc can build native executables too, but Mingw is slightly 'cleaner' if you have no need for emulated symlinks and other cruft.
Hmm, what else can I think of? Well a lot of the big applications like Emacs and Mozilla have native Win32 ports. Don't forget the old DOS stuff, DJGPP which is a GNU-based development environment for DOS - everything except fork()!. There used to be a rival called EMX but it seems to have faded away.
You're right that allowing Windows free software on Freshmeat but not Windows proprietary software is something of a double standard; but then so is allowing PalmOS (a wholly proprietary platform and not Unix). I don't think anyone expects Freshmeat to hold to a particular set of principles, it's above all a practical and useful site. So allowing Windows software but only when it is free might be a pragmatic compromise.
Maybe one day, one of the Freshmeat staff will be forced to use a Windows box for a few months, and then I'd expect a Windows section to appear pretty rapidly:-).
It's a fair point, why is an app built using the GNOME libraries any less platform-specific than one built with Carbon? I would say because GNOME itself is portable (both in theory and in practice) while Carbon is tied to one platform and operating system, and not available on Unix in general.
'If it runs on a Unix machine it is Unix software' - by that definition Microsoft Office is Unix software since you can run it using Crossover Office (and almost as well using Wine).
I have this vague notion of a program fitting into the whole 'Unix thang'. So if for example someone implemented a new version of getty which ran only on Mac OS X, it would be Unix software. But a Mac Classic application which can also be run on OS X via an emulation layer is not Unix software. This definition is not much good, I admit - but I think your definition is too broad to be useful. Perhaps we can conclude that 'Unix software' is not something you can define exactly.
You have to wonder why Apple bothered with Mach at all, why they didn't just take FreeBSD. Perhaps management or hired ex-Next developers were committed to the idea that microkernels are kewl.
Genetic information? I thought that gene sequences and stuff were fairly small, as in a couple of CDs for a typical organism.
A complete record of everything in your life so far - as will happen once phones all have full-motion video cameras, and are left on all the time - could easily fill a terabyte however.
- The Mac OS X GUI is not X11 or even vaguely related to it;
- Graphical applications written for Mac OS X will not run on other Unixes, even those that have XFree86.
This last point seems the most important to me - sure you _can_ disregard the native windowing system, compile an X server and libraries and run only X11 applications. You can do that on Windows too. But the Mac's standard user interface, the one that 99% of its users run, is not X11 and not particularly Unix-like.
Yes, I know that under some definitions Linux is not 'Unix' either. That is my whole point, that trying to include or exclude operating systems based on whether they are 'Unix' or not is silly. Almost any system can be classified as 'Unix' by some criterion or another - even MS-DOS with DJGPP has a fairly complete Unix environment. Freshmeat should just accept software for all platforms.
If the Freshmeat admins are too busy to cope with Windows software releases, that's a fairly good reason.
But how about free software for Windows? There isn't yet a good site for that, not that I know of; the 'software download sites for Windows' are pretty lame and focused on binary-only applications. This is a similar business-vs-geeks distinction as you point out for PalmOS (except here it's more Joe User vs geeks).
The amount of free software for Windows is growing, but still tiny compared to the amount of stuff you'll find on download.com.
I keep trying to sample my collection of BBC Micro software on tape and find a program to convert it to files. Apparently it is possible to read the sound in software and write a dump suitable for an emulator. I just need to figure out how to record sound under Linux on my hardware (builtin sound on A7V333).
It's easy for the Freshmeat editors to weed out the Windows-only projects, at least for those that have Trove categorization. If they want to delete NTRawrite from the database they can. For consistency, they ought also to delete all the PalmOS-only applications and anything else which doesn't run on a Unix system.
Hmm... I would say that Cygwin shouldn't be on the site since it runs only on Windows, but I guess it counts as a kind of 'Unix kernel' by itself so it's worth listing on a soi-disant Unix software site.
I agree that Windows is not an acceptable Unix even with Cygwin... but give me an unacceptable Unix over 'no Unix at all' any day:-P. If you have to use a Windows box then Cygwin and the related programs help make it usable. It would be very handy to have Freshmeat list all the free software which is available on Windows (and not just projects which have or are Unix ports).
Several years ago I installed a crappy X server (the now-payware MI/X) on a Windows box and was amazed to find that a local xterm running in the X server was much much faster at scrolling than NT's own terminal window. I agree that a decent local terminal is lacking.
Pehaps PuTTY could be modified to start a local connection and run text-mode programs... the trouble is that so many text-mode programs don't use ANSI codes to update the screen but rather some kind of direct access (either because they are DOS programs, or by using some kind of screen update API), so they cannot be tunnelled over a text connection. You'll find this out if you try to telnet or ssh to a Windows box and run some familiar apps like edit.com.
Is there a Windows X server which displays each window as a native window, rather than having the whole desktop in one window? I think this is called 'rootless' mode. I know about Exceed which does a good job but is payware. If there is a free X server which can make individual windows, then running xterm locally might be bearable.
I agree that Win32 does not fit in with what's listed on Freshmeat's About page. I would suggest allowing Windows software on the site - in which case that web page would change too.
I'm still not entirely happy about Mac OS X for this reason. A typical Mac OS X application - like, say, Microsoft Word for Mac OS X - will not work on any other Unix system. Even if the source were available it wouldn't work. (Unless someone who knows more about GNUstep can correct me on this.) So you have a 'Unix' system where most of the applications will not run on any other 'Unix' system. That seems wrong somehow.
Does Freshmeat accept application entries for Macintosh programs that do not use any Unix APIs, do not run on any Unix system other than the Mac, and do not follow a Unix style of user interface? If so, how does this qualify as 'Unix software'?
Replying to my own post, I think a better example than Mac OS X is PalmOS. There's no way that you could reasonably count PalmOS as a Unixlike operating system (or at least, any such definition would be so broad it would have to include almost any modern OS). Yet Freshmeat happily lists PalmOS-only software. Windows software? Oh no, we can't have that, this is a Unix site.
Please, Freshmeat, consider ditching the Unix bias (particularly as a large chunk of Mac OS X applications will not run on any other Unix system) and accepting submissions for software running on all operating systems, even that one from Redmond we're not supposed to like.
I was using the word Unix (not UNIX) loosely to mean the whole package of tools you normally expect on a Unix box - which includes the X window system, a C compiler and development tools like bison which are associated with Unix systems, perhaps an ssh client and server... it's a fairly loose definition I admit.
Perhaps the best definition of 'Unix' is that from Debian's definition of an important package - an important package is one where an experienced user sitting down at a box and finding it lacking this package would grumble and ask 'where the heck is foo?'. So you or I might say 'where the heck is awk?' if we found a supposedly Unix-like system which lacked it. Therefore having awk is some part of being a Unix system (though not the most important). X11 is another part, I believe.
The two criteria I listed - trademarking and POSIX - both classify Mac OS X as Unix. But they are clearly inadequate, since the first excludes Linux and the second includes Windows NT. At least, they are inadequate if you're trying to find a classification that justifies including Mac software but excluding Windows software.
I agree that Mac OS X should be included in Freshmeat. But not because a panel of experts has decided to classify the system as 'Unix'. Include it in Freshmeat because it's a good OS that many people use, and there's a lot of software for it!
My statement pointing out similarities between Mac OS X and Unix was not intending to show that OS X isn't Unix-like. Although it did show that the definition of Unix-like *depends on what criteria you choose*.
My whole argument is that the term 'Unix-like' is open to a lot of interpretation and can be used more as an excuse for including or excluding a particular platform - rather than as a logical test determining what platforms to pick. There are different definitions, some of them include the Macintosh, some even include Windows.
Lastly, I was suggesting that Freshmeat could become 'an index of useful software' rather than 'an index of Unix and cross-platform software'.
I guess the interesting test is when someone submits a Mac Classic application which happens to run on Mac OS X. That would definitely not be Unix software, any more than a Windows app which happens to run under Wine (and at least Wine is itself moderately cross-platform and available on several Unixes).
So how is the filesystem managed? I imagine there are some applications which run on top of Mach (with layers like 'Mac Classic' in between) and some BSD applications. Yet they share the same filesystem.
Slashdot Mirror
I haven't seen anyone (save a few Slashdot trolls) seriously argue that binary-only software is inherently more secure, either in theory or in practice. So at first it sounds like Mr Diffie is setting up a straw man at the beginning of his article. But then you realize that the 'opponents' are not serious arguments but, on the whole, vague FUD wafting about that may be swallowed by less-technical people. So his article is an attempt to explain to the rest of the world what the security industry already knew.
Scientists tried before to sequence banana, but they didn't know when to stop.
Just to clarify: I meant that mozilla itself is not a derivative work of Slashdot merely because it _can_ contact the Slashdot site and download some HTML. Whereas in the opinion of the FSF and others, a program which can and does load (say) the Qt library at run time is a derivative work of Qt. The difference is between calling a published 'external' interface (such as http) and making the other program directly part of your own code (such as by linking it into a single executable, whether at compile time or dynamically).
In a way I agree with what some other posters said, even though they are getting away from the original point: if you loaded up ggv and viewed a PDF file, then did a core dump of the ggv process viewing the PDF, this code dump would be a derivative work of both ggv and the document. However ggv itself, as an executable or whatever, is not a derivative work of the PDF document just because it _can_ load and display the file.
Your difficulty is not that you don't understand the GPL; it's that you don't understand what a derivative work is. That is defined by copyright law (statue and, mostly, precedent) and it's not really the GPL's fault that it is unclear.
There is the language in the GPL about 'mere aggregation' not counting as a derivative work, and I guess this could cover your two-classes-in-the-same-jar example.
The FSF's opinion, I think, is that linking (whether run-time or compile-time) makes a derived work, but calling via an XML-RPC interface or similar does not. (Otherwise my web browser would be a derivative work of Slashdot.) In the worst case, you can ask the software's copyright holder for clarification of what he or she counts as a derivative work.
If the two languages are almost identical can't you just use a bunch of sed scripts to turn nb into some kind of nn? Maybe not the best literary nn but good enough to get around the law.
'Reimplementing the entire Unix API and tools using "Free" code seems like an extraordinary waste of effort...'
In principle a version control system doesn't need to use diff at all. It could just store each revision of each file in full. That's probably what I would do if I implemented a VCS myself. Then if disk space gets tight, there can be a daemon which converts some of the complete copies into diffs against the latest version. But that doesn't need to happen on every checkin.
An interesting alternative to storing diffs, but still saving disk space, is to use compression such as bzip2 to squeeze redundancy between the different versions. If you concatenate all the different revisions in a single file and then compress it, you'll probably use just as little space as compressing an RCS file or other collection of diffs. But it might be too slow to do this in practice.
You can get atomic checkins with CVS: just lock the repository before making the commit and unlock it afterwards. Karl Fogel's book explains somewhere how to do this. You don't get rollback though.
In an ideal world I would want to run the whole test suite before each checkin. (Whether or not I was using Aegis or some other version control system). But running a complete set of tests involves doing a complete build, perhaps even more than one build, and it would take far too long to wait for tests to run before your changes are checked in.
It would be great to have some kind of automated testing system that watches the checkins and runs tests 24 hours a day. Instead of running the test suite for every single checkin, it picks the current head revision of the project, tags it, and runs the tests. If they all pass then this revision is marked as the 'last known good' - there may have been other checkins in the meantime. Then repeat with the current head revision.
If a test fails, then it might not be immediately possible to work out what change set was responsible. There might have been a whole load of stuff committed between the last known good version and the version currently being tested. But the testing tool can work forwards from the good revision one change set at a time to find the guilty party, and send them mail about the problem. Or to be a bit quicker, use binary search to find the point where one of the tests broke.
Why does it matter what kind of diff the version control system uses internally - 'crude' or otherwise? You shouldn't need to care about such details.
The disk space argument is valid I suppose. But what would _really_ save disk space is a way to compress the source repository, either everything or just the older revisions. My $CVSROOT directory is huge and most of that is stuff I will probably never need to access.
Or if space is really tight, a way to selectively forget about older revisions. I have a bunch of very large text files under version control, in fact they are word lists for ispell(1) and similar programs. An operation like sorting the list into alphabetical order generates a huge diff, but the log message is entirely sufficient to describe the change. I'd like to cut out some of the version history so that only log messages are preserved for older versions - you wouldn't be able to check them out, but I wouldn't want to anyway. So far the only way I can see to do this is to hack the RCS files by hand.
Let me respond to your posting and try to work out a list of sites. As you say, gnusoftware.org is down and has been for quite some time. The links on opensource.org aren't a great deal of use but I did find O'Reilly OSDir's Windows section with 18 apps listed, and BerliOS's Windows category with 11 projects. OSSBlacksheep is just a CD you can buy with some free software for Windows - similar to some mentioned on Slashdot recently.
More useful than these is the old favourite Cygwin, a Unix-on-Win32 layer with gcc and tools, and its offshoot Mingw (aka Ming, Mingw32, Minimalist GNU-Win32) which is a native gcc and toolchain, without a Unix emulation layer. You can use Cygwin to port lots of Unix apps, and you can use Mingw to build the Win32 ports of things like perl and Mozilla. Actually I don't think you need both since Cygwin's gcc can build native executables too, but Mingw is slightly 'cleaner' if you have no need for emulated symlinks and other cruft.
Hmm, what else can I think of? Well a lot of the big applications like Emacs and Mozilla have native Win32 ports. Don't forget the old DOS stuff, DJGPP which is a GNU-based development environment for DOS - everything except fork()!. There used to be a rival called EMX but it seems to have faded away.
You're right that allowing Windows free software on Freshmeat but not Windows proprietary software is something of a double standard; but then so is allowing PalmOS (a wholly proprietary platform and not Unix). I don't think anyone expects Freshmeat to hold to a particular set of principles, it's above all a practical and useful site. So allowing Windows software but only when it is free might be a pragmatic compromise.
Maybe one day, one of the Freshmeat staff will be forced to use a Windows box for a few months, and then I'd expect a Windows section to appear pretty rapidly :-).
It's a fair point, why is an app built using the GNOME libraries any less platform-specific than one built with Carbon? I would say because GNOME itself is portable (both in theory and in practice) while Carbon is tied to one platform and operating system, and not available on Unix in general.
'If it runs on a Unix machine it is Unix software' - by that definition Microsoft Office is Unix software since you can run it using Crossover Office (and almost as well using Wine).
I have this vague notion of a program fitting into the whole 'Unix thang'. So if for example someone implemented a new version of getty which ran only on Mac OS X, it would be Unix software. But a Mac Classic application which can also be run on OS X via an emulation layer is not Unix software. This definition is not much good, I admit - but I think your definition is too broad to be useful. Perhaps we can conclude that 'Unix software' is not something you can define exactly.
You have to wonder why Apple bothered with Mach at all, why they didn't just take FreeBSD. Perhaps management or hired ex-Next developers were committed to the idea that microkernels are kewl.
Genetic information? I thought that gene sequences and stuff were fairly small, as in a couple of CDs for a typical organism.
A complete record of everything in your life so far - as will happen once phones all have full-motion video cameras, and are left on all the time - could easily fill a terabyte however.
Yes, you can compile XFree86 on Mac OS X. But:
- Mac OS X does not include X11;
- The Mac OS X GUI is not X11 or even vaguely related to it;
- Graphical applications written for Mac OS X will not run on other Unixes, even those that have XFree86.
This last point seems the most important to me - sure you _can_ disregard the native windowing system, compile an X server and libraries and run only X11 applications. You can do that on Windows too. But the Mac's standard user interface, the one that 99% of its users run, is not X11 and not particularly Unix-like.
Yes, I know that under some definitions Linux is not 'Unix' either. That is my whole point, that trying to include or exclude operating systems based on whether they are 'Unix' or not is silly. Almost any system can be classified as 'Unix' by some criterion or another - even MS-DOS with DJGPP has a fairly complete Unix environment. Freshmeat should just accept software for all platforms.
If the Freshmeat admins are too busy to cope with Windows software releases, that's a fairly good reason.
But how about free software for Windows? There isn't yet a good site for that, not that I know of; the 'software download sites for Windows' are pretty lame and focused on binary-only applications. This is a similar business-vs-geeks distinction as you point out for PalmOS (except here it's more Joe User vs geeks).
The amount of free software for Windows is growing, but still tiny compared to the amount of stuff you'll find on download.com.
I keep trying to sample my collection of BBC Micro software on tape and find a program to convert it to files. Apparently it is possible to read the sound in software and write a dump suitable for an emulator. I just need to figure out how to record sound under Linux on my hardware (builtin sound on A7V333).
It's easy for the Freshmeat editors to weed out the Windows-only projects, at least for those that have Trove categorization. If they want to delete NTRawrite from the database they can. For consistency, they ought also to delete all the PalmOS-only applications and anything else which doesn't run on a Unix system.
Hmm... I would say that Cygwin shouldn't be on the site since it runs only on Windows, but I guess it counts as a kind of 'Unix kernel' by itself so it's worth listing on a soi-disant Unix software site.
:-P. If you have to use a Windows box then Cygwin and the related programs help make it usable. It would be very handy to have Freshmeat list all the free software which is available on Windows (and not just projects which have or are Unix ports).
I agree that Windows is not an acceptable Unix even with Cygwin... but give me an unacceptable Unix over 'no Unix at all' any day
Several years ago I installed a crappy X server (the now-payware MI/X) on a Windows box and was amazed to find that a local xterm running in the X server was much much faster at scrolling than NT's own terminal window. I agree that a decent local terminal is lacking.
Pehaps PuTTY could be modified to start a local connection and run text-mode programs... the trouble is that so many text-mode programs don't use ANSI codes to update the screen but rather some kind of direct access (either because they are DOS programs, or by using some kind of screen update API), so they cannot be tunnelled over a text connection. You'll find this out if you try to telnet or ssh to a Windows box and run some familiar apps like edit.com.
Is there a Windows X server which displays each window as a native window, rather than having the whole desktop in one window? I think this is called 'rootless' mode. I know about Exceed which does a good job but is payware. If there is a free X server which can make individual windows, then running xterm locally might be bearable.
I agree that Win32 does not fit in with what's listed on Freshmeat's About page. I would suggest allowing Windows software on the site - in which case that web page would change too.
I'm still not entirely happy about Mac OS X for this reason. A typical Mac OS X application - like, say, Microsoft Word for Mac OS X - will not work on any other Unix system. Even if the source were available it wouldn't work. (Unless someone who knows more about GNUstep can correct me on this.) So you have a 'Unix' system where most of the applications will not run on any other 'Unix' system. That seems wrong somehow.
Does Freshmeat accept application entries for Macintosh programs that do not use any Unix APIs, do not run on any Unix system other than the Mac, and do not follow a Unix style of user interface? If so, how does this qualify as 'Unix software'?
Replying to my own post, I think a better example than Mac OS X is PalmOS. There's no way that you could reasonably count PalmOS as a Unixlike operating system (or at least, any such definition would be so broad it would have to include almost any modern OS). Yet Freshmeat happily lists PalmOS-only software. Windows software? Oh no, we can't have that, this is a Unix site. Please, Freshmeat, consider ditching the Unix bias (particularly as a large chunk of Mac OS X applications will not run on any other Unix system) and accepting submissions for software running on all operating systems, even that one from Redmond we're not supposed to like.
I was using the word Unix (not UNIX) loosely to mean the whole package of tools you normally expect on a Unix box - which includes the X window system, a C compiler and development tools like bison which are associated with Unix systems, perhaps an ssh client and server... it's a fairly loose definition I admit.
Perhaps the best definition of 'Unix' is that from Debian's definition of an important package - an important package is one where an experienced user sitting down at a box and finding it lacking this package would grumble and ask 'where the heck is foo?'. So you or I might say 'where the heck is awk?' if we found a supposedly Unix-like system which lacked it. Therefore having awk is some part of being a Unix system (though not the most important). X11 is another part, I believe.
The two criteria I listed - trademarking and POSIX - both classify Mac OS X as Unix. But they are clearly inadequate, since the first excludes Linux and the second includes Windows NT. At least, they are inadequate if you're trying to find a classification that justifies including Mac software but excluding Windows software.
I agree that Mac OS X should be included in Freshmeat. But not because a panel of experts has decided to classify the system as 'Unix'. Include it in Freshmeat because it's a good OS that many people use, and there's a lot of software for it!
My statement pointing out similarities between Mac OS X and Unix was not intending to show that OS X isn't Unix-like. Although it did show that the definition of Unix-like *depends on what criteria you choose*.
My whole argument is that the term 'Unix-like' is open to a lot of interpretation and can be used more as an excuse for including or excluding a particular platform - rather than as a logical test determining what platforms to pick. There are different definitions, some of them include the Macintosh, some even include Windows.
Lastly, I was suggesting that Freshmeat could become 'an index of useful software' rather than 'an index of Unix and cross-platform software'.
I guess the interesting test is when someone submits a Mac Classic application which happens to run on Mac OS X. That would definitely not be Unix software, any more than a Windows app which happens to run under Wine (and at least Wine is itself moderately cross-platform and available on several Unixes).
So how is the filesystem managed? I imagine there are some applications which run on top of Mach (with layers like 'Mac Classic' in between) and some BSD applications. Yet they share the same filesystem.
Yeah, you can also run an X server on top of Windows and port a whole bunch of X11 software (normally using Cygwin, but sometimes without).