I just learned that the Dell employee discount, which is offered to employees of numerous Dell partners, does not apply to their N-series laptops, even though many people only have this discount because of their work with Ubuntu.
The irony continues to drip as the models I compared between the employee purchase price and the Ubuntu versions of the same, such as the Inspiron 15 and Inspiron 15n, roughly discounted the added cost of Windows 7 only. It appears that the employee discount equates to free Windows 7.
The current Dell Ubuntu offerings lack in many other areas, such as not offering gigabit ethernet or 802.11n as options. While I would love to support Dell in working with the Ubuntu community more, I really can't justify buying a sub-par laptop at the prices they're offering them at.
My friend Mackenzie showed off her System76 laptop at the 9.10 release party a few weeks ago. All of their laptops include gigabit ethernet, 802.11agn wireless, and many other options Dell doesn't offer. They're a bit more pricey, but according to Mackenzie their service is significantly better.
Monday, November 30, 2009
Thursday, November 19, 2009
moving to Bullet
Bullet has some really great features over ODE; soft body physics, particle physics, and hardware acceleration among the top.
After talking with a Crystal Space developer about this, I put it on my list of things to look into when PySoy is a bit more mature. However, a Debian packager's decision has accelerated these plans.
ODE is not designed to be installed as a single shared library, it has many build-time options which radically change it's behaviour - such as whether the library uses single or double precision, or whether to calculate gyroscopic force. As a general rule, distributions stick to the defaults when packaging as much as possible, but Debian (and thus Ubuntu and other Debian-based distros) ship a single system-wide library with non-default compile flags (Double precision) that would result in sub-par performance, network sync issues, and in some cases bugs in games.
Debian could have shipped four or eight different versions of the ODE library, such that games could be linked against the one it was designed for and work as expected, or ODE could have been designed to build both a single and double precision library with the other options as runtime flags, but instead we game developers are caught in the middle.
We fought this battle before with Soya, for some time actually, and in the end Soya had to ship their own version of ODE embedded in the source and statically linked to get around the problem. Even then it was an issue to get the package including a static ODE included. It's a battle not worth fighting.
While Bullet also supports building as double precision, it's an option so rarely used that no distro builds with it (Gentoo doesn't even have a USE flag to switch it), and given that Bullet is currently not packaged for Debian it'd be easier to add it as a new proper package than fight Debian packages to improve their build of ODE.
I am not looking forward to working with Bullet's incomplete C-API, likely having to fill in some gaps as we work on it, nor writing the Vala bindings for Bullet, but it'd be a lot faster and fun - not to mention resulting in new features.
After talking with a Crystal Space developer about this, I put it on my list of things to look into when PySoy is a bit more mature. However, a Debian packager's decision has accelerated these plans.
ODE is not designed to be installed as a single shared library, it has many build-time options which radically change it's behaviour - such as whether the library uses single or double precision, or whether to calculate gyroscopic force. As a general rule, distributions stick to the defaults when packaging as much as possible, but Debian (and thus Ubuntu and other Debian-based distros) ship a single system-wide library with non-default compile flags (Double precision) that would result in sub-par performance, network sync issues, and in some cases bugs in games.
Debian could have shipped four or eight different versions of the ODE library, such that games could be linked against the one it was designed for and work as expected, or ODE could have been designed to build both a single and double precision library with the other options as runtime flags, but instead we game developers are caught in the middle.
We fought this battle before with Soya, for some time actually, and in the end Soya had to ship their own version of ODE embedded in the source and statically linked to get around the problem. Even then it was an issue to get the package including a static ODE included. It's a battle not worth fighting.
While Bullet also supports building as double precision, it's an option so rarely used that no distro builds with it (Gentoo doesn't even have a USE flag to switch it), and given that Bullet is currently not packaged for Debian it'd be easier to add it as a new proper package than fight Debian packages to improve their build of ODE.
I am not looking forward to working with Bullet's incomplete C-API, likely having to fill in some gaps as we work on it, nor writing the Vala bindings for Bullet, but it'd be a lot faster and fun - not to mention resulting in new features.
Thursday, November 05, 2009
beta-3 roadmap updated
I updated the Roadmap for 1.0-beta3 today.
In short, we're dropping ambitions for audio support in this release. Once our migration to Vala is complete and the related changes implemented we'll release without further delay. After that we'll begin work on the newer features like audio, networking, and browser embedding for beta4 while the community tests and gives feedback on beta3.
There are a lot of new features already compared to the beta2 release. We're aiming for a beta3 release by January 1st 2010, 2 years from the beta2 release.
In short, we're dropping ambitions for audio support in this release. Once our migration to Vala is complete and the related changes implemented we'll release without further delay. After that we'll begin work on the newer features like audio, networking, and browser embedding for beta4 while the community tests and gives feedback on beta3.
There are a lot of new features already compared to the beta2 release. We're aiming for a beta3 release by January 1st 2010, 2 years from the beta2 release.
Subscribe to:
Posts (Atom)