Weekly Edition
Return to the Distributions page
| |||||||||||||||||||
|
| |||||||||||||||||||
Ubuntu 10.10 Beta (Maverick Meerkat) Released
The Ubuntu team is pleased to announce the release of Ubuntu 10.10 beta. Codenamed "Maverick Meerkat", 10.10 continues Ubuntu's proud tradition of integrating the latest and greatest open source technologies into a high-quality, easy-to-use Linux distribution. Ubuntu 10.10 Desktop Edition and Ubuntu 10.10 Netbook Edition continue the trend of ever-faster boot speeds, with improved startup times and a smoother, streamlined boot experience. Ubuntu 10.10 Server Edition provides even better integration of the Ubuntu Enterprise Cloud, with its install-time cloud setup. Ubuntu 10.10 Server for UEC and EC2 brings the power and stability of the Ubuntu Server Edition to cloud computing, whether you're using Amazon EC2 or your own Ubuntu Enterprise Cloud. The Ubuntu 10.10 family of Kubuntu, Xubuntu, Edubuntu, Ubuntu Studio, and Mythbuntu, also reach beta status today. Ubuntu Desktop features ---------------- The GNOME base platform has been updated to the current 2.31 versions. This includes the new dconf and gsettings API. Evolution was updated to the 2.30.2 version, which operates much faster than the version in Ubuntu 10.04 LTS. Shotwell has replaced F-Spot as the default photo manager. Gwibber has been updated to support the recent change in Twitter's authentication system, as well as changing the back end storage to improve performance. The Sound Indicator has been enhanced to include music player controls. The Ubuntu Software Center has an updated look and feel, including the new "Featured" and "What's New" views for showcasing applications, and an improved package description view. You can now easily access your package installation history too. New Design: The boot process is cleaner and faster. New themes, new icons, and new wallpaper bring a dramatically updated look and feel to Ubuntu. Ubuntu One: Polished desktop integration with new sign up and sign in process. Tighter integration with Ubuntu SSO. Nautilus enhancements for managing folder sync preferences. Faster file sync speed. Share links to music within the Ubuntu One Music Store. Please see http://www.ubuntu.com/testing/maverick/beta for details. Ubuntu Server features --------------- Cloud computing: The configurable initialization process for Ubuntu Server cloud images (cloud-init) has gained new features in Maverick Beta, including pluggable hooks, ebsmount, ext4 support, and new stanzas in the cloud-config format. Cloud image instances can now manage their own kernel and upgrade kernels with apt. This is done by using pv-grub, provided by Amazon. Ubuntu Netbook features ----------------------- The new Unity interface is now the default in Ubuntu Netbook Edition. It includes the global menu bar. The date/time indicator now has a real calendar widget. The standard photo management application has been switched to Shotwell. Kubuntu features ---------------- For Maverick, Kubuntu have merged the Desktop and Netbook images into one. Ubiquity, Kubuntu's installer, will detect the screen size before the install and use either the Plasma Desktop workplace or the Plasma Netbook workplace as needed. Users will be able to switch between the two in System Settings. Plasma Netbook now sports the Global Menu by default. The standard web browser is now Rekonq, a KDE browser based on Qt Webkit. Bluedevil has become the default bluetooth stack. Pulseaudio is the default sound server. KPackageKit updates bring a faster backend and an updated UI that provides a new Categories page, and new features such as a backup/restore tool for the list of installed packages. Kubuntu's installer (Ubiquity) now has updated look and layout. Qapt-batch now replaces install-package as the update/batch-installer utility KDE Platform, Workspaces, and Applications were updated to 4.5.0 (the recently released 4.5.1 update could not be integrated before beta release and will arrive shortly). Qt was updated to the current 4.7 beta release. See https://wiki.kubuntu.org/MaverickMeerkat/Beta/Kubuntu for more details. Xubuntu features ---------------- Xfce4 was updated to the current 4.6.2 release. New default applications include: Parole (Xfce4 Media Player), replacing Totem Movie Player; Xfburn (Xfce4 CD/DVD burning tool), replacing Brasero; and xfce4-taskmanager (Xfce4 process manager), replacing Gnome-Task-Manager. Edubuntu features ----------------- Edubuntu now includes Gnome Nanny, which provides parental controls in Edubuntu. There is new wallpaper included (periodic table breakout). In addition, an OEM Install mode is now available. For those interested in learning more, there's a new web site as well. Check out http://www.edubuntu.org. Ubuntu Studio features ---------------------- In this release, Ubuntu Studio has better integration between Pulse Audio and JACK. JACK and Pulse Audio can now be used side-by-side if they are using different audio interfaces. If they are trying to use the same audio interface, JACK will take precedent. The network connections can now be configured with gnome-network-admin. Mythbuntu features ------------------ In this release, Mythbuntu has updated to MythTV 0.23.1. There is also a new backup and restore tool. Other ----- * On the Desktop: GNOME 2.31, KDE 4.5.0b, Xfce 4.6.2, OpenOffice.org 3.2.1, X.org server 7.5 * On the Server: Apache 2.2.16, PostgreSQL 8.4.4, PHP 5.3.3, LTSP 5.2.4 * "Under the hood": Linux 2.6.35.3, GCC 4.4.4 (default) / 4.5.1 (optional), eglibc 2.12.1, Python 2.6.6 (default) / 3.1.2 (optional) The full release notes can be found at http://www.ubuntu.com/testing/maverick/beta About Ubuntu ------------ Ubuntu is a full-featured Linux distribution for desktops, laptops, and servers, with a fast and easy installation and regular releases. A tightly-integrated selection of excellent applications is included, and an incredible variety of add-on software is just a few clicks away. Professional technical support is available from Canonical Limited and hundreds of other companies around the world. For more information about support, visit http://www.ubuntu.com/support To Get Ubuntu 10.10 Beta ------------------------ To upgrade to Ubuntu 10.10 Beta from Ubuntu 10.04 LTS, follow these instructions: https://help.ubuntu.com/community/MaverickUpgrades Or, download Ubuntu 10.10 Beta; The following link will direct you to a download location near you: http://www.ubuntu.com/testing/download Or, choose the mirror closest to you: Africa: * http://ubuntu.mirror.ac.za/ubuntu-release/10.10 (South Africa) * http://ubuntu.saix.net/ubuntu-releases/10.10 (South Africa) Asia: * http://mirrors.sohu.com/ubuntu-releases/10.10 (China) * http://ftp.riken.jp/Linux/ubuntu-iso/CDs/10.10 (Japan) * http://ubuntutym2.u-toyama.ac.jp/ubuntu/10.10 (Japan) * http://ftp.kaist.ac.kr/ubuntu-cd/10.10 (Korea, Republic of) * http://ubuntu.qualitynet.net/releases/10.10 (Kuwait) * http://mirror.yandex.ru/ubuntu-releases/10.10 (Russian Federation) * http://tw.releases.ubuntu.com/10.10 (Taiwan) * http://ftp.linux.org.tr/ubuntu-releases/10.10 (Turkey) Europe: * http://ubuntu.lagis.at/releases/10.10 (Austria) * http://ftp.mgts.by/pub/ubuntu-releases/10.10 (Belarus) * http://ubuntu.ipacct.com/releases/10.10 (Bulgaria) * http://hr.releases.ubuntu.com/10.10 (Croatia) * http://releases.ubuntu.cz/releases/10.10 (Czech Republic) * http://mirrors.dotsrc.org/ubuntu-cd/10.10 (Denmark) * http://ftp.estpak.ee/pub/ubuntu-releases/10.10 (Estonia) * http://ubuntu.trumpetti.atm.tut.fi/releases/10.10 (Finland) * http://ubuntu.mirrors.proxad.net/10.10 (France) * http://ubuntu.mirror.tudos.de/ubuntu-releases/10.10 (Germany) * http://gb.releases.ubuntu.com/10.10 (Great Britain) * http://mirror.greennet.gl/releases/10.10 (Greenland) * http://speglar.simnet.is/ubuntu-releases/10.10 (Iceland) * http://ftp.heanet.ie/pub/ubuntu-releases/10.10 (Ireland) * http://na.mirror.garr.it/mirrors/ubuntu-releases/10.10 (Italy) * http://ubuntu.mirror.root.lu/ubuntu-releases/10.04 (Luxembourg) * http://nl.releases.ubuntu.com/releases/10.10 (Netherlands) * http://no.releases.ubuntu.com/10.10 (Norway) * http://ubuntu.task.gda.pl/ubuntu-releases/10.10 (Poland) * http://cesium.di.uminho.pt/pub/ubuntu/10.10 (Portugal) * http://ftp.astral.ro/mirrors/ubuntu.com/releases/10.10 (Romania) * http://rs.releases.ubuntu.com/10.10 (Serbia) * http://ubuntu.cica.es/releases/10.10 (Spain) * http://se.releases.ubuntu.com/10.10 (Sweden) * http://mirror.switch.ch/ftp/mirror/ubuntu-cdimage/10.00 (Switzerland) North America: * http://mirror.csclub.uwaterloo.ca/ubuntu-releases/10.10 (Canada) * http://mirror.anl.gov/pub/ubuntu-iso/CDs/10.10 (United States) * http://mirrors.us.kernel.org/ubuntu-releases/10.00 (United States) * http://ubuntu.osuosl.org/releases/10.10 (United States) Oceania/Australia: * http://mirror.aarnet.edu.au/pub/ubuntu/releases/10.10 (Australia) * http://mirror.linux.org.au/ubuntu-releases/10.10 (Australia) * http://releases.ubuntu.nautile.nc/10.10 (New Caledonia) * http://ftp.citylink.co.nz/ubuntu-releases/10.10 (New Zealand) South America: * http://mirror.pop-sc.rnp.br/mirror/ubuntu/10.10 (Brazil) * http://ubuntu.c3sl.ufpr.br/releases/10.10 (Brazil) Please download using Bittorrent if possible. The final version of Ubuntu 10.10 is expected to be released in October 2010. Feedback and Participation -------------------------- If you would like to help shape Ubuntu, take a look at the list of ways you can participate at http://www.ubuntu.com/community/participate/ Your comments, bug reports, patches and suggestions will help turn this Beta into the best release of Ubuntu ever. Please note that, where possible, we prefer that bugs be reported using the tools provided, rather than by visiting Launchpad directly. Instructions can be found at https://help.ubuntu.com/community/ReportingBugs If you have a question, or if you think you may have found a bug but are not sure, first try asking on the #ubuntu IRC channel on freenode, on the Ubuntu Users mailing list, or on the Ubuntu forums: http://lists.ubuntu.com/mailman/listinfo/ubuntu-users http://www.ubuntuforums.org/ More Information ---------------- You can find out more about Ubuntu and about this preview release on our website, IRC channel and wiki. If you are new to Ubuntu, please visit: http://www.ubuntu.com/ To sign up for future Ubuntu announcements, please subscribe to Ubuntu's very low volume announcement list at: http://lists.ubuntu.com/mailman/listinfo/ubuntu-announce -- Robbie Williamson robbie@ubuntu.com Ubuntu robbiew[irc.freenode.net] "You can't be lucky all the time, but you can be smart everyday" -Mos Def "Arrogance is thinking you are better than everyone else, while Confidence is knowing no one else is better than you." -Me ;) -- ubuntu-announce mailing list ubuntu-announce@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-announce (Log in to post comments)
Ubuntu 10.10 Beta (Maverick Meerkat) Released Posted Sep 3, 2010 23:38 UTC (Fri) by sdalley (subscriber, #18550) [Link] Am I the only one who looked at this announcement, saw "new dconf and gsettings API", thought "I wonder WOE that is?" googled to find out, only to discover a crummy gnome webpage with not a word about what the API actually is?(Oh, sorry, it's there in the tarball. Sort of, at a low level, with the who, why and when questions left unanswered.) It *looks* like Gnome's answer to the Windows Registry, and all our nice unix-like plain text config files are now summarily consigned to the dustbin of history, but one can't be sure. Does anyone know anything about this apparently momentous alteration to our plumbing? Specifically: dconv(1) actually has a decent manpage, except that's not for gnome dconf but another older dconf. (Its arguments are especially well documented!) Somebody obviously forgot to search the namespace before christening their shiny new toy. Impressed. (not)
Ubuntu 10.10 Beta (Maverick Meerkat) Released Posted Sep 3, 2010 23:56 UTC (Fri) by RainCT (subscriber, #57473) [Link]
It's a replacement for GConf.
Ubuntu 10.10 Beta (Maverick Meerkat) Released Posted Sep 4, 2010 0:31 UTC (Sat) by MisterIO (subscriber, #36192) [Link]
The only reason I've found(from past posts) for this change is performances. Is there any use case where the config file is changed(or even just read) so frequently that it actually impacts performances in a visible way?
Ubuntu 10.10 Beta (Maverick Meerkat) Released Posted Sep 4, 2010 0:43 UTC (Sat) by khc (subscriber, #45209) [Link]
iirc it's startup performance (when desktop starts, 10s of applications ask "What my settings are?")
Ubuntu 10.10 Beta (Maverick Meerkat) Released Posted Sep 4, 2010 0:47 UTC (Sat) by MisterIO (subscriber, #36192) [Link]
If it's only that, then I definitely disagree with this change.
Ubuntu 10.10 Beta (Maverick Meerkat) Released Posted Sep 4, 2010 1:48 UTC (Sat) by drag (subscriber, #31333) [Link]
Well I guess we all are very lucky it's not your decision to make. :)
There are quite a few shortcomings to gconf that this will help to deal with (hopefully) and poor performance is just one of them.
Ubuntu 10.10 Beta (Maverick Meerkat) Released Posted Sep 4, 2010 13:24 UTC (Sat) by MisterIO (subscriber, #36192) [Link]
Well, I certainly hope you're right, since this is the direction already taken anyway.
Ubuntu 10.10 Beta (Maverick Meerkat) Released Posted Sep 4, 2010 18:44 UTC (Sat) by drag (subscriber, #31333) [Link]
Sorry about the last post. I was in a bad mood.
Really the #1 benefit from dconf is that it's standardized. Previous configuration methods tended to be specific to languages or environments.
So if your dealing with KDE or Gnome or whatever you were always dealing with different configuration APIs, methods, and backends. Sometimes you'd deal with xml files and directory system with Gconf or you'd deal with *.ini systems people brought in through their windows experience, .*rc files, and all sorts of other various methods people invented up to solve their specific problem.
So the benefits from dconf, besides attempts to make it a better configuration backend from others, stems from being a standard.
So for example people have been trying to figure out a way to load configuration for hardware and software into a LDAP system. So the challenge was to find a way to bridge the configuration stored on LDAP with all the different configuration methods that you may run into. Thus because this is such a difficult barrier then it's remained elusive.
If people used dconf instead then all you need is one bridge to load and store configurations.
Gnome is switching over to it, of course. From a application's point of view if they used gsettings for everything then they shouldn't see any real difference (other then performance improvements), baring any bugs.
But dconf itself, I expect, does not have any Gnome-specific dependencies and thus can be used for all sorts of purposes.
One example would be a way to manage configuration for nodes in a cluster.
--------------------------------------
As far as windows registry goes and binary formats and whatnot.
The idea of using a binary database with a nice interface to store configurations is certainly a valid idea and is already used by a massive number of different applications. Having a standard interface to edit/save/load configurations and be properly optimized for configuration purposes should be a improvement over what is generally used now.
Hopefully. I don't know the technical details.
It's just that the Windows registry's execution left a lot to be desired...
Ubuntu 10.10 Beta (Maverick Meerkat) Released Posted Sep 4, 2010 20:42 UTC (Sat) by MisterIO (subscriber, #36192) [Link]
No problem.
About your explanation, it all makes sense. My only concern is the use of a binary format. I don't see why they couldn't standardize a textual config file format. The main point is that usually a textual config file is easier to understand and change, it's more resilient to corruption and easier to recover(from corruption or wrong settings).
Ubuntu 10.10 Beta (Maverick Meerkat) Released Posted Sep 4, 2010 22:47 UTC (Sat) by obi (subscriber, #5784) [Link]
Well, the API glib-based apps should be using is GSettings, and IIRC you can choose a different GSettingsBackend by using an environment variable. I think there is even a .ini-style pure text keyfile-based GSettingsBackend. Even if it's not fully functional, people who'd like something like this should be able to fix it up.
I trust the dconf guys to know why they're going with a binary format though. I suspect it's hard to do thousands of simultaneous reads and change notifications efficiently with (multiple) plain text files.
I would however like to see a fuse <-> gsettings bridge so it's easy to replicate/merge settings from different machines, and a bitter migration story (between gconf and dconf, between different gsettings backends, etc).
Ubuntu 10.10 Beta (Maverick Meerkat) Released Posted Sep 4, 2010 23:00 UTC (Sat) by foom (subscriber, #14868) [Link]
Yeah, I'm *so* looking forward to Gnome destroying the binary database containing the configuration for every app on the system when I happen to login on two machines at the same time sharing a network homedir.
Ubuntu 10.10 Beta (Maverick Meerkat) Released Posted Sep 5, 2010 0:57 UTC (Sun) by nix (subscriber, #2304) [Link]
Like that could ever happen. Like gconf, gsettings would surely never dream of doing any such thing. (It would drop a random lockfile and refuse to start instead. ;} )
Ubuntu 10.10 Beta (Maverick Meerkat) Released Posted Sep 5, 2010 1:48 UTC (Sun) by drag (subscriber, #31333) [Link]
Hrm. With dconf applications do not write directly to the database. They use dbus service.
My understanding is that writes to the configuration system are expensive like this so it can handle the locking and all that crap. Reads, on the other hand, are as cheap as hell.
And as far as the ease of corruption and recovery of binary data... that really depends on the format, right?
Why Are Binary Config Formats A Bad Idea? Posted Sep 6, 2010 5:01 UTC (Mon) by ldo (subscriber, #40946) [Link] So many reasons.
Maybe these sorts of things are less important with personal GUI apps than with stuff that needs systemwide config. I certainly wouldnt want to see systemwide services moving to binary config formats.
Ubuntu 10.10 Beta (Maverick Meerkat) Released Posted Sep 7, 2010 12:52 UTC (Tue) by sorpigal (subscriber, #36106) [Link]
"It's just that the Windows registry's execution left a lot to be desired..."
The value of the windows registry is that it provided programs with a standard, correct and (somewhat) simple API for storing and retrieving settings. This was and remains superior to each application inventing a brand-new mechanism, but is not necessarily superior to an application using a mechanism more specifically suited to the application.
The windows registry as a concept for replacing half-assed and poorly written application-specific configuration systems is a good idea. Anything that means I don't have to write another config file parser is a good thing, to me! Anything that makes providing more options easy, by making it easy and cheap to have something depend on a setting, is also good for me.
DConf by itself is not a bad idea; it's a good concept. The fact that the developers are in love with a binary back end is a huge problem. The correct default back end for a system like this should be the filesystem, much in the manner of libelektra. Anything binary is bad.
One thing that worries me when GNOME does something like this is that the tendency is to take a good idea and run so far with it that you pass the point of insanity. Consider Firefox: It's not a good idea to put all of Firefox's sqlite stuff in to dconf instead, nor even user.js. Even on Windows with the registry available Firefox doesn't do this. I expect, however, that we will find GNOME pushing for applications to store $everything via dconf with the motto of "If you can, you should."
Ubuntu 10.10 Beta (Maverick Meerkat) Released Posted Sep 4, 2010 18:28 UTC (Sat) by sdalley (subscriber, #18550) [Link]
Thank you for that clarification. It allowed me to find some useful information.
Strictly speaking, *gsettings* is the replacement for gconf, with a New Improved interface. dconf is a new faster key-value storage back-end which the application programmer should never have to deal with directly.
Sketchy developer documentation does indeed exist on mailing lists, and there's some stuff for admins too on http://library.gnome.org/devel/gio/unstable/ch27.html
A review of dconf. Posted Sep 5, 2010 18:49 UTC (Sun) by gmatht (subscriber, #58961) [Link]
There is also a review of dconf that I thought was interesting.
http://aseigo.blogspot.com/2005/04/stupidity-of-dconf.html I don't know enough about dconf to comment of the review though.
A review of dconf. Posted Sep 5, 2010 20:03 UTC (Sun) by Los__D (subscriber, #15263) [Link]
Errrrr... Review? It's mostly Aaron worrying about if DConf would be good, before it was even really planned (back in 2005).
A review of dconf. Posted Sep 5, 2010 22:08 UTC (Sun) by drag (subscriber, #31333) [Link]
Yep. It has to more to do with him ranting about the negative aspects of freedesktop.org as a organization from 6 years ago then anything to do with dconf.
People just are not doing a good job of documenting and promoting dconf as if it actually works as intended it should be hugely attractive to a lot more then just desktop Gnome folks and applications that happen to use gsettings.
A review of dconf. Posted Sep 6, 2010 9:20 UTC (Mon) by cmccabe (subscriber, #60281) [Link]
If you want to use the same configuration on multiple machines, how about NFS-mounting your home directory? Or if you're scared of NFS-mounting a home directory, create symlinks from your home directory to some directory that is NFS-mounted on each machine.
If you're really so concerned about reloading configuration when a config file changes, why not do an inotify() on the configuration file?
If you want all Gnome / KDE / SuperBloatGUI apps to use a single configuration API, why not create a library that just reads configuration files and parses them? For bonus points, include a version number in the text file so that you can extend the format over time.
Why do people insist on over-complicating things? You shouldn't need daemons, d-bus, custom binary formats, shared memory, and cross-process synchronization just to load some simple GUI configuration information. Truly, this is not the way of the ninja.
A review of dconf. Posted Sep 6, 2010 14:13 UTC (Mon) by nix (subscriber, #2304) [Link] If you're really so concerned about reloading configuration when a config file changes, why not do an inotify() on the configuration file?That doesn't work over NFS, does it? (As an aside, does anyone know of a non-cluster networked FS that is more POSIXish than NFS? Pohmelfs looked suitable for a while, but it seems to have gone moribund, and Evgeniy seems to want to layer it on top of the elliptics key/value store rather than letting it export an existing filesystem, as now, so it doesn't look like a good replacement in the long term, alas.)
A review of dconf. Posted Sep 6, 2010 19:27 UTC (Mon) by cmccabe (subscriber, #60281) [Link]
Well, the Ceph developers are trying to get strict POSIX semantics. Of course, it's a clustered filesystem, and you asked for non-clustered.
RFS was an ancient remote filesystem that had POSIX semantics and was non-clustered. In fact, I think its name simply meant "remote file system." It seems like it died long ago. Supposedly it was because NFS was a more open standard, and NFS was faster because of its relaxed semantics.
OpenAFS is a remote filesystem that does support inotify. It is used at MIT and Carnegie Mellon, and probably some other places. AFS has open-to-close semantics, kind of similar to NFS. AFS does a lot of client-side caching, and unlike NFSv2 and NFSv3, it makes no pretense of being stateless.
A review of dconf. Posted Sep 6, 2010 20:38 UTC (Mon) by nix (subscriber, #2304) [Link]
"Non-clustered" was perhaps a crude description of what I'm really looking for. I'd like to retain the property of NFS that you can rapidly switch a local filesystem to a remote one (or into one exported to remote machines): you don't need to copy everything to a new filesystem and unmount the old one, you can access it locally too... IMNSHO that property is pretty much crucial for most non-huge-scale networked filesystems to take off to any real degree.
Clustered filesystems tend to be monsters that always have their own low-level filesystem (so you can't promote a local filesystem into a remotely-accessible one easily), and tend to assume shared block devices and stuff like that, often over some sort of expensive enterprise fabric: hello, my LAN only has six machines on it, I don't have InfiniBand, but I'd like each of those machines to be able to get high performance and close-to-POSIX semantics out of the filesystem on the other end, unlike NFS. And to be honest six or sixty makes few odds here: SANs only become practical when you're talking hundreds. And there are a lot of people with fewer than hundreds of Linux boxes, but more than one, who want to share filesystems between them...
A review of dconf. Posted Sep 6, 2010 16:29 UTC (Mon) by drag (subscriber, #31333) [Link]
> If you want to use the same configuration on multiple machines, how about NFS-mounting your home directory? Or if you're scared of NFS-mounting a home directory, create symlinks from your home directory to some directory that is NFS-mounted on each machine.
So your telling me that NFS is a serious alternative to LDAP and other directory protocols?
If you think this through as to why on one hand it would be acceptable for organizations to use LDAP and Active Directory to manage user, group policies (not just UID/GID), hardware driver, and so on configurations rather then just mounting /etc/ on NFS then it's pretty obvious why what your saying is not a acceptable solution.
It's not just desktop that I need to be able to manage...
> If you're really so concerned about reloading configuration when a config file changes, why not do an inotify() on the configuration file?
Yeah. That is a possible solution, but it probably is not the most ideal one.
For example:
How are you going to deal with a situation were you have multiple possible configuration inputs on a system?
With the solution outlined above you have a huge number of possible race conditions to deal with... Most obvious: "A" reads the configurations, "B" reads the configuration, "B" writes out configurations, "A" writes out configurations, and then "A" gets notifications from the kernel that "B" has made changes.
This is why we need to use things like 'visudo' to make changes to sudeors files.
> If you want all Gnome / KDE / SuperBloatGUI apps to use a single configuration API, why not create a library that just reads configuration files and parses them? For bonus points, include a version number in the text file so that you can extend the format over time.
That's what they do now.
Prior to dconf, gconf used a directory system based on directories and XML files containing keypairs.
$ find .gconf -type f |wc
Right now you cannot edit the files directly to make changes to configurations, unfortunately. The configuration for the system is handled by "gnome-settings-daemon" which reads the configurations at start up and makes sure to flush all the configurations out at shutdown.
----------------------------------
The primary problem here for people here is going to be that dconf uses a binary format.
I understand this and I know that text formats have a huge number of advantages based on the fact that, ultimately, ASCI/UTF-8 is a well defined binary format with lots of parsers and editors that are easy to use and understand.
The problem is that ASCII/UTF-8 do not define their format enough to make it a solution for storing configurations. If you want something that as a configuration file is relatively easy to program for you need further definitions like the *.ini format or something like XML.
At this point, however, we have reached the point were your running into severe performance limitations with disk I/O, memory usage, and you still have not defined things enough to establish a way to avoid race conditions.... figure out IPC, notification system, locking mechanisms, and so on and so forth.
This is were it all breaks down. There are a hundred possible different solutions for dealing with text-based formats and there are thousands which seem to work well enough for most people. And all of them are being used, currently, on my Linux desktop.
All sorts of different levels of abstractions, libraries, editors and all that stuff. It literally takes years to know enough to be able to handle configuration methods and formats on the Linux desktop and even then you have to constantly refer to documentation. Programming something that can handle all of this is a nightmare and nobody has yet figured out a way to do it.
--------------------------------
Binary formats CAN be robust, have revision, be easy to edit and easy to program for. It just depends on the details. After all ASCII/UTF-8 itself is just a binary formation when you look at it from a system perspective.
And this is the huge thing we lack right now:
Details on Dconf.
Lack of information breads problems and if developers want Dconf to be a acceptable solution they are going to have to be more forth coming as to the technical details as to WHY dconf will work and how it works.
Without further adoption by other projects it's just going to be one more method in a sea of methods.
A review of dconf. Posted Sep 6, 2010 19:56 UTC (Mon) by cmccabe (subscriber, #60281) [Link]
My initial comment was a little bit of a rant. When I take a closer look at dconf, it does look better than what came before. It will also be nice to have KDE and Gnome using the same mechanism.
It's just that... One of the core philosophies of UNIX is "everything is a file." I think people have forgotten about that in the mad rush to build something that rivals Windows.
I personally used a system where my home directory was mounted on AFS at Carnegie Mellon University. Whenever I made changes to a config file, I could log into another system and see those changes reflected. There were no userspace daemons and d-bus had not been created yet. I know that this can be done without registries or binary formats. It was done in the 80s with hardware that we wouldn't put inside a toaster oven these days.
I don't agree with your comments on binary versus text configuration files. The hard thing about configuration files isn't really figuring out the syntax. It's figuring out the semantics. What does each option really do? Switching to a registry doesn't help with that. Just try opening up regedit.exe on Windows. Do you find those settings easier to understand than what lives in /etc?
Your comment about replacing LDAP with a remotely-mounted /etc directory is interesting. It's what Plan9 would have done. It's a shame that NFS doesn't support inotify.
A review of dconf. Posted Sep 6, 2010 20:47 UTC (Mon) by nix (subscriber, #2304) [Link] The problem is that ASCII/UTF-8 do not define their format enough to make it a solution for storing configurations. If you want something that as a configuration file is relatively easy to program for you need further definitions like the *.ini format or something like XML. At this point, however, we have reached the point were your running into severe performance limitations with disk I/O, memory usage, and you still have not defined things enough to establish a way to avoid race conditions.... figure out IPC, notification system, locking mechanisms, and so on and so forth.Why do people keep saying this? It's absolute rubbish: or rather, it could be a problem, but KDE *2* fixed this. What you do is you have readable, textual configuration files, as expensive to parse as you like: then you have a daemon which takes out inotify watches on your configuration file directories and parses them all into a compact binary cache format in a well-known location. Then everyone just mmap()s that cache file and gets their high-speed binary goodness. If the config files change, the daemon spots it and rebuilds the cache. More elaborate configurations could have the daemon hand out FDs to the cache file via a Unix-domain socket in a well-known location: this allows easy extension into a protocol whereby the daemon tells the clients when configurations change, and so on. Clients still need to know how to write their configuration file (if it's client-generated, not human-written), but don't need to know how to parse it. (It would even be possible for clients to contribute a shared object that allows their particular readable config file to be a different format to the others, yet still benefit from the binary-cache-and-mmap() stuff.) Again, this is not even slightly a new idea. How long ago was KDE 2 released again?
Know what is new since 2005? Posted Sep 6, 2010 15:40 UTC (Mon) by gmatht (subscriber, #58961) [Link]
I didn't notice the 2005. Its weird though, there doesn't seem to be much recent discussion of dconf, virtually all the discussion I can find is from 2005. I don't know whether the issues raised then have been addressed. For example, do the KDE devs like dconf? Will it show up in KDE, or has it done so already?
Know what is new since 2005? Posted Sep 17, 2010 14:25 UTC (Fri) by jospoortvliet (subscriber, #33164) [Link]
Warning: rant.
Yeah, it has shown up in KDE already, somewhere around 2000. It's called KConfig and supports indeed different backends. It reads all flat-text config files (default backend), caches it in a binary file, uses inotify to see if changes are made and if that happens rebuilds the binary file.
This gives all the advantages of a windows-registry like binary blob but not the disadvantage (if something is wrong you can easily regenereate the binary cache from the original files).
Oh and it doesn't need a separate daemon! It works as a plugin to KDED (like battery monitoring, network and a billion other things). So it is a very efficient solution.
dconf claims to be aiming for cross-desktop, but it was purely developed for one set of apps. Imho there should've been a bit more discussion - after all, KConfig was open, I'm fairly sure a GTK variant or even just bindings could've been created instead of re-inventing the wheel. Even more, I remember that being suggested from the KDE side... So dconf = NIH at work.
And yes, that IS a freedesktop.org issue - a lot of people ignore it when developing something, then put their solution on there and claim it's the second coming of you-know-who. Meanwhile other projects doing honest, hard work on cross-desktop solutions (like Akonadi) are refused a location on FDO - worse, if others figure out what they are doing is a good idea they start a *competing* solution. WTF?
But I'm sure there are people who can explain this - the type who can 'explain' why a circle is square can handle this too, I bet.
But that's mostly history now (recent for sure). And very similar to what happened to D-BUS - which ended up being adopted by the KDE community anyway, despite the fact it took a long time after adoption until it was really good enough to replace DCOP (I've heard it's still slower).
So maybe dconf will be picked up after all. Which would be nice - sure, another daemon instead of the KConfig solution which doesn't need that. But at least it should improve interoperability. I just wish next time someone starts developing something like Pulse Audio or dconf or D-Bus that they discuss it with the 'other desktop' and try to be a bit openminded when it comes to technology on that side. It's often better... And should surely lead to better solutions.
Luckily this seems finally happening with things like the desktop icon spec, systray spec, global menu (nice, Ubuntu!) and a few more. Points for that.
|
|
||||||||||||||||||