On 7 Nov 2002, Brian K. Jones wrote: >> And we've done that, by allowing backward compatibility. I think >> people would be somewhat upset, if I were to disable the xfs font >> server, and core X server support, and ship only Xft2. Think >> about it. > >How can you say you have allowed for backward compatibility, and then >say the following? Very simple. See below... >> Well, both GNOME and KDE require Xft, so getting rid of Xft would >> involve getting rid of GNOME and KDE, and deleting core libraries >> that are a part of XFree86. Users are free to do that of course, >> it is open source afterall. Such systems would be unsupported >> however. > >This doesn't sound to me like backward compatibility. In fact, >it sounds like I HAVE to use this new font system if I want to >use pretty much anything my users expect to see. You are not understanding backward compatibility. Backward compatibility hs nothing at all to do with new software continuing to do things in a manner which is the same as the old software. Backward compatibility is about old software continuing to work with new software, in this case the whole OS. Installing a GTK1 application and having it work, even though the main OS is using GTK2 for most things is legacy compatibility. Providing those GTK1 libraries is providing backward compatibility. Providing xfs, mkfontdir, ttmkfdir, etc. is providing backward compatibility. The stuff shipped with the OS doesn't have to _use_ that legacy compatibility stuff at all. If it does, then it does, but if it doesn't - that has nothing to do with compatibility. >Backward compatibility means I have a choice of doing things the >old way, or that doing things the old way will either work for >everything, or seamlessly be translated to the new way in the >background. No, that is not what backward compatibility means at all. First of all, backward compatibility goes _one_ way, it doesn't go both ways. An example of backward compatibility is XFree86 and kernel DRM. Every XFree86 release comes with a new set of kernel DRM modules that are required for DRI to work correctly and provide 3D acceleration infrastructure. In order for you to use the new XFree86 release, your kernel _must_ have the new kernel DRM modules. The new kernel DRM modules for XFree86 4.2.0 for example are backward compatible with XFree86 4.1.0. What this means, is that by using the new kernel DRM from 4.2.0, you can now run XFree86 4.2.0 properly, and you can run XFree86 4.1.0 also, since the new kernel DRM is backward compatible. You may not use the XFree86 4.1.0 kernel DRM however with XFree86 4.2.0, because new features and functionality are added to 4.2.0 that was not present in 4.1.0, so the old kernel modules do not have the features that the new XFree86 kernel DRM provides. To continue the analogy to XFree86, what you are requesting, is that GNOME2 use xfs optionally. That is like XFree86 4.2.0 being able to optionally use DRM 4.1.0 in a sense. Granted, my comparison isn't a tight comparison, but I hope it gets the point across. XFree86 4.2.0 requires new features of the new kernel DRM in order to work, and so you must use this new DRM. Likewise, GNOME2 is using new features of XFree86, and so you must use this new XFree86 if you want to use GNOME2. That isn't breaking backward compatibility, in fact it has nothing to do with compatibility at all in any way. Backward compatibility in this case, is the ability for you to install GNOME 1 applications and have them work in the OS still. New technology, and new applications, or new versions of applications can use new technology, and by them doing so, that does not have anything to do with breaking backward compatibility. It changes the way things work, yes. But it does not prevent software from functioning. >Also note that 'fontconfig' doesn't appear to be an end user tool. Why >is it sort of portrayed as one in the Release Notes, which make it sound >like you can run fontconfig and everything will be dandy? Getting to >know this is system is a non-trivial event. Perhaps we need to make a new certification. RHFE - Red Hat Font Engineer. I mean really, come on. This isn't rocket science. >> >I did not imagine this *library* was a 'random Red Hat thing'. The fact that >> >they've decided to shove it down my throat is a bit inconvenient though. >> >> It's not shoved down your throat. Legacy fonts using core server >> fonts are supported now as much as they ever have been. > >I'll refer you to the release notes, and to your earlier comments about >how this is NOT true. As you've said, GNOME and KDE require Xft, and >it's now a core X library. Inasmuch as there's not really much of a >choice in how I configure fonts, that's pretty much shoving it down my >throat, no? While the 'fonts' are supported, the implementation has >changed. Choice is good for some things, yes. But providing 400 ways of doing something, and continuing to support that indefinitely does not create a better system. With Xft2, and with GNOME2 using Xft2, there really is no good reason to use core server fonts at all. "Because I am used to configuring xfs" is not a good reason. If you consider that "ramming Xft down your throat" then sobeit. We are ramming Xft down your throat. Better get used to it though because Mozilla is now ported to Xft, and most other major software projects are being ported to Xft also. The remaining GNOME/GTK applications that are not using GNOME 2 yet, will be likely in the next OS release, or perhaps the one after that, and most other sensible projects will be using Xft also. Some legacy software possibly wont change for a while, or possibly not at all. It's also important to note that Red Hat is not making decisions for everyone, or for various projects out there. Rather, XFree86.org is providing new technology that is better than past technology, and various projects such as GNOME, KDE, Mozilla, and others are simply looking at this technology and deciding that it is better, and the proper way to go, and using it. Red Hat is simply doing 2 things here: 1) Helping to contribute code to these projects, and 2) Using these projects code in our OS, and benefiting from the projects using new technology like Xft. We don't control anything. So if you want to complain that some project or program switched to Xft and no longer uses core server fonts - Red Hat isn't the place to complain. Complain to the developers who wrote the given program, or project. Sorry, but softare evolves, and as it evolves things change. New interfaces and API's are developed, and new versions of software take advantage of these new API's to gain new functionality. When a new API is available for software to use that is superior to some old API, and the software is updated to use the new API, generally unless there is some compelling major reason to use the old API still, it is beneficial all around not to. There's simply no good reason whatsoever for GNOME to use core server fonts. If you disagree, feel free to use some older version of the OS, or to switch distributions. Note however that all distributions will be doing the same thing. >> >Agreed. In addition, having this new technology and not telling >> >people what the heck is going on and how to hack this beast into >> >submission is also less than useful to some of us. I can't >> >deploy until I know what's going on - in gory detail - with >> >probably about 40% of the packages on the Redhat CDs. Xft would >> >be one of those packages. >> >> Xft is installed automatically. You don't need to know about it >> at all, or even know it exists. > >This mentality may work for a home user. It does not work for >people who maintain and support it for a bunch of other users. >And what am I to say to the department chair who is working with >someone who wants to read Hebrew on her screen and is having >issues because the fonts don't render 'properly' or >consistently? "Sorry boss, I don't know how those fonts even >get there? I didn't even know there was a font rendering >interface?" That's unacceptable. At some point I guess one has >to come to terms with the fact that it's nearly impossible to >know everything, and you pick your battles. This is one I sorta >have to battle with whether I like it or not. Well, if it is not documented clearly in any of the official Red Hat Linux manuals that come with the distribution in hard copy, or are available on ISO image or online, then I would consider this a possible problem that needs to get fixed. I haven't looked in the documentation to find out if we've documented this or not, as I assume we have. If font configuration is not covered in our manuals, or is incorrect or incomplete, then you may very well have a legitimate complaint, and I urge you to file a bug report in bugzilla against our documentation. If it is documented, then I urge you to read it. >> Linux on the desktop needs to be simplified greatly if it is >> going to be a contender against Microsoft. > >Agreed. It also needs to look prettier :-) I, for one, am glad >there are people who like hacking with things like fonts. I >have neither the eye nor the patience for them. Nor do I, which is why I'm glad that Owen Taylor has taken over most font related things now, so I don't have to pull out my hair. <grin> >FWIW, I happen to like the way the fonts look these days. I >*want* to get to know this system, and I will in time. I don't >hate Red Hat, and I don't hate the XFree people. I don't hate >new technology, and I've read the release notes. I thank you >for your input and the information, which I've found invaluable. >Undoubtedly, in a few months I'll be answering Xft questions on >this very list. Well that is good to hear. In the end, *everyone* must realize that software changes. It evolves, and the reason that it evolves, is because there are people out there who want it to evolve, to do more things, to become easier to use, to use better technology, to solve new problems. Some people are happy with the way things are, or the way things were, and are upset of changes. That is natural preference of individualism. People who do not like change, and like things "the old way" should just never upgrade, or should selectively upgrade individual things. Each new Red Hat Linux operating system will indeed change things. Some things it will change drastically, others it will change slightly, and also some things will remain the same. This is not ever going to stop. Software just doesn't sit still. If it did, there would be few compelling reasons to ever upgrade. The fact is that the majority of people out there want Linux to be easier, and want things that can autoconfigure to do so. Anything that could potentially "just work" *should* "just work". That doesn't mean things shouldn't be configureable mind you (although Havoc might disagree here <grin>), but it does mean that a fresh OS install, if at all possible should provide the user with a generic OS, that has sane defaults for the general case, with as much hardware and software autoconfigured as possible. The user/admin/whatever then can customize their system by raising or lowering the default security with various software, they can customize various things, install add ons, etc. Things should just work and do so preferably without requiring user intervention if possible. IMHO, that is one of our goals, or it is one of mine at least. Software evolutionary changes do however sometimes come with growing pains, where there is a transitionary period between two technologies or somesuch. Fonts are one of those transitionary things. UTF-8 is another one of those transitionary things. I'm sure there are various other things too that I'm forgetting. In the end, users just have to deal with these things, one way or another. Nothing can be 100% perfect. The best that we can do, is to harness the best open source technology that is available out there, either produced by collective open source projects, or produced internally at Red Hat and contributed to the community. By doing that, and embracing what we feel is the best technology, and presenting it to our users in our products, hopefully Linux can meet the needs of more and more users out there, and solve more and more problems for people. If there is one thing that would bother me, it would be to see us hold back on some technology because we fear that some minority of users are going to be upset of a given change. We must move forward in order to succeed, and along the way, that means that some people are going to have to learn new ways of doing things if they want to stay current with progress. Hopefully we document things well enough that the people who actually read our documentation can learn how to properly use the OS, and get their work done. I'm pretty sure that we want to hear about it though if we do not manage to document things. My experience has generally been though that most people don't bother reading the documentation and then complain that something changed and wasn't documented. New Microsoft OS's don't appear to even come with manuals - perhaps we're wasting our time producint ours. ;o) Anyway, I think I've made my points here. People are free to disagree with me, and are free to like or dislike changes that Red Hat makes to the OS. That is all part of individualism and freedom. We make the changes that we do, because we believe in the technology, and where it is going, and we want to be a big part of it getting there. Reading the various online OS reviews, and various customer feedback, both good and bad, I think we're meeting our goals, and I think customer and user satisfaction is higher than ever. There will always be people who feel the opposite way of course, but you simply can't please all of the people all of the time, and if you try to, you'll please nobody. We need to pick our goals, and try to achieve them. There will be bumps along the way, but I don't think there is any possible way to be in the software business without having bumps along the way. As long as the bumps are for the good, then I'm happy. If you or anyone has suggestions for improvements, as always, feel free to file them in bugzilla and mark them as severity "enhancement". If your request is specific to a given package, file it against that package. If it is more general, or to the OS as a whole, file it against "distribution". We do read all of these things, and we discuss them internally. Many new features and enhancements come from user requests. Just don't file flames or negative comments - we don't like those. ;o) TTYL -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer XFree86 maintainer Red Hat Inc. -- Psyche-list mailing list Psyche-list@redhat.com https://listman.redhat.com/mailman/listinfo/psyche-list
