Date: Wed, 05 Feb 2003 11:23:54 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Rahul Siddharthan <rsidd@online.fr> Cc: "Pedro F. Giffuni" <giffunip@yahoo.com>, freebsd-chat@FreeBSD.org Subject: Re: GGI (was: Project Status) Message-ID: <3E4164CA.3B1E7C30@mindspring.com> References: <20030205103556.B7212@papagena.rockefeller.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Rahul Siddharthan wrote: > Pedro F. Giffuni wrote: > > As a short summary some of us want o turn FreeBSD into > > a decent desktop by providing high quality graphics > > support in the kernel. > > I don't think this is what's holding back FreeBSD (or Linux) at all. > It's an old logical fallacy: Windows has graphics support in the > kernel; Windows is successful; so if we have graphics support in the > kernel, we'll be successful. Actually, the main reason for it is to provide graphics support for programs, including X, so that you don't have to carry device driver parts around in user space. The secondary reason for it is so that when you are running X, and your kernel panics, the console gets properly dropped into the debugger, instead of leaving you screwed. The tertiary reason is so that you don't have to run graphics programs as root, in order for their user space device drivers to be able to access the hardware, and is a security issue. "Being like Windows" is far from people's minds, when they talk about GGI. In fact, GGI is very *unlike* Windows, in that the rendering primitives *remain* in user space. > XFree86 is doing great, and getting better and better, in my opinion. > What's the problem? Speed? Automated recognition of the hardware, or fallback, so that a minimum set of graphics operates by default, on all instances. This is a minimal requirement for desktop support. Basically, it boils down to "lack of productization". GGI removes one of these barriers; it does not claim to remove them all. > They're adding new features at a rapid pace -- with recent > improvements in freetype and Keith Packard's recent XFT stuff, the > font display is probably better than Windows or Mac, and the overall > ease of configuration is getting there. With XFT2 you just need to > drop a font into your ~/.fonts directory, and XFT2-aware applications > can use it. X has forever suffered from fixed cell rendering. GGI will not fix this; changing X would. Several companies have done this in the past: NeXT, with NeXTStep, Sony with NeWS, etc. It is no mistake that these people are tightly tied to Adobe, and to Apple, participated in Taligent, and helped write the Unicode standard, such that local use spaces were not interspersed, making it difficult for fixed-cell rendering systems like X to support ligatured scripts, like Tamil, Devengarl, Hebrew, and Arabic. > For the people who say X is bloated, slow, etc: X was around in the > 1980s before Microsoft Windows, and it ran quite nicely on > ridiculously slow machines. SGI became a graphics powerhouse using X. X *is* bloated. Consider "virtual desktops", where there are VNC or similar clients with "views" onto your desktop, which runs *forever* on a hosted service platform, somewhere, and never shuts down. How many instances of this can you run on a single hosting platform, before you run out of RAM? Windows isn't much better. What has to happen is that the display and rendering function need to be divided, and whatever can be shoved into the display portion, needs to be shoved into the display portion, to increas the number of instances of hosted platforms that can be run simultaneously. Who *cares* if the thing on your desk is a piece of crap, or the latest and greatest, as long as the platform your applications are actually running on isn't? > GGI looks like an interesting toy project (it's been around for a > while too). In fact, it is one of the three major projects over which the Linux project almost forked. The fork was only avoided when Linus backed down from his claim that he would "never integrate GGI into the official Linux code base". > For a decent desktop, we need to support and use the efforts of > projects like KDE and GNOME, better integrate their system management > capabilities with FreeBSD, maybe come up with a better default > configuration of these environments as part of the install. No, actually. These are just "look and feel" and applications interoperability platforms. As soon as they have standardized themes use between them, they will become commodity, and whichever one the programmers like more, probably on the basis of documentation and sample code, will win. In fact, the "look and feel" *should* live in the rendering engine, and not in the application, and the rendering engine *should* live with the display device. This offloads more work from the server running the applications, enabling it to handle a higher load, *AND* it standardizes "look and feel" for all applications which use a given display. Macintosh had this right from day 1, though they failed to seperate and standardize the communications channel from the application server to the display server. > Incidentally, one serious missing feature for desktop users, on both > FreeBSD and Linux, is packet writing software for UDF file systems > (CD-RW). (There are patches for linux.) Is anyone working on that > for FreeBSD? What about the other BSDs? There is commercial code for FreeBSD. It is the "pro" version of one of the programs whose free version is already in ports. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E4164CA.3B1E7C30>