Yeah, right. You can't get people to do that for free software? One of the major problems with the free software out there is that it mainly uses a huge variety of these crap toolkits. Every time I download a piece of software it seems I have to install three new libraries... Qt... Gtk... Glib... Allegro... So many damned toolkits! You're telling me people won't upgrade/install for free software?
I'm telling you people won't necessarily buy CDE 2.1 for their pre-2.1 system in order to build a piece of free software.
It is safe to write software for 2.1.
Even if I want it to work on, say, Solaris 2.5.1, Solaris 2.6, and Solaris 7, none of which come bundled with CDE 2.1?
developers who do not wish to be coerced by the government to give away their work are "free" to twist in the wind.
Developers who do not wish to be coerced to give away their work are free to use code whose creators have not imposed, as a condition of use of that code, that source be made available to any changes that they make, and that the users of said code are not allowed to arrange that the government be able to coerce people not to freely redistribute their changed code.
Not all code on the planet is GPLed; there's plenty of non-GPLed code that said developers can use, and they can also write their own replacements - they have alternatives to "twisting in the wind".
This, in a nutshell, is a problem with the GPL. Its purpose is solely to hurt commercial programmers,
Its purpose, at least in part, is to arrange that code based on GPLed code be made available, in source form, to all who use that code, and that recipients of that code not be enjoined from further redistributing the code.
This may, as a side effect - perhaps intentional - hurt commercial programmers, by "forcing" them to use code other than GPLed code; however, not providing source to software packages could also hurt commercial programmers trying to build something atop that package, by preventing them from seeing how the code works and thus figuring out how to make it do what they want, and preventing them from fixing said code if bugs in it get in their way.
I could believe that Stallman also wants to eliminate commercial software as well; however, I have seen no evidence that the sole purpose of the GPL is to prevent programmers from making money for their software, period - for one thing, given that not all software is GPLed, it cannot completely prevent programmers from making money from their software.
If someone makes improvements, they belong to that person; he or she should have a choice of sharing them or not. To try to force him or her to give up that work with no compensation is confiscation, pure and simple. This is what the GPL tries to do: confiscate programmers' work using the government's guns and courts.
No, it doesn't. It tries to say "if you use this code, and if you make available binary code based on it, you must make available the source as well, and must not restrict anybody from giving away what source and binary code, based on that code, you've provided them."
If you don't want to have to give your code away, don't use GPLed code. "The government's guns and courts" are not being used to force people to use GPLed code; they could be used to force people who choose to use GPLed code to make available the source to their changes to that code, and to prevent the people who made those changes from "using the government's guns and courts" to prevent others provided with that changed code from giving it away.
They're not taking away your freedom to write non-free code. They're just taking away your freedom to use their code to write a non-free derivative of that code, and thus to take away the freedom of the recipients of code based on GPLed code to get the source and to give away that code and any additional changes.
Yes, the GPL restricts your freedom to use GPLed code to write non-free code - just as most traffic laws restrict your freedom to drive at 300 km/h on a public highway. If you want to drive that fast, find a private race track (or head over to Germany and drive on an Autobahn, although I suspect they might get peeved if they've imposed a speed limit due to, say, road conditions, and you ignore that restriction); if you want to write non-free software, write it entirely by yourself, or base it on code with a license that allows that.
If you don't like the restrictions imposed by the GPL, don't use GPLed code - write your own replacement code.
It is important to remember that CDE/Motif 2.1 is a large improvement over 1.2
E.g., it finally has widgets from which you can construct a tree view or a multi-column list (as one of the developers of Ethereal, my interest in toolkits that don't come with tree-view or multi-column list support is somewhat limited - yeah, there are probably alternative tree-view or multi-column list widgets out there, but having to supply it and have people have to compile it is a bit of a pain).
and that's why it was developed
Yeah, most new versions of products aren't specifically intended to be worse than their predecessors (although some products have been known to be improvements on their successors...)
--so if you're going to judge CDE/Motif, judge it by 2.1.
Except that if a lot of UNIX systems still ship with 1.2[.x], 2.1 isn't necessarily usable for many applications (unless you want to force people to upgrade in order to run your application, which you might be able to get away with for a commercial app, but I suspect you couldn't get people to do in order to run a free-software app).
By the way, do I risk an invasion from Hot Grits Man if I note that my copy of the OSF/Motif(TM) 2.0 Programmer's Guide has, right after the RESTRICTED RIGHTS NOTICE on the trademark and license page, a RESTRICTED TIGHTS[sic] LEGEND?
I want my X resources, my command line parsing, and a standard framework of gui mechanisms.
And I've managed to live without those being available in every application, so the failure to use Xt in no way makes a GUI unacceptable to me. Period.
(The bulk of the stuff in my.Xdefaults file is cruft to batter various applications into giving me the colors, key bindings, fonts, etc. that I want, rather than, say, the key bindings that the developers of Netscape Navigator wanted. The GTK+ and Qt-based applications I've used somehow seem, by and large, to give me what I want, without having to fill up a configuration file with stuff.)
Any GNOME super-hero can tell me how GNOME and HURD relate to each other?
I'm not a "GNOME super-hero", but the way GNOME and the Hurd relate to one another is that:
the Hurd contains the part of the implementation of a UNIX API that needs to run in some form of "privileged" mode (kernel mode, or privileged servers running in user mode);
GNU libc (and perhaps some other libraries) contain(s) the rest of the "core UNIX" API;
the X libraries run atop that "core API" just as they do on other OSes providing that API (Linux distributions, BSDs, Solaris, Irix, Digital UNIX, HP-UX, AIX, blah blah blah);
GTK+ and GLib run atop the X library and the "core API", just as on other OSes providing that API;
GNOME runs atop all that stuff, just as on other OSes providing that API.
I.e., GNOME relates to the Hurd the same way it relates to the kernel of other UNIX-flavored systems; with the possible exception of the small amount of stuff that needs to worry about which particular UNIX-flavored OS it's using, GNOME neither knows nor cares that the Hurd is running down at the bottom.
Basically, you load the Mach microkernel, then you load the OSF/1 unix server
If there's an "OSF/1 unix server" on Digital UNIX, it appears to be a chunk of kernel-mode code (and I'm not even certain that it does put that stuff into a separate server process), so DU/Tru64U doesn't appear to be all that microkernelish.
Under the terms of the license, you are free to modify, compile and use any changes you make. Although there is no limit to what you may change, there are limitations on what you may do with those changes.
You may not redistribute any portion of the Solaris 8 source code internally or externally, which means you may not make copies or pass your CDs on to someone else. Similarly, although you will retain any intellectual property and other rights provided to you by law, you do not have the right to redistribute any portion of the Solaris 8 source code that you received from Sun. If you want to make your source code modifications available to other Solaris source code licensees, you can do so by passing the changes back to Sun, and Sun will then post them to a secure website that you and other registered users may access.
Maybe they don't understand that free as in beer doesn't measure up to free as in speech...
{Free,Net,Open}BSD are free-as-in-speech, as well as free-as-in-beer; the BSD license just happens to allow one to make derivatives of that code that are not free-as-in-speech (or not free-as-in-beer).
Worth ignoring because Qt 2.x is, guess what - compatible with GTK+ and Motif.
And Motif? It does support the Xdnd protocol that GTK+ (and the toolkit/application framework that introduced Xdnd, JX) support, but I hadn't heard that it, like GTK+, also supported the Motif DnD protocol as well - are you certain that it does (e.g., because Troll Tech says so on their Web site)?
Given that X gives you a standard method of transmitting windows over a network to or from assorted other systems, that puts it well ahead of the other single user GUI's in my opinion.
NeWS, as per the second point made to the person to whom you responded, also supported displays over the network - you sent PostScript code to the display server, and it runs that code to draw stuff and send information back to the application for input events that the PostScript code didn't handle itself.
QT and GTK both lack good software for GUI building and prototyping. When you're trying out different looks for an application, it's REALLY annoying to have write code to have to specify the look'n'feel of an app when it makes much more sense to use your visual intuition to 'draw' the interface.
Qt and GTK+ may lack them, but the environments built atop them may have them; does Glade, for GNOME (and, it indicates, raw GTK+), or Kdevelop, for KDE, provide enough of that sort of functionality for you? (Kdevelop has a dialog editor, at least, and Glade also appears to have a way of visually constructing the GUI.)
I haven't figured out how to do similar dragging and dropping on the desktop or between applications with KDE or Gnome. I'm pretty sure it's there,
GTK+ 1.2[.x] (the toolkit for Gnome - as well as for many non-GNOME applications) has support for drag-and-drop, using both the Xdnd protocol and the Motif DnD protocol. Qt 2.0 (the toolkit for the under-development KDE 2.0) also supports drag-and-drop using Xdnd (but not, as far as I know, the Motif DnD protocol); I think Qt 1.x supported DnD on UNIX/X11, but not using Xdnd (unless one of the later 1.x's added support for it, which it might have).
I'm pretty sure it's there, but it doesn't seem as integrated as it did on Irix.
"Doesn't seem as integrated" in what sense? Presumably not in the API sense, as you haven't yet looked at the API; maybe fewer KDE and/or GNOME applications support DnD, but I'm not going to assume that's the case.
have no problem agreeing that the "default" GTK look is pretty klunky.
Note that the default GTK+ look is very much like that of, err, umm, Motif....
If Jamie hadn't used a GTK+ theme in Exhibit B, the "why is Motif ugly and GTK+ beautiful?" question would have been even more pointed.
Of course, what this points out is that GTK+, given that it's themable, cannot, in and of itself, be described as "ugly" or "beautiful", even by the criterion of one particular person's taste, unless you refer to its default appearance, as the way it looks depends on the theme being used.
or the fact that the roots of Windows come from Motif, not the Mac
Umm, are you certain of that? Motif and Windows 3.x have visual similarities, but I'm not certain that's because Windows was modeled after Motif - I have the impression it may have been the other way around.
The general idea of using an interchange format for final-form documents is in the public domain. Anyone is free to devise his or her own set of unique commands and data structures that define an interchange for final-form documents. Adobe owns the copyright in the data structures, operators, and the written specification for the particular interchange format called the Portable Document Format. These elements may not be copied without Adobe's permission.
Adobe will enforce its copyright. Adobe's intention is to maintain the integrity of the Portable Document Format as a standard. This enables the public to distinguish between the Portable Document Format and other interchange formats for final-form documents.
However, adobe desires to promote the use of the Portable Document Format for information interchange among diverse products and applications. Accordingly, Adobe gives copyright permission to anyone to:
Prepare files in which the file content conforms to the Portable Document Format.
Write drivers and applications that produce output represented in the Portable Document Format.
Write software that accepts input in the form of the Portable Document Format and displays the results, prints the results, or otherwise interprets a file represented in the Portable Document Format.
Copy Adobe's copyrighted list of operators and data structures, as well as the PDF sample code and PostScript language Function definitions in the written specification, to the extent necessary to use the Portable Document Format for the above purposes.
The only condition on such copyright permission is that anyone who uses the copyrighted list of operators and data structures in this way must include an appropriate copyright notice.
although it also says:
This limited right to use the copyrighted list of operators and data structures does not include the right to copy the
Portable Document Format Reference Manual [oh, well, I guess the Adobe police will be after me now for posting this...], other copyrighted material from Adobe, or the software in any of adobe's products which use the Portable Document Format, in whole or in part, nor does it include the right to use any Adobe patents.
I don't know whether any of those patents are used by xpdf, ps2pdf, Quartz, etc..
The article claims that keeping track of shapes as objects in the server is some breakthrough development. Well, maybe for Apple. The rest of us have had that kind of graphics canvases in our toolkits for years (with Tcl/Tk and GNOME being only fairly recent examples).
Yes, but not in the server (e.g., in the X server).
But, no, it's not a new idea. Amusingly enough, the implementations of that notion of which I've heard were both done atop UNIX-derived OSes - Sun's NeWS, and the NeXT machines' version of Display PostScript.
The dock takes advantage of Quartz's ability to apply vector transformations to
bitmapped images.
...
Aqua appears to use (via Quartz) a form of bicubic interpolation to scale the icons.
(emphasis mine) which seems to suggest that the icons are bitmaps, not "vector-based", and that the icons are scaled up by interpolating between the points.
I really like the idea of a vector based GUI. I think that looking at more "organic" shapes is easier on the eyes than looking at all those squares and blocks.
If by "'organic' shapes" you mean the jelly blobs of Aqua, I don't think they're intrinsically tied in any way to a "vector based GUI". In fact, the Ars Technica article says as much - it says of the gelatinous buttons, "On the other hand, nothing we've discussed so far can't be duplicated with a second generation display layer."
Why use a vector based windowing system on a monitor that can only display squares and blocks efficiently.
Well, I'm not sure what's "vector-based" about Display PDF; PDF is a PostScript-like language (not entirely surprising, considering who invented PDF...), so it might be "vector-based" in that a path might be made out of lines - but the PDF spec says that a "path object" is "an arbitrary shape made of straight lines, rectangles, and cubic curves", so it's more than just "vectors" (in the sense of "lines").
The moment a vector based windowing system becomes usefull even unavoidable is when we have "analog" monitors as in "monitors that can actually display vectors" as opposed to the current "monitors that diplay bitmaps"
To put it bluntly, I would not, if I were you, hold my breath waiting for that to happen. I suspect it may be easier to make raster CRTs (you just have to make the beam scan left to right, and then scan the next line below it, and..., rather than being able to steer it arbitrarily), and the display on my desk isn't even a CRT - LCD displays (which, as far as I'm concerned, rule) are intrinsically digital monitors that display bitmaps.
I have the impression that, these days, rasterizing vectors is pretty much a solved problem.
IMHO this vector based windowing system is just a marketing buzz-word induced waste of cpu-time.
The reason for a "vector-based" (or, as I might be inclined to say, "path-based") windowing system, at least as presented by Ars Technica's article, is that "vector" transformations (which, I suspect, are transformations on vectors representing points, i.e. the vector from the origin of the coordinate system to the point, not vectors representing lines from one arbitrary point to another) can be applied to the PDF description of something being drawn.
Much of the other advantages that article ascribes to a "vector-based" windowing system, such as the stuff Aqua does with transparency, have, I suspect, little if anything to do with PDF being "vector-based" (or "path-based").
Besides, I didn't see any mention of "vector-based graphics" on the Graphics page of Apple's stuff on MacOS X; "vector-based graphics" may have been Ars Technica's term - as suggested above, I'm not sure I'd use it, and that may be why Apple doesn't appear to be using it there, either.
FreeBSD will not run VMWare, because VMWare uses a kernel module under Linux. Last I checked, FreeBSD can't use Linux kernel modules. Until VMWare writes a native version for FreeBSD
This piece of software provides some basic support for running the VMware 1.1 for Linux on FreeBSD.
I'm using FreeBSD 4.0 -current system and don't know whether this software will work on the 3.X branch.
...
At this time I was able to successfully run the following operation systems under VMware on FreeBSD:
- FreeBSD 4.0 Current - Linux (Debian 2.1) - Windows NT - Windows 95 OSR2 (in safe mode:) - MS DOS 7.0 (Part of Win'95)
(The answer to the implied question about 3.x appears to be "you'd have to bludgeon the kernel changes into compiling under 3.x"; I didn't put a lot of effort into trying to do that, so I don't know if it's doable.)
but the philosophy behind 4.4BSD-Lite is a direct and blatant rewrite of the proprietary code that came before it. What the programmers did was to basically reconstruct the copy-protected code in a new, lawsuit-free form. It's not a direct clone, but it's close enough to look, feel, and behave the same way.
Umm, the fts routines weren't just a reconstruction of copyrighted AT&T code, they implemented a new API that came out of BSD (I remember when Keith was writing it). Yes, one thing done for 4.4-Lite was replacement of copyrighted AT&T code (note that the project to do so started before the lawsuit...), but that's not all there was to 4.4-Lite.
As for whether BSD "looks, feels, and behaves" more like "real UNIX" than does Linux, that may depend on your definition of "real UNIX" - init and the twisty little maze of rc files on most Linux distributions "looks, feels, and behaves" more like that of most commercial UNIXes (i.e., is more SV-like) than do init and its rc files on the BSDs, for example.
If you want that feature why not just go with FreeBSD?
Because he may have other reasons to want to run Linux, and those may be legitimate reasons; if some particular OS comes up with a useful feature, I have no particular problem with other OSes adopting that feature, or a variant thereof.
The whole suite has been extensively regression tested and package tested. It should be reliable and suitable for widespread use.
egcs won't release a stable compiler until gcc 3.0.
Sorry, putting a quote from the 2.95 announcement just before a quote from the person to whom I'm responding makes the above, from my response, a bit confusing; the first of those two statements came from the 2.95 announcement, but the second was a quote from the person to whom I responded - it is not a statement from the GCC 2.95 announcement.
Slashdot Mirror
I'm telling you people won't necessarily buy CDE 2.1 for their pre-2.1 system in order to build a piece of free software.
Even if I want it to work on, say, Solaris 2.5.1, Solaris 2.6, and Solaris 7, none of which come bundled with CDE 2.1?
Developers who do not wish to be coerced to give away their work are free to use code whose creators have not imposed, as a condition of use of that code, that source be made available to any changes that they make, and that the users of said code are not allowed to arrange that the government be able to coerce people not to freely redistribute their changed code.
Not all code on the planet is GPLed; there's plenty of non-GPLed code that said developers can use, and they can also write their own replacements - they have alternatives to "twisting in the wind".
Its purpose, at least in part, is to arrange that code based on GPLed code be made available, in source form, to all who use that code, and that recipients of that code not be enjoined from further redistributing the code.
This may, as a side effect - perhaps intentional - hurt commercial programmers, by "forcing" them to use code other than GPLed code; however, not providing source to software packages could also hurt commercial programmers trying to build something atop that package, by preventing them from seeing how the code works and thus figuring out how to make it do what they want, and preventing them from fixing said code if bugs in it get in their way.
I could believe that Stallman also wants to eliminate commercial software as well; however, I have seen no evidence that the sole purpose of the GPL is to prevent programmers from making money for their software, period - for one thing, given that not all software is GPLed, it cannot completely prevent programmers from making money from their software.
No, it doesn't. It tries to say "if you use this code, and if you make available binary code based on it, you must make available the source as well, and must not restrict anybody from giving away what source and binary code, based on that code, you've provided them."
If you don't want to have to give your code away, don't use GPLed code. "The government's guns and courts" are not being used to force people to use GPLed code; they could be used to force people who choose to use GPLed code to make available the source to their changes to that code, and to prevent the people who made those changes from "using the government's guns and courts" to prevent others provided with that changed code from giving it away.
They're not taking away your freedom to write non-free code. They're just taking away your freedom to use their code to write a non-free derivative of that code, and thus to take away the freedom of the recipients of code based on GPLed code to get the source and to give away that code and any additional changes.
Yes, the GPL restricts your freedom to use GPLed code to write non-free code - just as most traffic laws restrict your freedom to drive at 300 km/h on a public highway. If you want to drive that fast, find a private race track (or head over to Germany and drive on an Autobahn, although I suspect they might get peeved if they've imposed a speed limit due to, say, road conditions, and you ignore that restriction); if you want to write non-free software, write it entirely by yourself, or base it on code with a license that allows that.
If you don't like the restrictions imposed by the GPL, don't use GPLed code - write your own replacement code.
E.g., it finally has widgets from which you can construct a tree view or a multi-column list (as one of the developers of Ethereal, my interest in toolkits that don't come with tree-view or multi-column list support is somewhat limited - yeah, there are probably alternative tree-view or multi-column list widgets out there, but having to supply it and have people have to compile it is a bit of a pain).
Yeah, most new versions of products aren't specifically intended to be worse than their predecessors (although some products have been known to be improvements on their successors...)
Except that if a lot of UNIX systems still ship with 1.2[.x], 2.1 isn't necessarily usable for many applications (unless you want to force people to upgrade in order to run your application, which you might be able to get away with for a commercial app, but I suspect you couldn't get people to do in order to run a free-software app).
By the way, do I risk an invasion from Hot Grits Man if I note that my copy of the OSF/Motif(TM) 2.0 Programmer's Guide has, right after the RESTRICTED RIGHTS NOTICE on the trademark and license page, a RESTRICTED TIGHTS[sic] LEGEND?
To which newer versions are you referring? Later 1.2[.x] releases, or 2.x? If 2.x, which commercial UNIXes ship with 2.x?
And I've managed to live without those being available in every application, so the failure to use Xt in no way makes a GUI unacceptable to me. Period.
(The bulk of the stuff in my .Xdefaults file is cruft to batter various applications into giving me the colors, key bindings, fonts, etc. that I want, rather than, say, the key bindings that the developers of Netscape Navigator wanted. The GTK+ and Qt-based applications I've used somehow seem, by and large, to give me what I want, without having to fill up a configuration file with stuff.)
I'm not a "GNOME super-hero", but the way GNOME and the Hurd relate to one another is that:
I.e., GNOME relates to the Hurd the same way it relates to the kernel of other UNIX-flavored systems; with the possible exception of the small amount of stuff that needs to worry about which particular UNIX-flavored OS it's using, GNOME neither knows nor cares that the Hurd is running down at the bottom.
If there's an "OSF/1 unix server" on Digital UNIX, it appears to be a chunk of kernel-mode code (and I'm not even certain that it does put that stuff into a separate server process), so DU/Tru64U doesn't appear to be all that microkernelish.
Yes, if Solaris ever became "freely available and open source", that might be cool.
However, I've yet to see any signs of that happening; the term under which Sun have said they'll make source license available don't seem particularly like "open source" to me:
(emphasis mine).
{Free,Net,Open}BSD are free-as-in-speech, as well as free-as-in-beer; the BSD license just happens to allow one to make derivatives of that code that are not free-as-in-speech (or not free-as-in-beer).
And Motif? It does support the Xdnd protocol that GTK+ (and the toolkit/application framework that introduced Xdnd, JX) support, but I hadn't heard that it, like GTK+, also supported the Motif DnD protocol as well - are you certain that it does (e.g., because Troll Tech says so on their Web site)?
NeWS, as per the second point made to the person to whom you responded, also supported displays over the network - you sent PostScript code to the display server, and it runs that code to draw stuff and send information back to the application for input events that the PostScript code didn't handle itself.
For better or worse, NeWS didn't survive, though.
Qt and GTK+ may lack them, but the environments built atop them may have them; does Glade, for GNOME (and, it indicates, raw GTK+), or Kdevelop, for KDE, provide enough of that sort of functionality for you? (Kdevelop has a dialog editor, at least, and Glade also appears to have a way of visually constructing the GUI.)
GTK+ 1.2[.x] (the toolkit for Gnome - as well as for many non-GNOME applications) has support for drag-and-drop, using both the Xdnd protocol and the Motif DnD protocol. Qt 2.0 (the toolkit for the under-development KDE 2.0) also supports drag-and-drop using Xdnd (but not, as far as I know, the Motif DnD protocol); I think Qt 1.x supported DnD on UNIX/X11, but not using Xdnd (unless one of the later 1.x's added support for it, which it might have).
Here's Troll Tech's documentation on DnD with Qt (probably for 2.0). There may be additional KDE APIs atop that; try plowing through the KDE developer's site.
Here's the GTK+ reference documentation section on DnD APIs; again, there may be additional GNOME APIs atop it - if you plow through the GNOME developer's site, you may find something.
"Doesn't seem as integrated" in what sense? Presumably not in the API sense, as you haven't yet looked at the API; maybe fewer KDE and/or GNOME applications support DnD, but I'm not going to assume that's the case.
Note that the default GTK+ look is very much like that of, err, umm, Motif....
If Jamie hadn't used a GTK+ theme in Exhibit B, the "why is Motif ugly and GTK+ beautiful?" question would have been even more pointed.
Of course, what this points out is that GTK+, given that it's themable, cannot, in and of itself, be described as "ugly" or "beautiful", even by the criterion of one particular person's taste, unless you refer to its default appearance, as the way it looks depends on the theme being used.
Umm, are you certain of that? Motif and Windows 3.x have visual similarities, but I'm not certain that's because Windows was modeled after Motif - I have the impression it may have been the other way around.
And the PDF 1.3 spec says:
although it also says:
I don't know whether any of those patents are used by xpdf, ps2pdf, Quartz, etc..
Yes, but not in the server (e.g., in the X server).
But, no, it's not a new idea. Amusingly enough, the implementations of that notion of which I've heard were both done atop UNIX-derived OSes - Sun's NeWS, and the NeXT machines' version of Display PostScript.
The Ars Technica article says:
(emphasis mine) which seems to suggest that the icons are bitmaps, not "vector-based", and that the icons are scaled up by interpolating between the points.
If by "'organic' shapes" you mean the jelly blobs of Aqua, I don't think they're intrinsically tied in any way to a "vector based GUI". In fact, the Ars Technica article says as much - it says of the gelatinous buttons, "On the other hand, nothing we've discussed so far can't be duplicated with a second generation display layer."
Well, I'm not sure what's "vector-based" about Display PDF; PDF is a PostScript-like language (not entirely surprising, considering who invented PDF...), so it might be "vector-based" in that a path might be made out of lines - but the PDF spec says that a "path object" is "an arbitrary shape made of straight lines, rectangles, and cubic curves", so it's more than just "vectors" (in the sense of "lines").
To put it bluntly, I would not, if I were you, hold my breath waiting for that to happen. I suspect it may be easier to make raster CRTs (you just have to make the beam scan left to right, and then scan the next line below it, and..., rather than being able to steer it arbitrarily), and the display on my desk isn't even a CRT - LCD displays (which, as far as I'm concerned, rule) are intrinsically digital monitors that display bitmaps.
I have the impression that, these days, rasterizing vectors is pretty much a solved problem.
The reason for a "vector-based" (or, as I might be inclined to say, "path-based") windowing system, at least as presented by Ars Technica's article, is that "vector" transformations (which, I suspect, are transformations on vectors representing points, i.e. the vector from the origin of the coordinate system to the point, not vectors representing lines from one arbitrary point to another) can be applied to the PDF description of something being drawn.
Much of the other advantages that article ascribes to a "vector-based" windowing system, such as the stuff Aqua does with transparency, have, I suspect, little if anything to do with PDF being "vector-based" (or "path-based").
Besides, I didn't see any mention of "vector-based graphics" on the Graphics page of Apple's stuff on MacOS X; "vector-based graphics" may have been Ars Technica's term - as suggested above, I'm not sure I'd use it, and that may be why Apple doesn't appear to be using it there, either.
(The answer to the implied question about 3.x appears to be "you'd have to bludgeon the kernel changes into compiling under 3.x"; I didn't put a lot of effort into trying to do that, so I don't know if it's doable.)
Umm, the fts routines weren't just a reconstruction of copyrighted AT&T code, they implemented a new API that came out of BSD (I remember when Keith was writing it). Yes, one thing done for 4.4-Lite was replacement of copyrighted AT&T code (note that the project to do so started before the lawsuit...), but that's not all there was to 4.4-Lite.
As for whether BSD "looks, feels, and behaves" more like "real UNIX" than does Linux, that may depend on your definition of "real UNIX" - init and the twisty little maze of rc files on most Linux distributions "looks, feels, and behaves" more like that of most commercial UNIXes (i.e., is more SV-like) than do init and its rc files on the BSDs, for example.
In what fashion is the Win32 API "more integrated" than the APIs of various UNIX systems?
Because he may have other reasons to want to run Linux, and those may be legitimate reasons; if some particular OS comes up with a useful feature, I have no particular problem with other OSes adopting that feature, or a variant thereof.
Sorry, putting a quote from the 2.95 announcement just before a quote from the person to whom I'm responding makes the above, from my response, a bit confusing; the first of those two statements came from the 2.95 announcement, but the second was a quote from the person to whom I responded - it is not a statement from the GCC 2.95 announcement.