RPM vs. tar for distribution for open source web applications

RPM advantages

  • Installation always puts it in the same location
  • Single copy of the source on the server, saves disk space
  • Potentially more secure, since permissions can be set to read-only
  • RPM can serve as an installation wizard, rather than writing one
  • RPM can also uninstall
  • Dependencies managed by RPM
  • Upgrades can be managed by RPM
  • Fits nicely into larger architecture
  • Can cross directories to handle configuration at different levels, for example, add an Apache .conf file.
  • Allows custom default configuration to be installed easily

RPM disadvantages

  • Single copy means application shouldn’t be customized once installed, all accounts will have to run the same
  • Single copy also means there may be additional filesystem architecture adaptations, for example a compiled template directory normally placed under the application would have to be accommodated. Application may have to be modified
  • May require root access
  • Filesystem architecture should be known
  • Requires installer to have some knowledge of RPM, usually more complex than tar
  • Requires installer to understand more filesystem commands (how to link into installed application, rather than install it
  • If application is normally distributed as a tar/gz file, RPM will be outside the documentation
  • Creating RPMs is far more complex than creating tars. Learning curve.
  • Development team and environment. If everyone is working on a single server, it may be difficult for them to share a single copy of an application. Consider VMWare.

Deciding Factors

  • Installation type - single application on the server, or multiple. Single is best with RPM, multiple is probably better with tar
  • Application source - custom applications may be better with RPM, outside/open source applications are probably better with tar
  • Dependencies and type - RPM really does a nice job with dependencies
  • Upgrades - RPM allows yum/up2date management of upgrades, with dependency observation
  • Skill/experience/education level of team
  • Servers in use - tar may be slightly more portable
  • Flexibility of target system
  • Updates during development are very easy to apply with RPMs

Image substitution

Image substitution has been added. This allows you to extract the images, and view them and their dimensions. You can then create new images with the same names to change the design.

robots.design interface updates ...

The color mapper is transitioning to use a more polished interface.

dojo - ContentPanes - compression

To compress the content delivered to a dojo ContentPane, you can compress the content and cache it with the Zlib functions of PHP, then open it with the filesystem functions and deliver it with the Content-Type header set to “text/html” (or other appropriate setting), and Content-Encoding set to “gzip“.

The compress and cache should be performed if the file is likely to be reused. If reuse is unlikely, or the file is relatively small, use gzencode or gzdeflate.

This should work with other libraries as well.

Careers are Important

A career is important. It is how you get the money to do the things that are important to you.

With that in mind, the company you work for must be stable enough to deliver that income.

Look around, listen, think. Are the customers happy? Is the work done well? Are projects profitable?

If you answered ‘no’ to any one of these questions - look more, think more. If the customers aren’t happy, they will leave, and it will be more difficult to attract new customers. If the work isn’t done well, the customers won’t be happy and it will be harder to get new customers. If projects aren’t profitable, the company simply cannot survive. It will be closed or sold.

Not every customer will be happy, not every project will be done well, and there are often projects that go overbudget - however - if the majority of the time, things go well, everything will be okay.