Granted, it is their software, however, it could be (and occasionally is) software created by other companies.
Very few companies, and almost none since the '80s, provide a mechanism for scripts or other embedded code in an untrusted document to run with local user privileges. It's not even that they do a better job of restricting active content to trusted documents... rather, they simply don't provide a mechanism for macros (Javascript, VBscript, Word macros,...) or embedded objects (ActiveX, COM objects,...) to execute outside a sandbox at all.
Microsoft's spent an enormous amount of effort on schemes to try and make it safe to install and run, or run directly, unrestricted applets and scripts embedded in web pages, word documents, and so on. And has utterly failed in coming up with a safe way to do this inherently unsafe thing.
I don't know anyone else who's done anything even close to this in the past decade, let alone kept it in place and intact against an agreement they made with the US Department of Justice. Microsoft's arrogant naivete really is unique in the IT world.
Because most users have the ability to log in as root/admin due to management oversight/ignorance.
This is a secondary problem. Keeping users from having Administrator rights would be a good thing, but the local desktop security on Windows isn't really that great, and even if it was solid there's just so many ways a worm can propogate among a pool of computers without ever saving itself to persistent storage, let alone hiding in a system rather than user executable, that the problems caused by Microsoft's "Security Zones" model makes this one pale into insignificance.
Concentrate on reducing the surface area for attacks, it's a much bigger win than improving local security or antivirus software or whatever...
Basically, Microsoft's desktop has been unbelievably open to content-based attacks like this. Originally it was just Word macros having too many rights (which may be what's going on here, as well). When Active Desktop was introduced and the Microsoft HTML control was put in the position of being a "gatekeeper" for internet security things got MUCH worse VERY quickly.
So, well, avoiding content-based attacks on Windows requires (ironically) avoiding as many Microsoft applications as possible, or any applications that use the HTML control (Microsoft or not... Realplayer is one I'm leary of), or support Microsoft's scripting tools.
Word is just the tip of the iceberg. It used to be the poster boy for this problem, but it's been a long time since it's been in the limelight. Internet Explorer and Outlook are the usual victims these days.
Should every Lenovo laptop be inspected before use in government offices, just in case some enterprising intelligence officer in the PLA is really that stupid?
Why stop with Lenovo?
They should also demand compilable source code for the OS and all applications, so they can make sure there's no trojan horses there (much easier, really, than a hardware hack), and recompile them with the compiler of their choice to avoid a Thompson Trojan...
And... you know... that's probably not a bad idea.
If you're worried about Chinese-manufactured PCs being slipped into US defense networks, you better ban 'em all. What manufacturer is it that has no Chinese manufacturing plants?
Senior management at both Apple and Creative will now be involved with this, occasionally heavily, until it is resolved. This will take time and energy away from other activities, like production and producing new products.... so the people who actually develop and produce products might manage to slip a few decent ones out the door while the "vision thing" guys are distracted... like a two button mouse that works, or a Creative MP3 player that's not klunky?
If *bsd were not there they would be forced to spend money licensing/developing it themselves (ok, not if Apple had the licenses lying around anyway, but more generally) if they didn't want to opensource.
If they didn't want to opensource they wouldn't have been opensourcing all the stuff they didn't have to opensource that they did opensource anyway. They spent money opensourcing it that they didn't have to. So I don't think that saving money was the real reason.
The real reason is that open source works. Opening the source is valuable in and of itself, whether you have to or not. If it didn't work, then there wouldn't be all this open source software around to pick up... because the things that make open source work for people don't magically stop working just because you're a computer company.
BSD is for people who believe that open source is valuable, in and of itself, and that companies that release code will benefit in the long run just as individuals do.
And the success of the open source movement, whether GPL or BSD or MagicFairylicence bears that out.
Then why is glibc lgpl?
Glibc implements a lot more than just the open UNIX APIs.
If there were a BSD licensed optimising C compiler, they would have gone with that and we would not have got a free objective C compiler as quickly as we did.
There were multiple open source optimising C compilers by the end of the '90s, including a BSD one and a british effort that used a Java/.NET/mono-like intermediate code. They lost out to GCC not because GCC was the only free one, but because GCC was the one that had the most back-ends and the best optimisers. The tricks the FSF pulled to make that happen rather annoy me, because I'm a big fan of competition and I hate a monoculture even if it's one I happen to benefit from, but I shan't go into them here.
Similarly, the FreeBSD code base was better than the one they'd built NeXTstep on. They didn't have to use it, they chose it because they could. If it didn't exist or it was licensed on terms they couldn't work with, to get back to my original point, they wouldn't have gone with Linux instead... they would have used something else that would have been LESS open and MORE proprietary.
It's rather that it's simply chance Apple is making a desktop rather than a server OS
OK, you're using "chance" in a way that I don't quite understand, so I'll let this pass.
The internal architecture is that the UNIX interface is on the same level as the win32 one.
Er, no, Win32 is more like Cocoa and Carbon. The UNIX interface is more like the NT kernel interface.
Wasn't vms considered open once it had a posix layer
No.
True enough, but the flipside of that is there isn't that much to it, which leads to a lot of system-dependent stuff, so having an implementation of the unix API doesn't make program portability a done deal.
Indeed, there's a lot of UNIX code that uses non-UNIX APIs on every platform, including Linux. But on the other hand it's not that hard to write portable code. last year I came across a cute termcap-based screen hack I'd written on the PDP-11 in 1981. I compiled it on Tru64 and Mac OS X and after fixing one bug (a line that had in fact been wrong originally, it just hadn't been caught by the compiler) it ran perfectly.
On the other hand porting elm to Xenix 286 was a nightmare, mostly because the author wasn't aware that there were machines in which sizeof(char *) > sizeof(int)... and porting from Win32 to Win64 would probably be as hard.
The UNIX API is really brilliantly designed, and you can do an enormous amount of stuff without ever writing any code that has to know anything about the system configuration, and MOST system-dependant sections I find in UNIX ports are completely unnecessary. It's a pity that things like "configure" have lead people to think otherwise.
Apples and oranges - comparing what MS shipped with what's available from the darwin community.
No, just look at what APPLE shipped and what MICROSOFT shipped. Forget the rest of opendarwin.org and interop systems and the rest.
[Wine is] at the point where I would expect a typical windows program to work on it
And it's taken 10 years to get to the point where Linux was at back in the slackware days, or FreeBSD was at when it was still 386BSD patchkit 23.
I seem to have a similar chance of getting a windows program to run on wine as getting an unported program from one unix to run on another
Which is about the same chance as you had of getting an unported program to run on Slackware or FreeBSD 0.0. Or Digital UNIX, in the early days. It doesn't take 10 years of work to get to that point... for command line apps it really is close to a semester's undergraduate course.
We were early adopters of Digital UNIX. Brand new UNIX, brand new hardware, the first ever fully 64-bit UNIX, we had ALL the arrows in our back. And when I sat down on our first box, back when there was NO open source repository for the Alpha and EVERY program was a port... there wasn't even a stable gcc that I could find... 90% of the programs we used were built with no more than a couple of makefile tewaks to get the library names right. Most of the ones that didn't port easily were using configure.
And that's on a system that was supposedly incompatible at a pretty deep level with everything out there, for the sake of having a pure ILP64 memory model. That wasn't on a system that had had 10 years of tweaking to make it a perfect clone of Solaris. With an open system that just happens. You don't have to keep chasing the proprietary system you're cloning, you just implement the system and it works.
True, but it's only by Apple's goodwill that that code is available.
It's only because of Apple's goodwill that code even exists. Apple could just as easily have kept using their AT&T-licensed code and not released any of it, or they could have gone with BeOS, or the NT kernel (which wasn't out of the question at all in the late '90s before it got forcibly stuffed with Win32 crap). There's this undercurrent of "if it wasn't BSD Apple would have had to use Linux and the kernel would still be open" that I'm perceiving... and that's not true.
If Apple changed their mind, too, all that code would still be available.
But the license allows them to take any and all that they want.
And I'm certain the FreeBSD core team and developers to a man would rather they take more than they are. Apple doesn't get more because they choose not to, and because they choose not to they're keeping OS X from being a good server OS as well as a good desktop OS.
The GPL requires that anything that uses a GPL library be GPLed.
The GPL requires that anything that is a derived work of a GPLed library be GPLed.
The FSF defines "a derived work" to mean "anything that uses an API that requires they use a GPLed library". Not "anything that's linked with a GPLed library". If they didn't, you couldn't use gcc to compile proprietary software, you couldn't ship proprietary software on Linux.
The obvious example is readline
Which supports what I just wrote. That's why I said "open systems with GPL implementations", not "proprietary GPLed APIs". An open system is one that is defined in terms of public interfaces and protocols, that isn't defined by an implementation. UNIX was from teh start defined by the UNIX Programmer's Manual... not the code base. Up until System V UNIX releases were defined by the edition of the manual, and the manual was specifically defined by Bell Labs as being an open document. So far as I know only Whitesmiths has attempted to implement a UNIX workalike without following that manual.
Any GPLed library where that library defines the API is no more an "open system" than Win32. And any library that implements an open API is an open systems library regardless of whether that library is GPL, BSDL, APSL, or a proprietary implementation.
The impression I got was that unix was chosen because the components could be replaced one piece at a time while still having a working OS.
That's actually one of the advantages of a genuinely open system. Because it's defined in terms of interfaces and protocols, the implementation of those interfaces is much less critical.
There's no way MS could get away with changing the win32 API these days.
You say that, and yet there really are people coding for.NET.
Yes. But if the commercial unicies were open enough, what's the point of freebsd?
Oh, certainly "more open" is better than "less open", but price is a HUGE factor here as well. I dare say that if you could have bought a copy of (say) AIX for Intel for $19.95 in any computer store in 1990 it's unlikely there would have been the kind of groundswell of demand for either FreeBSD or Linux that there has been.
If freebsd is better on the server for now it's by fortune more than anything else.
Um, no. Apple has the code, and it's even employing members of the FreeBSD core team. If Apple wanted that kind of solid server operating system they'd have one. That's not their core market... the desktop is... and OS X's features are targeted to the desktop rather than the server.
I guess you could say it's simply chance that a group of people with a strong server background designed and implemented a strong server OS, but I really think that's pushing the term a bit far.
You have the posix APIs in windows as well
You have a complete hosted UNIX for Windows, and it's going to be in there as a standard part of Vista. But there's a huge difference between "X contains an implementation of an open system" and "X is an implementation of an open system".
The core native system calls, interfaces, and protocols in Mac OS X are UNIX ones. Even many of the Mac OS 9 compatibility components in Carbon, like aliases, are accessed through UNIX APIs.
Cocoa and Carbon are running on top of Darwin, they use the UNIX APIs to do their job, and Apple has moved a long way away from the Carbon/Classic model to a much more UNIX-based one in Cocoa.
OS/2 is dead, and Wine illustrates the difference between an open API and a closed one. The UNIX API is stable enough and small enough that implementing enough of UNIX to run command line tools is a decent one-quarter college course. I created a subset of the UNIX API in *Fortran* after reading "Software Tools" and working through the examples, and it was good enough to make porting '80s era apps to Ratfor from C by semi-automatic code practical.
Meanwhile it's taken Wine a decade to get to the point where it runs real apps and it's still playing catch-up... a decade after Linus started developing Linux you had people porting Linux APIs back to traditional UNIX systems!
Yeh, GNUstep is forever going to be playing catch-up to Cocoa, like Wine and Win32... but Darwin is still tracking its open source components as much as the other way around.
I don't really see this difference.
Microsoft's support for Open Source in Interix is limited to precisely what the GPL requires:
C:\temp\SFU\sources\Interix>dir gnu
Volume in drive C has no label.
Volume Serial Number is 6401-814C
The NT kernel actually has a bunch of interesting stuff in it, and back in the late '90s before they shoved huge chunks of Win32 up its fundamental orifice to improve the performance of the tightly-coupled Win32 subsystem this might actually have been a viable course.
Funny, I use the BSD license and I get a lot of code fixes back. I also contribute code fixes to other projects. Well, mostly, there's a few projects I don't bother helping... but that's got little to do with their license and more to do with the developer coming back with "I'm not going to use your fix because nobody should be able to do what your fix allows you to do".
Yes, really, not "I don't like your code" (I can deal with that... John Ousterhout rewrote every line of code I sent him and that's cool because he's a way better coder than I am), but "you shouldn't have this option/setting/command line flag/preference at all".
And not "leet hack code", but things like "change the default directory to save files in" or "run a helper application in the same directory as the file" or "hide or disable invalid menu items".
And, you now, GPL and BSD and MagicFairyLicense code can all be saddled with developers like that. And it has a MUCH bigger effect than the license.
BSD-guy: Hey, why did everyone switch from my code to theirs? o_O
Err, the BSD guys are going "Hey, cool, they're still using my code" and the GPL guys are going "they should be using our code instead!"
The difference here is that they are helping their direct competitors, and quite possibly people they have an idealogical opposition to.
Apple's paying Jordan Hubbard's salary, so I don't think that's an issue.:)
The Apple team gets all the work of the FreeBSD team, which gets none of theirs, so even if FreeBSD has many more programmers, Apple can still get ahead.
Apple doesn't get all the work of the FreeBSD programmers, because they aren't using all of FreeBSD.
And FreeBSD gets the work of the Apple programmers, there's ongoing projects to incorporate code that Apple wrote and included in Darwin... such as launchd... into FreeBSD.
The number of basic libraries that are pure GPL would mean it would require a lot of reimplementation effort from Apple if they wanted to keep things closed.
Erm, there's GPL code in Darwin too. The GPL doesn't require that applications running on open systems with GPL implementations be GPLed.
I honestly feel the FreeBSD team are making propriety systems more entrenched, and making the world worse for those who want to run free software.
They let me run more free software on my Mac than I ever could on Windows.
Because the XNU kernel for the x86 (a tiny part of Darwin) may be a proprietary UNIX kernel at this point, but it's a UNIX kernel, and that means it's still an open system.
Have the OSX developers removed these features? If so, what were they smoking?
Darwin is not "FreeBSD plus enhancements by Apple". It's "NeXT's OS minus the AT&T-licensed code plus enhancements from FreeBSD".
So you've replaced one propriety system with a better propriety system which will be harder to switch people away from.
Um, the "open system" versus "proprietary system" distinction arose long before there were open-source UNIXes available, long before there was a GNU manifesto. The FSF chose to implement a UNIX clone in HURD not because UNIX was the best OS design they knew (a lot of the FSF were agressively dismissive of UNIX) but because it was an open system that wasn't subject to the whims of a single company... by the mid '80s not even AT&T could have made a major change to the UNIX API and gotten away with it... as proven by the failure of the System V TLI API to supplant Berkeley sockets.
Whether the source to XNU is open or closed, the vast majority of interfaces to XNU are open standards, so even Darwin x86 is just as much an open system as any commercial UNIX has ever been. Meanwhile, FreeBSD remains a superior server operating system, and UNIX software runs efficiently and natively on both.
Windows is closed in the "open source" sense, and the "open systems" sense, and Microsoft has much more control over it than AT&T ever had over commercial UNIX or Apple has over the UNIX and BSD APIs that OS X is built on. The difference in "openness" between Windows and OS X is immense, real, and meaningful.
I just find it incredibly unlikely that Apple's additions have made it a worse OS.
Darwin is not "FreeBSD with additions". It's "NeXTstep/Rhapsody with AT&T code removed and replaced by code imported from FreeBSD". And even if it was FreeBSD with additions, it'd be FreeBSD as it was in the late '90s, without the enormous amount of work done on FreeBSD since Apple changed the direction of Rhapsody and started turning it into Darwin.
As a server it's definitely missing a lot of features from FreeBSD that are pretty important. It's also got a lot higher OS overhead because Mach is such a pig. The stuff on top of Darwin is great, but Mac OS X would be much better if they just used FreeBSD instead of Darwin underneath.
According to nVidia, the driver only references the functions in the Linux kernel and builds a layer so that the platform-independent driver will work.
And is the driver that does this released under the GPL?
It looks like OS X is taking a few tips from the 80s.
What, unbundling the documentation tools and the compilers and even the man pages, and selling them back to you for outrageous prices?
No?
Most Unix developers are accustomed to having access to the source code for the system;
Even when I was at Berkeley working on 4BSD that wasn't true. Only the CSRG guys had access to that source, everyone else was stuck with (if they were lucky) photocopies of the Lyons book.
Having access to the source code of the kernel is useful for understanding how the system works,
Yep, and you still have that. You don't have the x86-specific stuff, but you have everything else. And there just isn't that huge a difference between systems... hell, I was debugging Digital UNIX kernel problems by referring to the FreeBSD sources in the '90s, and the differences between XNU PPC and XNU x86 are trivial by comparison.
As a FreeBSD user, closed-source Unix just doesn't make sense to me
Then stick with FreeBSD.
As a former FreeBSD committer and 386BSD patchkit maintainer, I'll continue to use the best tools I have available: Mac OS X on the desktop and FreeBSD in the server room.
BDS, Brown Dragon Software, was a single-man shop that went out of business long before the GPL was released. His C compiler was great, but I don't believe his UNIX clone ever shipped.
Slashdot Mirror
Were there some people out there who thought that it was safe to open a word doc before today?
Ha ha hahahaha! Hee hee! What a joke... are there people who trust Word documents? Hell yes!
Wordpad is a decent program of its kind. I'm not a big fan of GUI text editors, but given that I have to say Wordpad is one of my favorites.
Another option (if you can find a copy) is the old Word Viewer.
Granted, it is their software, however, it could be (and occasionally is) software created by other companies.
...) or embedded objects (ActiveX, COM objects, ...) to execute outside a sandbox at all.
Very few companies, and almost none since the '80s, provide a mechanism for scripts or other embedded code in an untrusted document to run with local user privileges. It's not even that they do a better job of restricting active content to trusted documents... rather, they simply don't provide a mechanism for macros (Javascript, VBscript, Word macros,
Microsoft's spent an enormous amount of effort on schemes to try and make it safe to install and run, or run directly, unrestricted applets and scripts embedded in web pages, word documents, and so on. And has utterly failed in coming up with a safe way to do this inherently unsafe thing.
I don't know anyone else who's done anything even close to this in the past decade, let alone kept it in place and intact against an agreement they made with the US Department of Justice. Microsoft's arrogant naivete really is unique in the IT world.
Because most users have the ability to log in as root/admin due to management oversight/ignorance.
This is a secondary problem. Keeping users from having Administrator rights would be a good thing, but the local desktop security on Windows isn't really that great, and even if it was solid there's just so many ways a worm can propogate among a pool of computers without ever saving itself to persistent storage, let alone hiding in a system rather than user executable, that the problems caused by Microsoft's "Security Zones" model makes this one pale into insignificance.
Concentrate on reducing the surface area for attacks, it's a much bigger win than improving local security or antivirus software or whatever...
Is Microsoft this fragile?
... Realplayer is one I'm leary of), or support Microsoft's scripting tools.
Yes.
Basically, Microsoft's desktop has been unbelievably open to content-based attacks like this. Originally it was just Word macros having too many rights (which may be what's going on here, as well). When Active Desktop was introduced and the Microsoft HTML control was put in the position of being a "gatekeeper" for internet security things got MUCH worse VERY quickly.
So, well, avoiding content-based attacks on Windows requires (ironically) avoiding as many Microsoft applications as possible, or any applications that use the HTML control (Microsoft or not
Word is just the tip of the iceberg. It used to be the poster boy for this problem, but it's been a long time since it's been in the limelight. Internet Explorer and Outlook are the usual victims these days.
Should every Lenovo laptop be inspected before use in government offices, just in case some enterprising intelligence officer in the PLA is really that stupid?
Why stop with Lenovo?
They should also demand compilable source code for the OS and all applications, so they can make sure there's no trojan horses there (much easier, really, than a hardware hack), and recompile them with the compiler of their choice to avoid a Thompson Trojan...
And... you know... that's probably not a bad idea.
If you're worried about Chinese-manufactured PCs being slipped into US defense networks, you better ban 'em all. What manufacturer is it that has no Chinese manufacturing plants?
Senior management at both Apple and Creative will now be involved with this, occasionally heavily, until it is resolved. This will take time and energy away from other activities, like production and producing new products. ... so the people who actually develop and produce products might manage to slip a few decent ones out the door while the "vision thing" guys are distracted... like a two button mouse that works, or a Creative MP3 player that's not klunky?
Care to elaborate on what this idea was?
I don't see why it has to be. Well written code will port easily across architectures, badly written code won't.
I think that was the point I was making.
If *bsd were not there they would be forced to spend money licensing/developing it themselves (ok, not if Apple had the licenses lying around anyway, but more generally) if they didn't want to opensource.
If they didn't want to opensource they wouldn't have been opensourcing all the stuff they didn't have to opensource that they did opensource anyway. They spent money opensourcing it that they didn't have to. So I don't think that saving money was the real reason.
The real reason is that open source works. Opening the source is valuable in and of itself, whether you have to or not. If it didn't work, then there wouldn't be all this open source software around to pick up... because the things that make open source work for people don't magically stop working just because you're a computer company.
BSD is for people who believe that open source is valuable, in and of itself, and that companies that release code will benefit in the long run just as individuals do.
And the success of the open source movement, whether GPL or BSD or MagicFairylicence bears that out.
Then why is glibc lgpl?
Glibc implements a lot more than just the open UNIX APIs.
If there were a BSD licensed optimising C compiler, they would have gone with that and we would not have got a free objective C compiler as quickly as we did.
There were multiple open source optimising C compilers by the end of the '90s, including a BSD one and a british effort that used a Java/.NET/mono-like intermediate code. They lost out to GCC not because GCC was the only free one, but because GCC was the one that had the most back-ends and the best optimisers. The tricks the FSF pulled to make that happen rather annoy me, because I'm a big fan of competition and I hate a monoculture even if it's one I happen to benefit from, but I shan't go into them here.
Similarly, the FreeBSD code base was better than the one they'd built NeXTstep on. They didn't have to use it, they chose it because they could. If it didn't exist or it was licensed on terms they couldn't work with, to get back to my original point, they wouldn't have gone with Linux instead... they would have used something else that would have been LESS open and MORE proprietary.
It's rather that it's simply chance Apple is making a desktop rather than a server OS
OK, you're using "chance" in a way that I don't quite understand, so I'll let this pass.
The internal architecture is that the UNIX interface is on the same level as the win32 one.
Er, no, Win32 is more like Cocoa and Carbon. The UNIX interface is more like the NT kernel interface.
Wasn't vms considered open once it had a posix layer
No.
True enough, but the flipside of that is there isn't that much to it, which leads to a lot of system-dependent stuff, so having an implementation of the unix API doesn't make program portability a done deal.
Indeed, there's a lot of UNIX code that uses non-UNIX APIs on every platform, including Linux. But on the other hand it's not that hard to write portable code. last year I came across a cute termcap-based screen hack I'd written on the PDP-11 in 1981. I compiled it on Tru64 and Mac OS X and after fixing one bug (a line that had in fact been wrong originally, it just hadn't been caught by the compiler) it ran perfectly.
V7 UNIX -> 4BSD.
16-bit little-endian -> 32-bit big-endian and 64-bit little-endian.
sgtty -> termios.
On the other hand porting elm to Xenix 286 was a nightmare, mostly because the author wasn't aware that there were machines in which sizeof(char *) > sizeof(int)... and porting from Win32 to Win64 would probably be as hard.
The UNIX API is really brilliantly designed, and you can do an enormous amount of stuff without ever writing any code that has to know anything about the system configuration, and MOST system-dependant sections I find in UNIX ports are completely unnecessary. It's a pity that things like "configure" have lead people to think otherwise.
Apples and oranges - comparing what MS shipped with what's available from the darwin community.
No, just look at what APPLE shipped and what MICROSOFT shipped. Forget the rest of opendarwin.org and interop systems and the rest.
[Wine is] at the point where I would expect a typical windows program to work on it
And it's taken 10 years to get to the point where Linux was at back in the slackware days, or FreeBSD was at when it was still 386BSD patchkit 23.
I seem to have a similar chance of getting a windows program to run on wine as getting an unported program from one unix to run on another
Which is about the same chance as you had of getting an unported program to run on Slackware or FreeBSD 0.0. Or Digital UNIX, in the early days. It doesn't take 10 years of work to get to that point... for command line apps it really is close to a semester's undergraduate course.
We were early adopters of Digital UNIX. Brand new UNIX, brand new hardware, the first ever fully 64-bit UNIX, we had ALL the arrows in our back. And when I sat down on our first box, back when there was NO open source repository for the Alpha and EVERY program was a port... there wasn't even a stable gcc that I could find... 90% of the programs we used were built with no more than a couple of makefile tewaks to get the library names right. Most of the ones that didn't port easily were using configure.
And that's on a system that was supposedly incompatible at a pretty deep level with everything out there, for the sake of having a pure ILP64 memory model. That wasn't on a system that had had 10 years of tweaking to make it a perfect clone of Solaris. With an open system that just happens. You don't have to keep chasing the proprietary system you're cloning, you just implement the system and it works.
True, but it's only by Apple's goodwill that that code is available.
It's only because of Apple's goodwill that code even exists. Apple could just as easily have kept using their AT&T-licensed code and not released any of it, or they could have gone with BeOS, or the NT kernel (which wasn't out of the question at all in the late '90s before it got forcibly stuffed with Win32 crap). There's this undercurrent of "if it wasn't BSD Apple would have had to use Linux and the kernel would still be open" that I'm perceiving... and that's not true.
If Apple changed their mind, too, all that code would still be available.
But the license allows them to take any and all that they want.
And I'm certain the FreeBSD core team and developers to a man would rather they take more than they are. Apple doesn't get more because they choose not to, and because they choose not to they're keeping OS X from being a good server OS as well as a good desktop OS.
The GPL requires that anything that uses a GPL library be GPLed.
The GPL requires that anything that is a derived work of a GPLed library be GPLed.
The FSF defines "a derived work" to mean "anything that uses an API that requires they use a GPLed library". Not "anything that's linked with a GPLed library". If they didn't, you couldn't use gcc to compile proprietary software, you couldn't ship proprietary software on Linux.
The obvious example is readline
Which supports what I just wrote. That's why I said "open systems with GPL implementations", not "proprietary GPLed APIs". An open system is one that is defined in terms of public interfaces and protocols, that isn't defined by an implementation. UNIX was from teh start defined by the UNIX Programmer's Manual... not the code base. Up until System V UNIX releases were defined by the edition of the manual, and the manual was specifically defined by Bell Labs as being an open document. So far as I know only Whitesmiths has attempted to implement a UNIX workalike without following that manual.
Any GPLed library where that library defines the API is no more an "open system" than Win32. And any library that implements an open API is an open systems library regardless of whether that library is GPL, BSDL, APSL, or a proprietary implementation.
That's actually one of the advantages of a genuinely open system. Because it's defined in terms of interfaces and protocols, the implementation of those interfaces is much less critical.
There's no way MS could get away with changing the win32 API these days.
You say that, and yet there really are people coding for
Yes. But if the commercial unicies were open enough, what's the point of freebsd?
Oh, certainly "more open" is better than "less open", but price is a HUGE factor here as well. I dare say that if you could have bought a copy of (say) AIX for Intel for $19.95 in any computer store in 1990 it's unlikely there would have been the kind of groundswell of demand for either FreeBSD or Linux that there has been.
If freebsd is better on the server for now it's by fortune more than anything else.
Um, no. Apple has the code, and it's even employing members of the FreeBSD core team. If Apple wanted that kind of solid server operating system they'd have one. That's not their core market... the desktop is... and OS X's features are targeted to the desktop rather than the server.
I guess you could say it's simply chance that a group of people with a strong server background designed and implemented a strong server OS, but I really think that's pushing the term a bit far.
You have the posix APIs in windows as well
You have a complete hosted UNIX for Windows, and it's going to be in there as a standard part of Vista. But there's a huge difference between "X contains an implementation of an open system" and "X is an implementation of an open system".
The core native system calls, interfaces, and protocols in Mac OS X are UNIX ones. Even many of the Mac OS 9 compatibility components in Carbon, like aliases, are accessed through UNIX APIs.
Cocoa and Carbon are running on top of Darwin, they use the UNIX APIs to do their job, and Apple has moved a long way away from the Carbon/Classic model to a much more UNIX-based one in Cocoa.
OS/2 is dead, and Wine illustrates the difference between an open API and a closed one. The UNIX API is stable enough and small enough that implementing enough of UNIX to run command line tools is a decent one-quarter college course. I created a subset of the UNIX API in *Fortran* after reading "Software Tools" and working through the examples, and it was good enough to make porting '80s era apps to Ratfor from C by semi-automatic code practical.
Meanwhile it's taken Wine a decade to get to the point where it runs real apps and it's still playing catch-up... a decade after Linus started developing Linux you had people porting Linux APIs back to traditional UNIX systems!
Yeh, GNUstep is forever going to be playing catch-up to Cocoa, like Wine and Win32... but Darwin is still tracking its open source components as much as the other way around.
I don't really see this difference.
Microsoft's support for Open Source in Interix is limited to precisely what the GPL requires:Compare to the source trees on opendarwin.org... even without the XNU-x86 code.
That reminds me, I need to build Apple's latest update to rsync on FreeBSD.
The NT kernel actually has a bunch of interesting stuff in it, and back in the late '90s before they shoved huge chunks of Win32 up its fundamental orifice to improve the performance of the tightly-coupled Win32 subsystem this might actually have been a viable course.
GPL-guy: They fixed my code, w00t! \m/
Funny, I use the BSD license and I get a lot of code fixes back. I also contribute code fixes to other projects. Well, mostly, there's a few projects I don't bother helping... but that's got little to do with their license and more to do with the developer coming back with "I'm not going to use your fix because nobody should be able to do what your fix allows you to do".
Yes, really, not "I don't like your code" (I can deal with that... John Ousterhout rewrote every line of code I sent him and that's cool because he's a way better coder than I am), but "you shouldn't have this option/setting/command line flag/preference at all".
And not "leet hack code", but things like "change the default directory to save files in" or "run a helper application in the same directory as the file" or "hide or disable invalid menu items".
And, you now, GPL and BSD and MagicFairyLicense code can all be saddled with developers like that. And it has a MUCH bigger effect than the license.
BSD-guy: Hey, why did everyone switch from my code to theirs? o_O
Err, the BSD guys are going "Hey, cool, they're still using my code" and the GPL guys are going "they should be using our code instead!"
Funny how Microsoft's shipping open source code themselves, isn't it?
The difference here is that they are helping their direct competitors, and quite possibly people they have an idealogical opposition to.
:)
Apple's paying Jordan Hubbard's salary, so I don't think that's an issue.
The Apple team gets all the work of the FreeBSD team, which gets none of theirs, so even if FreeBSD has many more programmers, Apple can still get ahead.
Apple doesn't get all the work of the FreeBSD programmers, because they aren't using all of FreeBSD.
And FreeBSD gets the work of the Apple programmers, there's ongoing projects to incorporate code that Apple wrote and included in Darwin... such as launchd... into FreeBSD.
The number of basic libraries that are pure GPL would mean it would require a lot of reimplementation effort from Apple if they wanted to keep things closed.
Erm, there's GPL code in Darwin too. The GPL doesn't require that applications running on open systems with GPL implementations be GPLed.
I honestly feel the FreeBSD team are making propriety systems more entrenched, and making the world worse for those who want to run free software.
They let me run more free software on my Mac than I ever could on Windows.
Because the XNU kernel for the x86 (a tiny part of Darwin) may be a proprietary UNIX kernel at this point, but it's a UNIX kernel, and that means it's still an open system.
Have the OSX developers removed these features? If so, what were they smoking?
Darwin is not "FreeBSD plus enhancements by Apple". It's "NeXT's OS minus the AT&T-licensed code plus enhancements from FreeBSD".
So you've replaced one propriety system with a better propriety system which will be harder to switch people away from.
Um, the "open system" versus "proprietary system" distinction arose long before there were open-source UNIXes available, long before there was a GNU manifesto. The FSF chose to implement a UNIX clone in HURD not because UNIX was the best OS design they knew (a lot of the FSF were agressively dismissive of UNIX) but because it was an open system that wasn't subject to the whims of a single company... by the mid '80s not even AT&T could have made a major change to the UNIX API and gotten away with it... as proven by the failure of the System V TLI API to supplant Berkeley sockets.
Whether the source to XNU is open or closed, the vast majority of interfaces to XNU are open standards, so even Darwin x86 is just as much an open system as any commercial UNIX has ever been. Meanwhile, FreeBSD remains a superior server operating system, and UNIX software runs efficiently and natively on both.
Windows is closed in the "open source" sense, and the "open systems" sense, and Microsoft has much more control over it than AT&T ever had over commercial UNIX or Apple has over the UNIX and BSD APIs that OS X is built on. The difference in "openness" between Windows and OS X is immense, real, and meaningful.
I just find it incredibly unlikely that Apple's additions have made it a worse OS.
Darwin is not "FreeBSD with additions". It's "NeXTstep/Rhapsody with AT&T code removed and replaced by code imported from FreeBSD". And even if it was FreeBSD with additions, it'd be FreeBSD as it was in the late '90s, without the enormous amount of work done on FreeBSD since Apple changed the direction of Rhapsody and started turning it into Darwin.
As a server it's definitely missing a lot of features from FreeBSD that are pretty important. It's also got a lot higher OS overhead because Mach is such a pig. The stuff on top of Darwin is great, but Mac OS X would be much better if they just used FreeBSD instead of Darwin underneath.
According to nVidia, the driver only references the functions in the Linux kernel and builds a layer so that the platform-independent driver will work.
And is the driver that does this released under the GPL?
It looks like OS X is taking a few tips from the 80s.
What, unbundling the documentation tools and the compilers and even the man pages, and selling them back to you for outrageous prices?
No?
Most Unix developers are accustomed to having access to the source code for the system;
Even when I was at Berkeley working on 4BSD that wasn't true. Only the CSRG guys had access to that source, everyone else was stuck with (if they were lucky) photocopies of the Lyons book.
Having access to the source code of the kernel is useful for understanding how the system works,
Yep, and you still have that. You don't have the x86-specific stuff, but you have everything else. And there just isn't that huge a difference between systems... hell, I was debugging Digital UNIX kernel problems by referring to the FreeBSD sources in the '90s, and the differences between XNU PPC and XNU x86 are trivial by comparison.
As a FreeBSD user, closed-source Unix just doesn't make sense to me
Then stick with FreeBSD.
As a former FreeBSD committer and 386BSD patchkit maintainer, I'll continue to use the best tools I have available: Mac OS X on the desktop and FreeBSD in the server room.
Too bad the Open Source crowd is moving away from GNUstep based programs like Windowmaker to the Windows-clone Gnome and KDE desktops. :(
GPL vs BDS
BDS, Brown Dragon Software, was a single-man shop that went out of business long before the GPL was released. His C compiler was great, but I don't believe his UNIX clone ever shipped.
No. Mach has never been relevant to the microkernel vs monolithic kernel debate. It's much too heavyweight to build a real microkernel OS on top of.