5 ms·

"Entire gnome desktop"? WTF is that? Everybody is using a mix of Qt/GTK apps, and thanks to "just-for-gnome" turds like gconf nothing gets along and you have to

"Entire gnome desktop"? WTF is that? Everybody is using a mix of Qt/GTK apps, and thanks to "just-for-gnome" turds like gconf nothing gets along and you have to google and dance around several incompatible configuration GUIs. Pardon me, but "instant apply" feature is not enough to excuse for this mess: yeah, I change something in Gconf and maybe 20% of apps pick up my change instantly. A whopping 20%, but INSTANTLY, was that the goal? They should have ALL kept using standard /etc + ~/.xxrc files or came to an agreement to use something truly global, so I could enjoy the same font rendering or a freaking window colors in Skype and Pidgin. I can live without instant config changes but at least I could have grepped "color" and "window" appearing on the same line somewhere in /etc and in ~/.gtk or ~/.kde. Tools like GConf are destroying one of the greatest UNIX strengths: scriptability. I keep versions of config files for selected software under git and simply push it to /etc when I need to quickly set up a new machine. Nobody needs freaking "pluggable back-ends" because everybody needs to be able to instantly backup/restore selected applications configuration in a standard way And is it really worth it to run a freaking daemon so you can see your config changes instantly take effect? Also, your comment has "XML" in it. Are you sure? Seriously? Why not PDF? It's about as good as XML for storing key=value pairs, there are lots of tools developed for it too! And just as useles for sed/awk/grep. This disease of bloating up simple things into monstrosities based on "pluggable architectures" must be contagious: some infected gnome devs must have sat at the same table with GRUB-2 folks, so now we've lost a great bootloader.

FooBarWidget 17y ago
> Everybody is using a mix of Qt/GTK apps, and thanks to "just-for-gnome" turds like gconf nothing gets along and you have to google and dance around several incompatible configuration GUIs. So now we have, Gnome-specific config storage, KDE-specific config storage, and the rest all uses its own config storage. So now we have at least two classes of apps that use their own standard config storage. Getting rid of GConf would mean all of those apps would use their own config storage, creating even more fragmentation. That would be better, how? > Pardon me, but "instant apply" feature is not enough to excuse for this mess: yeah, I change something in Gconf and maybe 20% of apps pick up my change instantly. A whopping 20%, but INSTANTLY, was that the goal? No idea where you pulled the 20% number from. It's always 100% in my experience with the exception of Firefox and font settings. > They should have ALL kept using standard /etc /etc is not a standard. Did you ignore what everybody else has been saying? > + ~/.xxrc files Oh like ~/.gconf? > or came to an agreement to use something truly global, so I could enjoy the same font rendering or a freaking window colors in Skype and Pidgin. I can live without instant config changes but at least I could have grepped "color" and "window" appearing on the same line somewhere in /etc and in ~/.gtk or ~/.kde. Agreed, but this problem has got nothing to do with GConf. Getting rid of the GConf you so hate will not solve this very problem. > Tools like GConf are destroying one of the greatest UNIX strengths: scriptability. gconf-tool. Completely scriptable. Enjoy. > I keep versions of config files for selected software under git and simply push it to /etc when I need to quickly set up a new machine. Put ~/.gconf in git. Enjoy. > Nobody needs freaking "pluggable back-ends" because everybody needs to be able to instantly backup/restore selected applications configuration in a standard way Yeah, if only those stupid GConf files are backup-able with standard tools like 'cp' or 'tar'! Oh wait... they are! > And is it really worth it to run a freaking daemon so you can see your config changes instantly take effect? It is really worth requiring an entire windowing system and fancy graphics just so one can see images in a web browser? We should just stick with telnet dammit! Yes. Why not run a daemon? It eats maybe a few hundred KB of private RSS. Even an old desktop system by today's standard has 256 MB of RAM. The daemon also improves startup performance by caching a small set of active configuration settings in memory instead of having to constantly load them from disk, something which is not possible if every app parses the config files. > Why not PDF? Why PDF? I'll tell you why not PDF, because it's not a good format for storing config, what's why! You said there are lots of tools for editing PDF - but none of them are usable for editing key-value pairs. As opposed to XML tools. If the XML file hard to read? Use xmllint to reformat or to indent it. Edit with a standard text editor. grep, sed, awk, all work, I have no idea what you're talking about. No, I think your fear for 2010 technology and your tendency to stick with 1970s stuff is more of a disease.
- old-gregg 17y ago
  So now we have, Gnome-specific config storage, KDE-specific config storage, and the rest all uses its own config storage. No. If Gnome-specific and KDE-specific config did not exist, we all would have standard ini-style config files sitting in /etc (for system/root) and in ~/.gnome and ~/.kde respectively with each program owning a file named after itself. Also, the biggest problem with windows registry isn't its internal structure: users don't care about that. The issue with registry is that it grows over time and never shrinks due to buggy and forgotten programs that leave junk in there. That's #1 reason why people complain about their computers getting slower. GConf happily inherits this fatal flaw because find ~/.gconf/ -name "program" won't find anything. Again: gconf-tool is an example of a non-standard little turd that I was referring to when expressed my annoyance with managing multiple configuration systems. And how is placing ~/.gconf under git helps me to quickly restore configuration for selected apps? Have you looked inside of .gconf? Have you seen wifi.conf file in there? Those who have would no doubt pick /etc. One more time: gconf is not find/awk/grep/sed friendly, hence it is a maintenance nightmare. Yes. Why not run a daemon? It eats maybe a few hundred KB of private RSS. How typical for a 2010 technologist: "I want this little tiny toy feature which will eat only a few insignificant hundred KB...". You know what? Users have hundreds of little tiny little needs that would enjoy running all time time. I can keep naming things forever that a computer is capable of doing, and if you multiply those hundreds by your "few hundred KB" very quickly you'll end up with something like Vista: functional yet barely capable of running itself. Moreover, are you sure gconfd eats hundreds of K? Care to look again? Sending configuration change notifications is NOT a significant feature to have its own daemon. Even Windows is smart enough to run a single svchost.exe service that groups tens of little background features like that into a single process. No, I think your fear for 2010 technology and your tendency to stick with 1970s stuff is more of a disease. The industry seems to be voting my way: it is simple 1970s pieces of Linux tech that dominate competition, yes - those that read their config from ini files in /etc. And your 2010 "pluggable technology" is still waiting for a year of Linux desktop.
  - viraptor 17y ago
    > And how is placing ~/.gconf under git helps me to quickly restore configuration for selected apps? Have you looked inside of .gconf? Yes - it contains the hierarchy mapped to directories. In my case `.gconf` contains directories `apps`, `desktop`, `system`. Then `apps` contains a subdirectory for every application using gconf - for example `ekiga`. You can revert the chosen directory there to revert the version for a single application. I honestly don't know what problems are you seeing. > Have you seen wifi.conf file in there? No, I don't have it. All my configs are stored in respective app's directory in a `%gconf.xml` file. Are you sure that wifi.conf is managed by gconf? Maybe it's just some random file that was put there by a broken app?

FooBarWidget 17y ago

> Everybody is using a mix of Qt/GTK apps, and thanks to "just-for-gnome" turds like gconf nothing gets along and you have to google and dance around several incompatible configuration GUIs. So now we have, Gnome-specific config storage, KDE-specific config storage, and the rest all uses its own config storage. So now we have at least two classes of apps that use their own standard config storage. Getting rid of GConf would mean all of those apps would use their own config storage, creating even more fragmentation. That would be better, how? > Pardon me, but "instant apply" feature is not enough to excuse for this mess: yeah, I change something in Gconf and maybe 20% of apps pick up my change instantly. A whopping 20%, but INSTANTLY, was that the goal? No idea where you pulled the 20% number from. It's always 100% in my experience with the exception of Firefox and font settings. > They should have ALL kept using standard /etc /etc is not a standard. Did you ignore what everybody else has been saying? > + ~/.xxrc files Oh like ~/.gconf? > or came to an agreement to use something truly global, so I could enjoy the same font rendering or a freaking window colors in Skype and Pidgin. I can live without instant config changes but at least I could have grepped "color" and "window" appearing on the same line somewhere in /etc and in ~/.gtk or ~/.kde. Agreed, but this problem has got nothing to do with GConf. Getting rid of the GConf you so hate will not solve this very problem. > Tools like GConf are destroying one of the greatest UNIX strengths: scriptability. gconf-tool. Completely scriptable. Enjoy. > I keep versions of config files for selected software under git and simply push it to /etc when I need to quickly set up a new machine. Put ~/.gconf in git. Enjoy. > Nobody needs freaking "pluggable back-ends" because everybody needs to be able to instantly backup/restore selected applications configuration in a standard way Yeah, if only those stupid GConf files are backup-able with standard tools like 'cp' or 'tar'! Oh wait... they are! > And is it really worth it to run a freaking daemon so you can see your config changes instantly take effect? It is really worth requiring an entire windowing system and fancy graphics just so one can see images in a web browser? We should just stick with telnet dammit! Yes. Why not run a daemon? It eats maybe a few hundred KB of private RSS. Even an old desktop system by today's standard has 256 MB of RAM. The daemon also improves startup performance by caching a small set of active configuration settings in memory instead of having to constantly load them from disk, something which is not possible if every app parses the config files. > Why not PDF? Why PDF? I'll tell you why not PDF, because it's not a good format for storing config, what's why! You said there are lots of tools for editing PDF - but none of them are usable for editing key-value pairs. As opposed to XML tools. If the XML file hard to read? Use xmllint to reformat or to indent it. Edit with a standard text editor. grep, sed, awk, all work, I have no idea what you're talking about. No, I think your fear for 2010 technology and your tendency to stick with 1970s stuff is more of a disease.

old-gregg 17y ago
So now we have, Gnome-specific config storage, KDE-specific config storage, and the rest all uses its own config storage. No. If Gnome-specific and KDE-specific config did not exist, we all would have standard ini-style config files sitting in /etc (for system/root) and in ~/.gnome and ~/.kde respectively with each program owning a file named after itself. Also, the biggest problem with windows registry isn't its internal structure: users don't care about that. The issue with registry is that it grows over time and never shrinks due to buggy and forgotten programs that leave junk in there. That's #1 reason why people complain about their computers getting slower. GConf happily inherits this fatal flaw because find ~/.gconf/ -name "program" won't find anything. Again: gconf-tool is an example of a non-standard little turd that I was referring to when expressed my annoyance with managing multiple configuration systems. And how is placing ~/.gconf under git helps me to quickly restore configuration for selected apps? Have you looked inside of .gconf? Have you seen wifi.conf file in there? Those who have would no doubt pick /etc. One more time: gconf is not find/awk/grep/sed friendly, hence it is a maintenance nightmare. Yes. Why not run a daemon? It eats maybe a few hundred KB of private RSS. How typical for a 2010 technologist: "I want this little tiny toy feature which will eat only a few insignificant hundred KB...". You know what? Users have hundreds of little tiny little needs that would enjoy running all time time. I can keep naming things forever that a computer is capable of doing, and if you multiply those hundreds by your "few hundred KB" very quickly you'll end up with something like Vista: functional yet barely capable of running itself. Moreover, are you sure gconfd eats hundreds of K? Care to look again? Sending configuration change notifications is NOT a significant feature to have its own daemon. Even Windows is smart enough to run a single svchost.exe service that groups tens of little background features like that into a single process. No, I think your fear for 2010 technology and your tendency to stick with 1970s stuff is more of a disease. The industry seems to be voting my way: it is simple 1970s pieces of Linux tech that dominate competition, yes - those that read their config from ini files in /etc. And your 2010 "pluggable technology" is still waiting for a year of Linux desktop.
- viraptor 17y ago
  > And how is placing ~/.gconf under git helps me to quickly restore configuration for selected apps? Have you looked inside of .gconf? Yes - it contains the hierarchy mapped to directories. In my case `.gconf` contains directories `apps`, `desktop`, `system`. Then `apps` contains a subdirectory for every application using gconf - for example `ekiga`. You can revert the chosen directory there to revert the version for a single application. I honestly don't know what problems are you seeing. > Have you seen wifi.conf file in there? No, I don't have it. All my configs are stored in respective app's directory in a `%gconf.xml` file. Are you sure that wifi.conf is managed by gconf? Maybe it's just some random file that was put there by a broken app?