X3D (wikipedia) is one of those standards that is going to become very popular because it has a huge feature set or fail into obscurity because it is too large and complex to use. Regardless, I've just discovered the specification and have been reading about it / playing around w/ a few implementations over the last few days and I'm pretty impressed.
The cool thing about X3D is that it is a whole 3D scene standard, meaning not only does it encapsulate 3D meshes contained within traditional standards, it has practically everything you want for a 3D world. Lighting, Materials, Networking, Sound, Events, Animation, Scripting, Physics / Collision, and a slew of other 3D scene properties can be described in the X3D format. Of course the trade off for being this complete is the complexity of the standard.
The Draft Specifications and xsd go a long way to (starting to) understand the specification. At its root X3D is fairly straightforward, it is represented via xml files, created with a generator and parsed with a loader. Loaders do not run any of the dynamic / execution time components, rather a browser is used to manage scenes/scene graphs, the complete hierarchical set of all objects known as nodes. Nodes contain descriptive fields and events to manipulate and query the node state.
From there its just different node types which describe different types of components in the system. Components exist for 2D and 3D locations, coordinates, geometry, resources (audio, input, network, etc.), animation, collisions, navigation, organization, etc. Needless to say, alot of abstraction/inheritance is used, component interfaces sometimes expand several levels deep before concrete node object classes are defined. It's pretty complex but complete.
X3D itself is a successor of the VRML standard, the old VRML syntax is still supported as an alternative for xml. It's a relatively new standard, first approved in 2005, and at the very least an interesting study. I may continue to muck around with it, possibly using it in an new project in the future.
I've just tossed up two new morsi.org subdomains. projects.morsi.org is my new hosting space for projects I'm working on. yum.morsi.org is a yum repository setup for my rpms, which right now only has Romic but I will be putting up Motel soon and more in the future. Putting it to use is as simple as creating /etc/yum.repos.d/morsi-org.repo with the following:
[morsi-org] name=morsi-org baseurl=http://yum.morsi.org/repos/$releasever/ enabled=0 gpgcheck=0
I found creating / hosting a yum repo to be remarkably easy. On my local machine, I created a 'yum' directory with a 'x86_64' subdir (create more for other architectures as needed, x86, noarch, etc) copied my rpms into it, and ran 'createrepo yum'.
Optionally create a domain, and on your webhost create a 'repos' subdir under the webroot dir. Create a subdirectory under this for the fedora release version your are building for (or whatever you are running by default), eg '11' as currently Fedora is on version 11.
scp the entire yum directory from your localmachine to 'repos/<release>' on your webhost. Finally create the yum.repos.d on any client you want to pull packages from your repo, and make sure to specify --enablrepo=<reponame> when running yum.
Optionally you may also want to change the .htaccess in your repository's webroot to alter the look of the yum index.
Although I was a slow adopter, I am now an adamant git user. I won't go into all the details here, but git is a great distributed version control system (vcs), light years ahead of the last generation (cvs, svn), and honestly if it isn't too cost prohibitive, I would greatly recommend switching to it (the Linux kernel tree was moved to git, so I can't really see why anyone else wouldn't be able to).
Although I've never used it before, I've also heard alot of great things about the Mercurial (hg) distributed version control system. Recently one of the projects I was working on for work required me to use mercurial, so I've started getting up to speed.
One thing that took me a few minutes to discover is how to replate the git format-patch command w/ hg. eg with git, to see a list of all commits and then format a patch from the last one, run:
git log git log HEAD^ -p git format-patch HEAD^ git send-email 001-patchname.patch git send-email HEAD^ # alternatively
Doing the same w/ HG:
hg log # note this isn't paginated, a feature git has over hg imo hg log -r tip -p hg email -r tip
This is good starting place for those familiar w/ hg or git and are trying to use the other.