Re: CMS Review: Bricolage on the Nautis Project

On Wed, 22 Aug 2007, Simon Wilcox wrote:

> brad harder wrote:
>
>>  fta:
>> >  These are just two examples; there seems to
be a consensus that 
>> >  Bricolage
>> >  is not easy to install.
>>
>>  2 out of 2 people agree Bricolage is hard to
install. It's unanimous.
>
> It should go in cleanly on a clean install of most OSs
but compared to php 
> based applications even that is a bitch.
>
> If something break down (Math::PARI anyone ?) it's near
on impossible.

I consider myself _highly skilled_, both in Perl and Linux.
Bricolage was 
an absolute bear to install and configure on Redhat
Enterprise 3. It would 
be just as bad on RHEL4 or RHEL5.

Apache 1.3.x with mod_perl 1.x and Perl 5.8.x (an intriguing
mix of the 
antique and the modern - people who already run Apache 1.3
and mod_perl1 
don't generally _also_ run Perl 5.8, although I understand
why Perl 5.8 is 
a requirement: 5.6 is nearly dead and many modules won't
compile for it at 
all now), all built from source tarballs, plus some Perl
modules that did 
not want to install cleanly (Math::Pari indeed
- I know what to hack to make it install correctly from
behind a NAT, but 
I really doubt very many people can figure it out).

The combination would beat *most* people trying to install
it. If it can't 
been installed on most *nix machines without resorting to
compiling 
Apache/mod_perl/Perl/Perl modules from source, done by an
expert, it is a 
*BIG* problem.

Install is, and always has been, Bricolage's major flaw.

If I were to pick the one thing that would help Bricolage
adoption, it 
would be to create a completely self-contained, officially
supported, 
VMware appliance image running either CentOS5 or Ubuntu (and
get it 
published on VMware's appliances website) or create a
.deb/.rpm based 
install that "just works".

It has to be simple to install or people will just continue
to move to 
things that _are_ simple to install. While not CMSs, and so
targetted 
differently, it is instructive to look at blog software.

MovableType is considered _hard_ to install for most people
compared to 
WordPress. Which is why there are so many more WordPress
based blogs than 
MT based ones. And MT is at least twenty times easier to
install than 
Bricolage is.

Apache1.3 vs Apache2, mod_perl1 vs mod_perl2, PostgreSQL vs
MySQL, Web 1.0 
or Web 2.0 aren't the most important problems.

Ease of install and upgrade _is_.

-- 
Benjamin Franz

"It is moronic to predict without first establishing an
error rate
  for a prediction and keeping track of one’s past record
of accuracy."
                     -- Nassim Nicholas Taleb, Fooled By
Randomness

Benjamin Franz wrote:

> I consider myself _highly skilled_, both in Perl and
Linux. Bricolage 
> was an absolute bear to install and configure on Redhat
Enterprise 3. It 
> would be just as bad on RHEL4 or RHEL5.

Conversely, it works like a charm on Debian Sarge & Etch
as the 
necessary packages are still in the package tree.

> The combination would beat *most* people trying to
install it. If it 
> can't been installed on most *nix machines without
resorting to 
> compiling Apache/mod_perl/Perl/Perl modules from
source, done by an 
> expert, it is a *BIG* problem.

Agreed.

> Install is, and always has been, Bricolage's major
flaw.

Agreed although Bricolage isn't alone in this. Most major
perl 
applications have similar problems, including RT which can
also be a bitch.

> MovableType is considered _hard_ to install for most
people compared to 
> WordPress. Which is why there are so many more
WordPress based blogs 
> than MT based ones. And MT is at least twenty times
easier to install 
> than Bricolage is.

This is as much perl vs php however and php has the edge
over perl every 
time because the latter needs access to directories outside
of the 
docroot. This is actually a limitation of the perl binary
but Nick 
Clarke and others have suggested that this will be fixed in
perl 5.10.

> Apache1.3 vs Apache2, mod_perl1 vs mod_perl2,
PostgreSQL vs MySQL, Web 
> 1.0 or Web 2.0 aren't the most important problems.
> 
> Ease of install and upgrade _is_.

Agreed but choosing the right distribution makes it
infinitely easier. 
It's a poor defence though and we should be making it as
easy as possible.

Simon.

-- 
Digital Craftsmen Ltd
Exmouth House, 3 Pine Street, bond. EC1R 0JH
t 020 7183 1410 f 020 7099 5140 m 07951 758698
w http://www.digitalcr
aftsmen.net/

Benjamin Franz wrote:

> Install is, and always has been, Bricolage's major
flaw.

It probably is on other systems but on Debian/Ubuntu it is
incredibly 
simple for an install even including SFTP and therefore
Math::Pari.

I have installed Bricolage on Sarge and Etch and Ubuntu 6.10
and 7.04 
from bricolage version 1.8 to 1.10 and it works everytime
out of the box.

http://wiki.bricolage.cc/bin/view/Bric/InstallationTips

Follow the Manual Installation guide above which gives you
just four 
instructions

apt-get install (cut and paste package list)
install five modules from CPAN given
edit pg_hba.conf
make install in your unzipped tarball, follow onscreen
prompts

I appreciate it's probably difficult for other OS's but it
is pretty 
simple for a debian sysadmin / developer . But then why
would you want 
to run any other OS once you've found Debian/Ubuntu ?

/me runs and hides 

regards,

Paul

On Thu, 23 Aug 2007, Benjamin Franz wrote:
> I consider myself _highly skilled_, both in Perl and
Linux. Bricolage was an
> absolute bear to install and configure on Redhat
Enterprise 3.

Hmm, highly skilled. Therefore capable of submitting
patches to fix the installation?  :P

Benjamin Franz wrote:
>
> Install is, and always has been, Bricolage's major
flaw.
>
> If I were to pick the one thing that would help
Bricolage adoption, it 
> would be to create a completely self-contained,
officially supported, 
> VMware appliance image running either CentOS5 or Ubuntu
(and get it 
> published on VMware's appliances website) or create a
.deb/.rpm based 
> install that "just works".
>
> It has to be simple to install or people will just
continue to move to 
> things that _are_ simple to install. While not CMSs,
and so targetted 
> differently, it is instructive to look at blog
software.
>
> MovableType is considered _hard_ to install for most
people compared 
> to WordPress. Which is why there are so many more
WordPress based 
> blogs than MT based ones. And MT is at least twenty
times easier to 
> install than Bricolage is.
>
> Apache1.3 vs Apache2, mod_perl1 vs mod_perl2,
PostgreSQL vs MySQL, Web 
> 1.0 or Web 2.0 aren't the most important problems.
>
> Ease of install and upgrade _is_.
>

While I generally agree that Bric can be difficult to
install - it can 
require a bunch of disciplines maybe not entirely consistent
with, say, 
web development - I don't think it should be considered a
significant 
barrier to entry for using it.  Content Management is a hard
problem to 
solve, and Content Management one-size-fits-all is
impossible.

Bricolage is a good solution for enterprise, and less of a
good solution 
for a personal website, specifically because it can and
should be 
shoehorned into a heterogeneous and fluid environment.  A
user who gets 
frustrated installing Bric truly may be better served by a
solution like 
Drupal, or some other application server.

A potential user should have the resources available -
either financial 
or personnel - to tackle install issues, because if they
don't, it's a 
strong bet that they won't be leveraging Bric to its full
potential.  
And if that's the case, as I said, they're probably better
off with 
something else.  The products that Bricolage competes with
aren't the 
ones that are cheap and/or easy to install.

Maybe a better way to look at it would be as a Content
Management 
Framework?  If the unit responsible for IT isn't in control
of the unit 
responsible for marketing, they better have a flexible
framework, and 
Bric provides that.  I've worked with a number of content
management 
tools and Bric is by far the most flexible, stable, and
consistent.

Finally, regarding vitality, it would definitely aid
adoption if there 
were more frequent website updates and maintenance releases,
but I 
wouldn't confuse frequent releases with improved product:
see Fedora 
Cores 1-999.  Any issue that's raised on the mailing list
seems to be 
solved pretty quickly.

John