Who's to say it couldn't write to a film puncher? It had to have some means of output or it'd be useless; whether that device was a film puncher or something else is irrelevant since one could be substituted in, or another device could be built to transcribe the output onto film.
To a compiler, the compiled program is just data, no different from a sorted list or the results of a mathematical analysis. It's just a sequence of bits which happen to be valid input to the processor. Actually feeding those bits to the processor so that it performs the instructions described is the job of the operating system, or the human operator on early computers such as this one which didn't have an OS.
According to the article, the program was stored -- on punched film. It couldn't store the program in RAM so it would just read instructions from the film as it came time to execute them, but that doesn't make it any less a stored program.
Yes... to let people who want to develop with.NET (since it really is pretty nice) do so using open-source software, and run their programs on open-source operating systems. To lower the cost of switching away from Microsoft, to those who have already committed to using.NET, and to make it possible for developers already writing programs for open-source platforms to write software that will work on Windows as well, without large amounts of porting effort.
I'm excited by Mono because I do like.NET, and along with it, VS.NET. It's easy to write code that does fairly complex things while still being readable -- compared to, say, GTK's C API, which is very powerful, and even fairly pleasant to work with, but involves lots of overhead/boilerplate code and macros that are confusing unless you're accustomed to reading it. It's easy to get used to VS.NET's code completion; going back to coding in Emacs after using VS.NET for a few days, I found myself half-expecting the tooltip documenting a function's parameters after I type the left parenthesis. So I really like the idea of being able to do those things without having to interrupt everything else I'm doing and boot Windows, and being able to use the resulting software in the same fashion.
You can paste between terminal sessions using GNOME's clipboard mechanism -- you just have to use different hotkeys (in gnome-terminal it's ctrl-shift-C to copy) since the usual ones need to be passed through to the shell (ctrl-C to abort a job, for example).
Like it or not, we need to go to full subscript checking for anything that could possibly be exploited.
Arrays of primitive types are a feature inherited from C, and the design of C is such that the compiled code is a direct translation (optimizations notwithstanding) of the source code. The compiler doesn't insert any code that you didn't write.
Added in C++ is the ability to overload operators, including the subscript operator, so you can write classes which act just like arrays, but do bounds-checking and any other custom behavior you want. The standard library even provides one: std::vector. You should always use this, or another managed array class, instead of primitive arrays, unless you have a good reason and understand the risks.
In short, the feature is already there. If you're not using it, the shortcoming is in your training as a C++ programmer, not in the C++ language.
When using the partitioner, did you realize that in addition to choosing "finish partitioning", "automatically partition", "undo changes", or "configure LVM" from the menu, you can also move the cursor up into the list of partitions and press Enter to create new partitions of any size you want, or change filesystem and mountpoint settings for existing partitions? About the only thing you can't do is see the exact size in bytes of a partition, but that's not much of a big deal; numbers like "5.3 GB" are easier to read and quite sufficient in most cases. (And you can always switch over to the second virtual console and run cfdisk yourself if you really want to.)
If I have to even think about what "drivers" I need, I consider the distribution to have failed me.
And if you have to even think about what "partitions" or "packages" you need, the distribution has failed you too, right? In that case, go run Windows. Or do you draw the line somewhere?
Speaking of which, ever notice that when installing Windows, as the setup loads itself there are a few seconds where it says something like "press F8 now if you need to load additional drivers from a disk or CD" ? Hardware detection and automatic driver loading are a convenience, but they can't be perfect, whether because of licensing issues or just because the hardware didn't yet exist when the OS was released. Debian's new installer provides that convenience in most installations, but if it's not available, it's not the end of the world.
Let's see, 32g out of a 40g drive (don't have that problem with Knoppix), no option to build multiple partitions, no swap partition? I wanted lilo, I configured lilo, lilo was already installed, it installed grub. (in expert mode)
What installer were you using? The old one runs cfdisk, and the new one has a nice menu-based partitioner that lets you edit partitions, filesystem types, and mountpoints all at once. I don't remember offhand what options it gives you for a bootloader, since I use grub anyway, but if you're using the expert install you can just skip the bootloader step if you don't want it overwriting the bootloader you already installed.
I really don't understand what the difficulty is with Debian's installer. I found it a bit challenging when I was a complete Linux newbie, but nowadays I find it much more pleasant than other OS installers I have experience with. (Redhat/Fedora, Gentoo, and OpenBSD come to mind.)
It's not really "the masses" who run Debian... it's Debian Developers. Anyone can be a DD, but you have to get a PGP key signed by another DD and go through an application process, so there's a sort of self-screening that keeps out people who don't really have that much of an interest in the project. There are lots of DDs, and it's true that most probably don't have a deep knowledge of the workings of all the software in the distribution, but they're not exactly "unwashed masses" as you portray.:-)
As far as philosophy goes, well, I think you're well on your way to proving my point with your small dissertation on democracy and voting.
Dissertation? All I'm saying is that the Debian project does what its members think best, and if you were a part of the project, you'd have a say in how things are done. That's hardly a philosophical rant.
The SSH problem you mentioned happened a few days ago, due to a mistake while tightening permissions on/dev/tty*. Prior to that, the last problem I remember was about a month and a half ago, when GConf broke for a day or two. Bugs do pop up on occasion, but that's a natural consequence of using the "unstable" branch, the front line for packages that haven't been tested yet. I find it pretty hard to believe that no Slackware package has had a bug in several years.
Standard location? In my mind, the "standard" location for a file is where Debian puts it, and I get confused when it's located somewhere else in another distribution.:-)
I get the sense that you're used to installing things via "configure; make; make install". It's good to have a simple method like that available, but when I talk about maintainability of a system, installing non-packaged software is one of the biggest ways to hurt that maintainability. Files created by a "make install" usually don't have any way to cleanly remove or upgrade them; you can upgrade by installing a new version over the old, but if the old version included any files that were removed in the new version, you still have that cruft sitting around. You get the idea.
I like the fact that Debian has lots of infrastructure. I like to know that when I install a package, it will cleanly integrate with other related packages, and when I remove it, it will cleanly go away. I like the fact that when I'm looking for a package that performs a certain function, I can often guess its name, thanks to fairly consistent naming patterns, and that when I'm looking for a file, I can usually guess where it's located due to a consistent and sensible filesystem hierarchy.
I hang out in #debian on IRC, and I read some of the mailing lists, and I see a lot more discussion on practical matters than on philosophy, and philosophical rants are pretty rare. The system works quite well for those who use it; your comment about "fixing their distribution" just doesn't apply. Remember that Debian is run democratically: if you don't like the way something's being done, you can always register as a Debian Developer and vote to do things your way. If you don't want to do that, or if you get outvoted by people who like things the way they are, you can use another distribution and nobody will hold it against you.
I suppose you're right that if your hardware needs non-free firmware then it won't be usable right away in the installer, but it's not that much of a big deal to provide the necessary driver to the installer. But I think long-run maintainability of a system, especially a server, is much more important than ease of getting it installed in the first place, and that's an area where Debian shines. (That's not to say that installation should be difficult, but someone installing an operating system on a mission-critical server should be able to get by without having his hand held the whole way, or he's probably not qualified for the job.)
Nobody's saying that your proprietary hardware will cease to work in Debian. The packages will still exist; they'll just be in the "non-free" section, separated out so that people who don't want any non-free software can omit that section from their sources.list file. Non-free packages are technically not part of Debian, but if you have a non-free line in your sources.list, there's no difference whatsoever in how you use them.
Then again, it begs the question, is Debian really a desktop OS? Debian developers seem to argue that one a lot.
Stable isn't, but with a little care and feeding, Sid is. And the care and feeding is educational -- just doing an upgrade every few days with apt-listchanges installed is a great way to learn by osmosis little tidbits about the system's workings.
Is this second box of yours a server which needs stability above all else? Or is it, as I suspect, a desktop system?
If it's a desktop system, just run Sid. Despite the "unstable" label, it's quite usable -- I've been running it on my desktop for 3.5 years and it's still running smoothly; I've never needed to reinstall, or do major recovery of any sort (aside from some filesystem corruption at one point, but that was my own fault and not Debian's). Packages break on infrequent occasions, but rarely severely, and with some common sense you can work around the problems. "unstable" doesn't mean "will crash on you"; it means "hasn't been tested enough yet to be considered stable".
I'm running kernel 2.6.5, using LVM2 on some of my disks and XFS on all my filesystems. My desktop is GNOME 2.4 on XFree86 4.3 using the 5336 release of NVidia's driver; I may install the "experimental" packages of GNOME 2.6, but I'll probably just wait a little while until they're moved into unstable. My system is up-to-date and I'm quite happy with it.
If you want to use the new installer, go download it -- it's quite usable already. If you're comfortable using your existing testing system (installing and upgrading packages, configuring things, etc.) then you'll find that Sid isn't much different. You'll run into snags on occasion, but they're minor, and you'll learn from them and be that much more knowledgeable in the future.
Most likely, the non-free stuff will not be completely removed, but rather, moved to the non-free section of the distribution. (Strictly speaking, non-free isn't part of the distribution, so things moved there have been removed from Debian, but the packages are available from the same servers, and interoperate with the free stuff.)
The NVidia drivers, for example, work just fine in Debian. Not only is the nvidia-kernel-source package available via apt-get, but it works with Debian's kernel-package build system to produce.deb packages of the built modules. The fact that the drivers are non-free don't affect me in the least; I use them the same way I use any other third-party module package.
I'm not particularly bothered by this change. I'm slightly bothered by the delay of the Sarge release, but since I run Sid on my desktop, and my servers do fine with Woody plus an occasional backport, it's not that big a deal. And it does pretty much answer the question of whether GNOME 2.6 will make it into Sarge.:-)
If you like anime, you might want to watch "Armitage the Third". It's not deeply philosophical or anything, but it explores this situation from the point of view of a humanoid "third-type" robot, who, unlike the "second-type" robots which perform menial tasks, has emotions and a personality, and suffers from the anti-robot sentiment. (She also happens to be derived from a combat design, so she can fight for what she believes in, but that's sort of a different side to the story.)
The paper you have in mind is "Distributed Ray Tracing" by Robert Cook, Thomas Porter, and Loren Carpenter, all from Lucasfilm. It was published in the ACM "Computer Graphics" publication, Volume 18, Number 3, July 1984. If you have access to the ACM Digital Library, you can find the full info and a PDF link here; otherwise, you can download my copy from here. (This redistribution is permitted by the paper's copyright notice.)
Distributed ray tracing isn't a "hack", though -- it's a fundamental principle of modern global-illumination rendering systems. Kajiya introduced the rendering equation in 1986 (ACM citation here, my copy here), and Monte Carlo integration is used as a means of solving it. Monte Carlo integration approximates the value of an integral by sampling random points in the function's domain; in graphics, the domain is the illumination in the scene, the point samples are taken by tracing rays, and the random distribution is what originated in distributed ray tracing.
POV is literally child's play compared to the software used to render movies. It isn't remotely photorealistic -- even the natural falloff of light intensity over distance due to the inverse-square law isn't properly simulated. (Instead we have an approximation using the fade_power and fade_distance keywords.) The shading model (based on pigment, finish, and interior) doesn't account for effects like anisotropic reflection and subsurface scattering that occur in nature, and the idea that RGB (1.0, 1.0, 1.0) is "white" discourages the use of high-dynamic-range lighting.
Don't get me wrong, POV is a great piece of software for learning, and I wrote a few features for it in years past (variable reflection, metallic reflection, part of conserve_energy, and a blurred-reflection feature that doesn't seem to have made it into the current version). But trying to use it for serious production graphics is like using a Talking Whiz Kid as a word processor to write a Ph.D thesis.
[...] editing it yourself shouldn't be any harder or take any longer than searching through the program menus for the right option.
True, but do you really feel like starting a new shell, opening an editor to modify the dotfile, and then (most likely) have to restart the app, just to make a simple preferences change? Not having to descend to the console to change how the GUI works is a big part of the current push for usability that some projects (especially Gnome) are currently making. And the added bonus is that when you check a box in a preferences window, the change can take effect immediately, instead of having to restart the program to make it re-read the dotfile. (Yes, it's possible to include a menu command for "re-read configuration", but I haven't seen many programs that actually do that.)
In the spirit of shared libraries, do you realize a dotfile parser can also simply be part of a shared library?
I agree that a a centralized approach to configuration settings doesn't inherently need a daemon running in a separate process to manage the settings. However, it does enable GConf's notification mechanism I mentioned earlier. That notification mechanism is a really cool thing, because settings changes can take effect immediately across the whole desktop, in all running instances of a program, without needing to restart anything.
Dotfiles offer a flexibility that's useful in some specialized situations (like using several dotfiles to run several instances of a program with different settings), but they're more cumbersome to work with overall. If you're an experienced Unix hacker, hand-editing text files is fine, but for a desktop environment meant for general use, it's important to have programmatic interfaces to everything in the system -- preferences (via GConf), available hardware (take a look at Project Utopia), and so on.
However, at some point you want to be able to remove those ancient symbols that nobody uses anymore, so the binary doesn't keep getting bigger and bigger as new code is added but none is removed. This leaves distro builders with the task of having to decide where to draw the line between "old but supported" and "too old to be worth supporting", as the old symbols can't just be installed and uninstalled separately from the rest of the library. Maybe we'll start seeing packages like "libc6-backwardcompat" and "libc6-onlycurrent".
The advantage of that approach (used by both GConf and the Windows Registry) is that it's hierarchial and allows lots of data types (strings, numbers, Booleans, etc.) while still being structured enough to be not only read but also written to, in whole or in part, by software. It also enables additional features you wouldn't get (cleanly) with plain configuration files -- for example, in Windows, different registry keys can have different security settings, and with GConf, applications can "listen" on a key and be notified immediately when a change occurs, so that preferences changes can take effect immediately across the desktop.
Of course, XML is flexible enough to store an application's configuration settings in a hierarchial format with various data types, but dealing with it directly would require every application to incorporate parsing and writing functionality for their settings files. In the spirit of shared libraries, it's better to define an API for accessing settings, to reduce the amount of boilerplate functionality that must be implemented in every app. And since you don't want a million dotfiles in your home directory, you should keep the XML in a specific location too. But at this point you basically have GConf.
I use Gnome, and I much prefer GConf over INI-type files. What bothers me most is apps that store half their settings in GConf, and the other half in a dotfile in my home directory.:-)
Slashdot Mirror
Who's to say it couldn't write to a film puncher? It had to have some means of output or it'd be useless; whether that device was a film puncher or something else is irrelevant since one could be substituted in, or another device could be built to transcribe the output onto film.
To a compiler, the compiled program is just data, no different from a sorted list or the results of a mathematical analysis. It's just a sequence of bits which happen to be valid input to the processor. Actually feeding those bits to the processor so that it performs the instructions described is the job of the operating system, or the human operator on early computers such as this one which didn't have an OS.
According to the article, the program was stored -- on punched film. It couldn't store the program in RAM so it would just read instructions from the film as it came time to execute them, but that doesn't make it any less a stored program.
Is there any good reason to use POP3 over IMAP, aside from some services not offering IMAP access?
Yes... to let people who want to develop with .NET (since it really is pretty nice) do so using open-source software, and run their programs on open-source operating systems. To lower the cost of switching away from Microsoft, to those who have already committed to using .NET, and to make it possible for developers already writing programs for open-source platforms to write software that will work on Windows as well, without large amounts of porting effort.
I'm excited by Mono because I do like .NET, and along with it, VS.NET. It's easy to write code that does fairly complex things while still being readable -- compared to, say, GTK's C API, which is very powerful, and even fairly pleasant to work with, but involves lots of overhead/boilerplate code and macros that are confusing unless you're accustomed to reading it. It's easy to get used to VS.NET's code completion; going back to coding in Emacs after using VS.NET for a few days, I found myself half-expecting the tooltip documenting a function's parameters after I type the left parenthesis. So I really like the idea of being able to do those things without having to interrupt everything else I'm doing and boot Windows, and being able to use the resulting software in the same fashion.
You can paste between terminal sessions using GNOME's clipboard mechanism -- you just have to use different hotkeys (in gnome-terminal it's ctrl-shift-C to copy) since the usual ones need to be passed through to the shell (ctrl-C to abort a job, for example).
The article you linked to refers to Henrik's BSSRDF research. It's not prior art. :-)
At least in that case, the user has no one to blame but himself, and hopefully will learn the lesson for next time.
When using the partitioner, did you realize that in addition to choosing "finish partitioning", "automatically partition", "undo changes", or "configure LVM" from the menu, you can also move the cursor up into the list of partitions and press Enter to create new partitions of any size you want, or change filesystem and mountpoint settings for existing partitions? About the only thing you can't do is see the exact size in bytes of a partition, but that's not much of a big deal; numbers like "5.3 GB" are easier to read and quite sufficient in most cases. (And you can always switch over to the second virtual console and run cfdisk yourself if you really want to.)
And if you have to even think about what "partitions" or "packages" you need, the distribution has failed you too, right? In that case, go run Windows. Or do you draw the line somewhere?
Speaking of which, ever notice that when installing Windows, as the setup loads itself there are a few seconds where it says something like "press F8 now if you need to load additional drivers from a disk or CD" ? Hardware detection and automatic driver loading are a convenience, but they can't be perfect, whether because of licensing issues or just because the hardware didn't yet exist when the OS was released. Debian's new installer provides that convenience in most installations, but if it's not available, it's not the end of the world.
What installer were you using? The old one runs cfdisk, and the new one has a nice menu-based partitioner that lets you edit partitions, filesystem types, and mountpoints all at once. I don't remember offhand what options it gives you for a bootloader, since I use grub anyway, but if you're using the expert install you can just skip the bootloader step if you don't want it overwriting the bootloader you already installed.
I really don't understand what the difficulty is with Debian's installer. I found it a bit challenging when I was a complete Linux newbie, but nowadays I find it much more pleasant than other OS installers I have experience with. (Redhat/Fedora, Gentoo, and OpenBSD come to mind.)
It's not really "the masses" who run Debian... it's Debian Developers. Anyone can be a DD, but you have to get a PGP key signed by another DD and go through an application process, so there's a sort of self-screening that keeps out people who don't really have that much of an interest in the project. There are lots of DDs, and it's true that most probably don't have a deep knowledge of the workings of all the software in the distribution, but they're not exactly "unwashed masses" as you portray. :-)
Dissertation? All I'm saying is that the Debian project does what its members think best, and if you were a part of the project, you'd have a say in how things are done. That's hardly a philosophical rant.
The SSH problem you mentioned happened a few days ago, due to a mistake while tightening permissions on /dev/tty*. Prior to that, the last problem I remember was about a month and a half ago, when GConf broke for a day or two. Bugs do pop up on occasion, but that's a natural consequence of using the "unstable" branch, the front line for packages that haven't been tested yet. I find it pretty hard to believe that no Slackware package has had a bug in several years.
Standard location? In my mind, the "standard" location for a file is where Debian puts it, and I get confused when it's located somewhere else in another distribution. :-)
I get the sense that you're used to installing things via "configure; make; make install". It's good to have a simple method like that available, but when I talk about maintainability of a system, installing non-packaged software is one of the biggest ways to hurt that maintainability. Files created by a "make install" usually don't have any way to cleanly remove or upgrade them; you can upgrade by installing a new version over the old, but if the old version included any files that were removed in the new version, you still have that cruft sitting around. You get the idea.
I like the fact that Debian has lots of infrastructure. I like to know that when I install a package, it will cleanly integrate with other related packages, and when I remove it, it will cleanly go away. I like the fact that when I'm looking for a package that performs a certain function, I can often guess its name, thanks to fairly consistent naming patterns, and that when I'm looking for a file, I can usually guess where it's located due to a consistent and sensible filesystem hierarchy.
I hang out in #debian on IRC, and I read some of the mailing lists, and I see a lot more discussion on practical matters than on philosophy, and philosophical rants are pretty rare. The system works quite well for those who use it; your comment about "fixing their distribution" just doesn't apply. Remember that Debian is run democratically: if you don't like the way something's being done, you can always register as a Debian Developer and vote to do things your way. If you don't want to do that, or if you get outvoted by people who like things the way they are, you can use another distribution and nobody will hold it against you.
I suppose you're right that if your hardware needs non-free firmware then it won't be usable right away in the installer, but it's not that much of a big deal to provide the necessary driver to the installer. But I think long-run maintainability of a system, especially a server, is much more important than ease of getting it installed in the first place, and that's an area where Debian shines. (That's not to say that installation should be difficult, but someone installing an operating system on a mission-critical server should be able to get by without having his hand held the whole way, or he's probably not qualified for the job.)
Nobody's saying that your proprietary hardware will cease to work in Debian. The packages will still exist; they'll just be in the "non-free" section, separated out so that people who don't want any non-free software can omit that section from their sources.list file. Non-free packages are technically not part of Debian, but if you have a non-free line in your sources.list, there's no difference whatsoever in how you use them.
Stable isn't, but with a little care and feeding, Sid is. And the care and feeding is educational -- just doing an upgrade every few days with apt-listchanges installed is a great way to learn by osmosis little tidbits about the system's workings.
Is this second box of yours a server which needs stability above all else? Or is it, as I suspect, a desktop system?
If it's a desktop system, just run Sid. Despite the "unstable" label, it's quite usable -- I've been running it on my desktop for 3.5 years and it's still running smoothly; I've never needed to reinstall, or do major recovery of any sort (aside from some filesystem corruption at one point, but that was my own fault and not Debian's). Packages break on infrequent occasions, but rarely severely, and with some common sense you can work around the problems. "unstable" doesn't mean "will crash on you"; it means "hasn't been tested enough yet to be considered stable".
I'm running kernel 2.6.5, using LVM2 on some of my disks and XFS on all my filesystems. My desktop is GNOME 2.4 on XFree86 4.3 using the 5336 release of NVidia's driver; I may install the "experimental" packages of GNOME 2.6, but I'll probably just wait a little while until they're moved into unstable. My system is up-to-date and I'm quite happy with it.
If you want to use the new installer, go download it -- it's quite usable already. If you're comfortable using your existing testing system (installing and upgrading packages, configuring things, etc.) then you'll find that Sid isn't much different. You'll run into snags on occasion, but they're minor, and you'll learn from them and be that much more knowledgeable in the future.
Most likely, the non-free stuff will not be completely removed, but rather, moved to the non-free section of the distribution. (Strictly speaking, non-free isn't part of the distribution, so things moved there have been removed from Debian, but the packages are available from the same servers, and interoperate with the free stuff.)
The NVidia drivers, for example, work just fine in Debian. Not only is the nvidia-kernel-source package available via apt-get, but it works with Debian's kernel-package build system to produce .deb packages of the built modules. The fact that the drivers are non-free don't affect me in the least; I use them the same way I use any other third-party module package.
I'm not particularly bothered by this change. I'm slightly bothered by the delay of the Sarge release, but since I run Sid on my desktop, and my servers do fine with Woody plus an occasional backport, it's not that big a deal. And it does pretty much answer the question of whether GNOME 2.6 will make it into Sarge. :-)
If you like anime, you might want to watch "Armitage the Third". It's not deeply philosophical or anything, but it explores this situation from the point of view of a humanoid "third-type" robot, who, unlike the "second-type" robots which perform menial tasks, has emotions and a personality, and suffers from the anti-robot sentiment. (She also happens to be derived from a combat design, so she can fight for what she believes in, but that's sort of a different side to the story.)
The paper you have in mind is "Distributed Ray Tracing" by Robert Cook, Thomas Porter, and Loren Carpenter, all from Lucasfilm. It was published in the ACM "Computer Graphics" publication, Volume 18, Number 3, July 1984. If you have access to the ACM Digital Library, you can find the full info and a PDF link here; otherwise, you can download my copy from here. (This redistribution is permitted by the paper's copyright notice.)
Distributed ray tracing isn't a "hack", though -- it's a fundamental principle of modern global-illumination rendering systems. Kajiya introduced the rendering equation in 1986 (ACM citation here, my copy here), and Monte Carlo integration is used as a means of solving it. Monte Carlo integration approximates the value of an integral by sampling random points in the function's domain; in graphics, the domain is the illumination in the scene, the point samples are taken by tracing rays, and the random distribution is what originated in distributed ray tracing.
POV is literally child's play compared to the software used to render movies. It isn't remotely photorealistic -- even the natural falloff of light intensity over distance due to the inverse-square law isn't properly simulated. (Instead we have an approximation using the fade_power and fade_distance keywords.) The shading model (based on pigment, finish, and interior) doesn't account for effects like anisotropic reflection and subsurface scattering that occur in nature, and the idea that RGB (1.0, 1.0, 1.0) is "white" discourages the use of high-dynamic-range lighting.
Don't get me wrong, POV is a great piece of software for learning, and I wrote a few features for it in years past (variable reflection, metallic reflection, part of conserve_energy, and a blurred-reflection feature that doesn't seem to have made it into the current version). But trying to use it for serious production graphics is like using a Talking Whiz Kid as a word processor to write a Ph.D thesis.
http://www.eff.org/
I agree that a a centralized approach to configuration settings doesn't inherently need a daemon running in a separate process to manage the settings. However, it does enable GConf's notification mechanism I mentioned earlier. That notification mechanism is a really cool thing, because settings changes can take effect immediately across the whole desktop, in all running instances of a program, without needing to restart anything.
Dotfiles offer a flexibility that's useful in some specialized situations (like using several dotfiles to run several instances of a program with different settings), but they're more cumbersome to work with overall. If you're an experienced Unix hacker, hand-editing text files is fine, but for a desktop environment meant for general use, it's important to have programmatic interfaces to everything in the system -- preferences (via GConf), available hardware (take a look at Project Utopia), and so on.
However, at some point you want to be able to remove those ancient symbols that nobody uses anymore, so the binary doesn't keep getting bigger and bigger as new code is added but none is removed. This leaves distro builders with the task of having to decide where to draw the line between "old but supported" and "too old to be worth supporting", as the old symbols can't just be installed and uninstalled separately from the rest of the library. Maybe we'll start seeing packages like "libc6-backwardcompat" and "libc6-onlycurrent".
The advantage of that approach (used by both GConf and the Windows Registry) is that it's hierarchial and allows lots of data types (strings, numbers, Booleans, etc.) while still being structured enough to be not only read but also written to, in whole or in part, by software. It also enables additional features you wouldn't get (cleanly) with plain configuration files -- for example, in Windows, different registry keys can have different security settings, and with GConf, applications can "listen" on a key and be notified immediately when a change occurs, so that preferences changes can take effect immediately across the desktop.
Of course, XML is flexible enough to store an application's configuration settings in a hierarchial format with various data types, but dealing with it directly would require every application to incorporate parsing and writing functionality for their settings files. In the spirit of shared libraries, it's better to define an API for accessing settings, to reduce the amount of boilerplate functionality that must be implemented in every app. And since you don't want a million dotfiles in your home directory, you should keep the XML in a specific location too. But at this point you basically have GConf.
I use Gnome, and I much prefer GConf over INI-type files. What bothers me most is apps that store half their settings in GConf, and the other half in a dotfile in my home directory. :-)