1) fonts include programs internally these days. 2) I believe this applies to the shape of the glyphs, not te bag of bits. So you can build fonts that look like some other fonts, but not just take the bits as is.
This is how you get Times New Roman that looks like Times Roman. Someone built a font from scratch that looks the same.
So copyright law does not protect the shapes of characters themselves against mimicry, as it does with, say, the design of Micky Mouse, to pick a notorious example.
But is far from what a font file is these days...
At least this is my understanding of the state of US law.
The fonts look pretty good even with the Freetype hinter turned off: part of the reason why is that we do anti-aliasing these days. And the autohinter in freetype continues to improve (which also avoids the patents).
And Linux is even more important/likely to get to serious volume in parts of the world where the TrueType patents do not apply: they are only US and Britain.
1) We hope a preliminary version of the fonts will be available next week for download, but no redistribution. They still need some work; consider this a beta test.
2) We hope finished fonts will be available in a month or so, after Jim Lyles (the font designer) has finished them up. We need a few changes: the font family Vera is derived from (Prima) has "0" and "O" too hard to distinguish, and similarly for "1" and "l", given our often technical audience.
There is also some work on hinting, etc, to finish up.
When finished, they will go under a copyright which allows you (roughly) to fold, spindle, and mutilate the fonts, so long as you change the name to something else, and you can sell them so long as you don't sell them by themselves. You can sell them with any software whatsoever. You can freely redistribute the fonts anywhere, anytime, unmodified under that name.
The sale provision is that Bitstream does not want other font vendors to just drop the fonts into their font sale mechanisms and sell them, something they are giving away.
I can't say I blame them.
3) the coverage of these fonts is roughly western european; there is the possibility of some fonts in the future with wider coverage, but as that those fonts are not yet complete, I don't want to say much more, as their availability is much less certain.
4) You can get a good idea of what the fonts look like and what the coverage is by the following URL (once the slashdot effect allows Bitstream to recover).
5) the agreement also covers potentially adding characters to the family under the Bitstream Vera name, but Bitstream (and Gnome) reserve the right to approve the additions: we want to *know* when we open fonts of these names that we have what we expect. Feel free to hack to your hearts content under other names, however.
A not widely or well understood fact about the MIT license is that it contains an implicit patent grant, something that I was unaware of until recently. (So what I had been nervous about with MIT/Berkeley licensed code for years turns out *NOT* to be true; we do have things reasonably covered.)
Scott Peterson, HP's intellectual property expert on open source licenses who is also on the W3C working group with Bruce clarified this to me a few months ago, something I had not understood despite being one of the people who helped write the MIT license.
An MIT license does allow a company this flexibility: this flexibility is not a bad thing, if it results in our ability to distribute code that would otherwise be unavailable to us.
What is more, there is good case law about how far afield you can go in taking this implied grant of patent into other areas. Nearby uses are fine, but if you go far afield, you don't get use.
Let me give a concrete example: I know of an algorithm that HP holds patents on that we may want to use for window system use, also used in our printers. (This is more than a hypothetical case, though it looks like technology may advance to where we don't need to bother). I think it likely if we need to use that algorithm we'll be able to write an implementation and use it in X under an MIT license, but it is extremely unlikely that HP could/would/should choose to allow it to be used for arbitrary purposes. The very nature of the MIT license along with the case law in this case would work in our favor to have access to that technology (if we need it; not yet clear); but I guarantee it would never be available under a GPL.
We need a situation, as Bruce says, which allows companies to cooperate in areas we care about without them going to other, much less benign standards venues. And many of them *will* go elsewhere, if this gets pushed too far.
So I believe that not only is this result good, but better than we could have hoped for even a year or two ago.
- Jim Gettys
Rotation is used, for example, on the iPAQ PDA, so that you can choose either landscape or portrait mode. It is also useful on tablets, some other circumstances.
Keith and I discussed mirroring when we originally designed RandR, but couldn't come up with a plausible need.
Then at a conference, someone came up to me and said they wanted to implement a Heads-UP display using a Laptop on their dashboard.
RandR as implemented and integrated into the XFree86 server differs in one substantial fashion from the design discussed in that paper: that is, RandR 1.0 does not implement the depth switching described in that document, and the support described for that in the protocol in that document and in the XFree86 implementationhas been removed from the protocol described here, as it has been overtaken by events.
These events include:
o Modern toolkits (in this case, GTK+ 2.x) have progressed to the point
of implementing migration between screens of arbitrary depths
o The continued advance of Moore's law has made limited amounts of VRAM
less of an issue, reducing the pressure to implement depth switching
on laptops or desktop systems
o The continued decline of legacy toolkits whose design would have
required depth switching to support migration
o The lack of depth switchin implementation experience in the
intervening time, due to events beyond our control
Additionally, the requirement to support depth switching might complicate other re-engineering of the device independent part of the X server that is currently being contemplated.
Rather than further delaying RandR's widespread deployment for a feature long wanted by the community (resizing of screens, particularly on laptops), or the deployment of a protocol design that might be flawed due to lack of implementation experience, we decided to remove depth switching from the protocol. It may be implementated at a later time if resources and interests permit as a revision to the protocol described here, which will remain a stable base for applications. The protocol described here has been implemented in the main XFree86 server, and more fully in the TinyX implementation in the XFree86 distribution, which fully implements resizing, rotation and reflection.
There were certainly wars over NeWS: SGI went with NeWS; and the subsequent GUI wars froze X development.
I programmed Forth extensively: I therefore have an informed opinion about postscript (arguably postscript is a bit less ugly the Forth, but both have fundamental flaws).... I have great respect for James Gosling's work on Java...
Sun's views on code/standards are well known: they like any they control. They tried this with NeWS by not making it available freely; it failed. The've been doing the same thing with Java, which has not succeeded the way it might have, due to this action.
It is also the case that I said little about NeWS at the time: your claim of other behavior is not borne out by reality. There was, however, tons of mud being thrown by the companies in all directions, but very little of it from me...
- Jim
Actually, there is a fundamental difference between NeWS and what is being done in Render (and Carl and Keith's latest work).
NeWS implemented postscript in a display server; Render is only implementing the imaging primitives in the X server (in this case, AA, alphablended trapezoids), leaving anything like Postscript (or pick your favorite other graphics library) to be implemented as a client side library.
If you think Postscript is a good extension language (which NeWS was based on), you need your head examined. And machines of that era could not rely solely on a Postscript imaging model (insufficient display bandwidth available for imaging applications). What is feasible today on 1000 mip machines for applications is quite different than the 1 mip machines of that era.
Now if you want an extension language in the X server, try something like Java: note that James Gosling saw the errors of his ways with that language.... It would make infinitely more sense than NeWS ever did.
And yes, lots of time was lost: the UNIX vendors fought with each other for years rather than helping X move on. See my Usenix invited talk.
http://www.usenix.org/events/usenix2000/invitedt al ks/gettys_html/img0.htm
If you want to have something "better", either help the current efforts, or go write your own window system. Grousing about the current state of things when you aren't doing either isn't acceptable. Note that we have been learning from much research in the intervening time: Plan 9's window system is the basis for the render work; it has blazed the way for a much better imaging model with great simplicity and power.
But I never believed NeWS was the answer (then again, I'm biased).
Xlib has both I18N code and CMS code that should never have been put in it.
I'm going to strip them out into separate shared libraries that only get loaded if an application uses them. The I18N code is generally replicated independently in toolkits, and the CMS (color management system) stuff is seldom if ever used.
This will preserve binary compatibility, and save at least.5 megabytes... - Jim
If you look at the iPAQ H3600 spec on handhelds.org, you'll find that the internal connectors are documented: if you want to do head mounted displays, or drive some other display, happy hacking.
You should also look at the Special Issue of "Software Practice and Experience" on the X Window System: it has all the most interesting X papers (and the original of the X11 paper) in one place.
W was a window system done by Paul Asente with Brian Reid for Stanford's V system, in reaction to VGTS. As you can see, we only followed in the footsteps of others in this alphabet soup.
So when we made the changes that it was no longer reasonable to to call it W (asynchonous requests, and no display lists- immediate mode only), we called it X, in tribute to W. We toyed with the idea of changing X's name later to reduce confusion (binding the free variable was a terrible thing to have done!), but it was realistically too late: X succeeded much faster than any delusions we might have had.
The asyncronicity was needed as RPC on UNIX was over 10 times slower than the calls on V, so performance of W under UNIX was very poor.
Getting rid of display lists was also a key change: we needed immediate mode graphics, and understood that you could always implement display lists in the client.
The major X innovation is in fact in window management, leaving management of windows to external window managers, rather than building this in. This has been a two edge sword: allowing long term evolution on management UI's, but also causing alot of disunity of UI, which can be a problem for end users. Over-all, I believe this was a correct decision: it has allowed X to continue to evolve and its UI to improve. Unfortunately, until recently alot of the UI's built have been lame: but as you can now see, X's design has been reasonably sound.
This is rougly correct: at Project Athena, a joint project between Digital, MIT and IBM, we needed a window system. But IBM would not license Andrew to Digital under reasonable terms, and one of the goals of Athena was to use the same software across Digital and IBM hardware.
So we had to roll our own (the collaboration between myself and Bob Scheifler continued; X itself started before the serious examination of Andrew as a possibility). IBM's failure to license Andrew killed Andrew, and caused X to see serious development.
Note that IPR developed by people working on Project Athena was owned by MIT, rather than by Digital or IBM (with licenses to Digital and IBM), rather than in the Andrew case, where the IPR developed on Andrew was owned by IBM. CMU got a poor deal, and doomed much/most of the output of that project.
I believe IBM's decision was in fact pivotal in the success of X, ironically.
The size of the X server on Itsy is under 700K, courtesy of Keith Packard's new frame buffer code; contrast this with your current X server weighing in at 2 megabytes. This is due to the changes in machine speeds over the last decade. (Note that Keith did the previous frame buffer code: but on 10 mip machines, you had to do things differently to drive a frame buffer flat out).
DDX's are beginning to cut over to this code, so expect your X servers to get smaller over the next year or two.
Keith is also working on an anti-aliased text and graphics with alpha blending extension: come hear his paper this summer at Usenix.
Oh, and someone said X is 20 years old: incorrect, the first thing called X was created less than 16 years ago, and X11's design is about 12 years old.
The indication of interest closure was for people NOT invited by Red Hat to participate. (anotherwords, for random E*TRADE customers).
Those who were, can still express interest, though you may have to do so by telephone (as I did).
Their phone number is 1-800-STOCKS5.
You'll still have to have an account already set up, and mention the directed share affinity program (and you may need the invitation mail in front of you to verify you were invited).
It wasn't quite as glacial as one might think. The draft standard was approved in March; the RFC issued recently when the RFC editor caught up on backlog. The internet drafts have not had a significant change for nearly a year. Most vendors have been working to the ID's for a long time.
HTTP/1.1 has already been pretty widely deployed: this was the approval of the draft standard, rather than the proposed standard.
As to performance stuff, see: http://www.w3.org/Protocols/HTTP/Performance/
As to recovering IP addresses, most clients have been sending the host name as part of the request using the HOST header for a long while. This means you can distinguish different web sites without depending on the IP address to distinguish them. - Jim Gettys HTTP/1.1 editor.
Slashdot Mirror
The inventor of the video game is Steve Russell,
8 .htma r-Arti cle.html
et. al., who wrote the first video game, "Spacewar" on the PDP-1 at MIT in 1962.
See: http://inventors.about.com/library/weekly/aa09019
http://ed-thelen.org/comp-hist/PDP-1-SpaceW
- Jim
I beg to differ:
1) fonts include programs internally these days.
2) I believe this applies to the shape of the glyphs, not te bag of bits. So you can build fonts that look like some other fonts, but not just take the bits as is.
This is how you get Times New Roman that looks like Times Roman. Someone built a font from scratch that looks the same.
So copyright law does not protect the shapes of characters themselves against mimicry, as it does with, say, the design of Micky Mouse, to pick a notorious example.
But is far from what a font file is these days...
At least this is my understanding of the state of US law.
The fonts look pretty good even with the Freetype hinter turned off: part of the reason why is that we do anti-aliasing these days. And the autohinter in freetype continues to improve (which also avoids the patents).
And Linux is even more important/likely to get to serious volume in parts of the world where the TrueType patents do not apply: they are only US and Britain.
Which their license specifically prohibits sale.
So the Microsoft web fonts can't be bundled and sold as part of a Linux (or other) distro.
The point here is to have some good fonts so that we look good "out of the box" until additional fonts are available. Right now, we don't...
1) We hope a preliminary version of the fonts will be available next week for download, but no redistribution. They still need some work; consider this a beta test.
2) We hope finished fonts will be available in a month or so, after Jim Lyles (the font designer) has finished them up. We need a few changes: the font family Vera is derived from (Prima) has "0" and "O" too hard to distinguish, and similarly for "1" and "l", given our often technical audience.
There is also some work on hinting, etc, to finish up.
When finished, they will go under a copyright which allows you (roughly) to fold, spindle, and mutilate the fonts, so long as you change the name to something else, and you can sell them so long as you don't sell them by themselves. You can sell them with any software whatsoever. You can freely redistribute the fonts anywhere, anytime, unmodified under that name.
The sale provision is that Bitstream does not want other font vendors to just drop the fonts into their font sale mechanisms and sell them, something they are giving away.
I can't say I blame them.
3) the coverage of these fonts is roughly western european; there is the possibility of some fonts in the future with wider coverage, but as that those fonts are not yet complete, I don't want to say much more, as their availability is much less certain.
4) You can get a good idea of what the fonts look like and what the coverage is by the following URL (once the slashdot effect allows Bitstream to recover).
http://store.bitstream.com/searchresults.asp?se
Now you know where the name Vera comes from
5) the agreement also covers potentially adding characters to the family under the Bitstream Vera name, but Bitstream (and Gnome) reserve the right to approve the additions: we want to *know* when we open fonts of these names that we have what we expect. Feel free to hack to your hearts content under other names, however.
I agree emphatically with Bruce!
A not widely or well understood fact about the MIT license is that it contains an implicit patent grant, something that I was unaware of until recently. (So what I had been nervous about with MIT/Berkeley licensed code for years turns out *NOT* to be true; we do have things reasonably covered.)
Scott Peterson, HP's intellectual property expert on open source licenses who is also on the W3C working group with Bruce clarified this to me a few months ago, something I had not understood despite being one of the people who helped write the MIT license.
An MIT license does allow a company this flexibility: this flexibility is not a bad thing, if it results in our ability to distribute code that would otherwise be unavailable to us.
What is more, there is good case law about how far afield you can go in taking this implied grant of patent into other areas. Nearby uses are fine, but if you go far afield, you don't get use.
Let me give a concrete example: I know of an algorithm that HP holds patents on that we may want to use for window system use, also used in our printers. (This is more than a hypothetical
case, though it looks like technology may advance to where we don't need to bother). I think it likely if we need to use that algorithm we'll be able to write an implementation and use it in X under an MIT license, but it is extremely unlikely that HP could/would/should choose to allow it to be used for arbitrary purposes. The very nature of the MIT license along with the case law in this case would work in our favor to have access to that technology (if we need it; not yet clear);
but I guarantee it would never be available under a GPL.
We need a situation, as Bruce says, which allows companies to cooperate in areas we care about without them going to other, much less benign standards venues. And many of them *will* go elsewhere, if this gets pushed too far.
So I believe that not only is this result good, but better than we could have hoped for even a year or two ago.
- Jim Gettys
Then you'll like the changes in GTK2.2 (though
we have some additional work before all this
hangs together).
The next GTK release has the capability for
applications to migrate from one X server to another.
What is left is the signalling mechanism (which
needs decent authentication) so that apps know
when to migrate.
- Jim
Rotation is used, for example, on the iPAQ PDA,
so that you can choose either landscape or
portrait mode. It is also useful on tablets,
some other circumstances.
Keith and I discussed mirroring when we originally
designed RandR, but couldn't come up with a
plausible need.
Then at a conference, someone came up to me and
said they wanted to implement a Heads-UP display
using a Laptop on their dashboard.
I said: "Sold!".
So we implemented it.
- Jim
Unfortunately not. From the spec as implemented.
RandR as implemented and integrated into the XFree86 server differs in
one substantial fashion from the design discussed in that paper: that
is, RandR 1.0 does not implement the depth switching described in that
document, and the support described for that in the protocol in that
document and in the XFree86 implementationhas been removed from the
protocol described here, as it has been overtaken by events.
These events include:
o Modern toolkits (in this case, GTK+ 2.x) have progressed to the point
of implementing migration between screens of arbitrary depths
o The continued advance of Moore's law has made limited amounts of VRAM
less of an issue, reducing the pressure to implement depth switching
on laptops or desktop systems
o The continued decline of legacy toolkits whose design would have
required depth switching to support migration
o The lack of depth switchin implementation experience in the
intervening time, due to events beyond our control
Additionally, the requirement to support depth switching might
complicate other re-engineering of the device independent part of the
X server that is currently being contemplated.
Rather than further delaying RandR's widespread deployment for a
feature long wanted by the community (resizing of screens,
particularly on laptops), or the deployment of a protocol design that
might be flawed due to lack of implementation experience, we decided
to remove depth switching from the protocol. It may be implementated
at a later time if resources and interests permit as a revision to the
protocol described here, which will remain a stable base for
applications. The protocol described here has been implemented in the
main XFree86 server, and more fully in the TinyX implementation in the
XFree86 distribution, which fully implements resizing, rotation and
reflection.
At least I'm not an anonymous coward...
There were certainly wars over NeWS: SGI went with NeWS; and the subsequent GUI wars froze X development.
I programmed Forth extensively: I therefore have an informed opinion about postscript (arguably postscript is a bit less ugly the Forth, but both have fundamental flaws).... I have great respect for James Gosling's work on Java...
Sun's views on code/standards are well known: they like any they control. They tried this with NeWS by not making it available freely; it failed. The've been doing the same thing with Java, which has not succeeded the way it might have, due to this action.
It is also the case that I said little about NeWS at the time: your claim of other behavior is not borne out by reality. There was, however, tons of mud being thrown by the companies in all directions, but very little of it from me...
- Jim
Actually, there is a fundamental difference between NeWS and what is being done in Render (and Carl and Keith's latest work).
t al ks/gettys_html/img0.htm
NeWS implemented postscript in a display server; Render is only implementing the imaging primitives in the X server (in this case, AA, alphablended trapezoids), leaving anything like Postscript (or pick your favorite other graphics library) to be implemented as a client side library.
If you think Postscript is a good extension language (which NeWS was based on), you need your head examined. And machines of that era could not rely solely on a Postscript imaging model (insufficient display bandwidth available for imaging applications). What is feasible today on 1000 mip machines for applications is quite different than the 1 mip machines of that era.
Now if you want an extension language in the X server, try something like Java: note that James Gosling saw the errors of his ways with that language.... It would make infinitely more sense than NeWS ever did.
And yes, lots of time was lost: the UNIX vendors fought with each other for years rather than helping X move on. See my Usenix invited talk.
http://www.usenix.org/events/usenix2000/invited
If you want to have something "better", either help the current efforts, or go write your own window system. Grousing about the current state of things when you aren't doing either isn't acceptable. Note that we have been learning from much research in the intervening time: Plan 9's window system is the basis for the render work; it has blazed the way for a much better imaging model with great simplicity and power.
But I never believed NeWS was the answer (then again, I'm biased).
I was born before getty was, thank you very much... Ken and Dennis must have been thinking of me...
You need to install an up to date X server
(XFree86 CVS, or the shortly to be released
4.0.2).
Otherwise, you'll still be using the core fonts.
up for access...
I think the flamers out there will now be very disappointed
that there is one less thing to flame at...
As various people have noted, shooting first and
asking questions later isn't a way to win friends
and influence people...
- Jim Gettys
- Jim
There are alot of things you can do with a Linux kernel that are difficult/impossible on the alternatives.
Xlib has both I18N code and CMS code that should never have been put in it.
I'm going to strip them out into separate shared libraries that only get loaded if an application uses them.
The I18N code is generally replicated independently in toolkits, and the CMS (color management system) stuff is seldom if ever used.
This will preserve binary compatibility, and save at least
- Jim
If you look at the iPAQ H3600 spec on handhelds.org, you'll find that the internal
connectors are documented: if you want to
do head mounted displays, or drive some other
display, happy hacking.
- Jim
You should also look at the Special Issue of
"Software Practice and Experience" on the X Window
System: it has all the most interesting X papers
(and the original of the X11 paper) in one
place.
So when we made the changes that it was no longer reasonable to to call it W (asynchonous requests, and no display lists- immediate mode only), we called it X, in tribute to W. We toyed with the idea of changing X's name later to reduce confusion (binding the free variable was a terrible thing to have done!), but it was realistically too late: X succeeded much faster than any delusions we might have had.
The asyncronicity was needed as RPC on UNIX was over 10 times slower than the calls on V, so performance of W under UNIX was very poor.
Getting rid of display lists was also a key change: we needed immediate mode graphics, and understood that you could always implement display lists in the client.
The major X innovation is in fact in window management, leaving management of windows to external window managers, rather than building this in. This has been a two edge sword: allowing long term evolution on management UI's, but also causing alot of disunity of UI, which can be a problem for end users. Over-all, I believe this was a correct decision: it has allowed X to continue to evolve and its UI to improve. Unfortunately, until recently alot of the UI's built have been lame: but as you can now see, X's design has been reasonably sound.
- Jim
This is rougly correct: at Project Athena, a joint project between Digital, MIT and IBM, we needed a window system. But IBM would not license Andrew to Digital under reasonable terms, and one of the goals of Athena was to use the same software across Digital and IBM hardware.
So we had to roll our own (the collaboration between myself and Bob Scheifler continued; X itself started before the serious examination of Andrew as a possibility). IBM's failure to license Andrew killed Andrew, and caused X to see serious development.
Note that IPR developed by people working on Project Athena was owned by MIT, rather than by Digital or IBM (with licenses to Digital and IBM), rather than in the Andrew case, where the IPR developed on Andrew was owned by IBM. CMU got a poor deal, and doomed much/most of the output of that project.
I believe IBM's decision was in fact pivotal in the success of X, ironically.
- Jim
A few factoids to add to the discussion.
The size of the X server on Itsy is under 700K, courtesy of Keith Packard's new frame buffer code; contrast this with your current X server weighing in at 2 megabytes. This is due to the changes in machine speeds over the last decade. (Note that Keith did the previous frame buffer code: but on 10 mip machines, you had to do things differently to drive a frame buffer flat out).
DDX's are beginning to cut over to this code, so expect your X servers to get smaller over the next year or two.
Keith is also working on an anti-aliased text and graphics with alpha blending extension: come hear his paper this summer at Usenix.
Oh, and someone said X is 20 years old: incorrect, the first thing called X was created less than 16 years ago, and X11's design is about 12 years old.
Compaq sells the T1500 (announced a week or two
x .html
ago), which is a Linux based thin client.
See:
http://www.compaq.com/products/thinclients/inde
The indication of interest closure was for people
NOT invited by Red Hat to participate. (anotherwords, for random E*TRADE customers).
Those who were, can still express interest, though
you may have to do so by telephone (as I did).
Their phone number is 1-800-STOCKS5.
You'll still have to have an account already set up, and mention the directed share affinity program (and you may need the invitation mail
in front of you to verify you were invited).
So don't panic yet!
It wasn't quite as glacial as one might think.
The draft standard was approved in March; the
RFC issued recently when the RFC editor caught
up on backlog. The internet drafts have not had
a significant change for nearly a year. Most
vendors have been working to the ID's for a long
time.
HTTP/1.1 has already been pretty widely deployed:
this was the approval of the draft standard,
rather than the proposed standard.
As to performance stuff, see:
http://www.w3.org/Protocols/HTTP/Performance/
As to recovering IP addresses, most clients
have been sending the host name as part of the
request using the HOST header for a long while.
This means you can distinguish different web sites
without depending on the IP address to distinguish
them.
- Jim Gettys
HTTP/1.1 editor.