Making the case for Django (vs. Drupal)
shacker
Drupal. A large and active users group, and dozens of departmental
sites running it. I've succeeded in building a few departmental sites
with Django but still feel like it's an uphill battle convincing
managers to agree to go with a relative unknown, both in terms of
language (Python) and platform. Things like the announcement that
whitehouse.gov switched to Drupal just cement the deal in many
managers' minds.
I'd like to put together a summary sheet and blog post summarizing all
the reasons why I feel Django is the better choice for many sites, to
try and help make the "sale" to managers. I have my own set of reasons
but am not going to include them in this message. I'm especially
interested in hearing from people who have done development in both
Django and Drupal (or WordPress or Joomla, or other). Would be
interested in hearing comments on things like:
- Overall development time
- Ease of making changes to templates
- Ease of finding 3rd party functionality (modules vs. reusable apps)
- Server performance
- Ease of building data models that reflect the needs of the
organization
- Ease of finding other developers to take on a project when someone
leaves
- User friendliness (admin and editorial interface)
- Ease of getting the system to do highly custom tasks
- Ease of upgrades
- Security
etc. etc. - anything at all. Please indicate whether it's OK to quote
you (I can paraphrase you if not)
Thanks in advance,
Scot
Alexandru Nedelcu
a platform to be friendly both to users and to developers, and IMHO,
Drupal is decent but doesn't do great on anything (ease of use, ease
of development, scalability, etc...).
Drupal has many more third-party modules.
But those modules are very opinionated and some are of poor quality,
even when you would expect otherwise (I've had problems configuring
the I18N module, and I couldn't do it to behave reasonably ... making
a Drupal website multi-language is a pain).
Development in Django is a lot easier, because the modules are more
generic and the development process is more predictable because of its
simpler architecture. This is not easy to demonstrate though. The best
thing you could do is to take some time to learn some Drupal
development (there's a book Pro Drupal Development on Amazon) ... and
then do a comparison between the two by implementing a feature,
measuring the lines of code written, going through the problems you
had, etc ...
Another thing you could do is to implement your own CMS in Django that
has most of the features managers are looking for ... most people will
not say no to something that's already implemented. If they still have
troubles deciding, then do a scalability test.
On Sat, Oct 31, 2009 at 6:44 PM, shacker <sha...@birdhouse.org> wrote:
>
> At the university where I work, there is a LOT of momentum behind
> Drupal. A large and active users group, and dozens of departmental
> sites running it. I've succeeded in building a few departmental sites
> with Django but still feel like it's an uphill battle convincing
> managers to agree to go with a relative unknown, both in terms of
> language (Python) and platform. Things like the announcement that
> whitehouse.gov switched to Drupal just cement the deal in many
> managers' minds.
--
Alexandru, Nedelcu
http://alexn.org
sste...@gmail.com
On Oct 31, 2009, at 1:20 PM, Alexandru Nedelcu wrote:
> Another thing you could do is to implement your own CMS in Django that
> has most of the features managers are looking for ...
That's *exactly* what scares the crap out of managers; custom code vs.
something "everyone" is using. You're almost making Drupal's case,
right there.
S
Andy McKay
things you mentioned) are quite different things. You are comparing
apples to oranges which makes the sell harder.
Drupal is a CMS and has a different target audience. It has the level
of complexity that comes from solving the CMS problems.
Drupal like most CMS's will allow you to do things the Drupal way
quite easily. As soon as you stray from that path, you'll be in trouble.
I recommend understanding your audience and the difference in tools
and how this affects them.
--
Andy McKay
www.clearwind.ca
shacker
> One key thing to remember is that Django and Drupal (and the other
> things you mentioned) are quite different things. You are comparing
> apples to oranges which makes the sell harder.
CMS. That part of the question resolves to something like "Is it
easier to use a prefab CMS (Drupal) with all of its opinions and
assumptions you have to wrestle with, or to start from the base level
(Django) and build up to what you need?"
In my experience, the Django admin suffices just fine AS the CMS in
many/most use cases, with a few modifications and the occasional
custom view.
It's been said that Drupal is a CMS with framework-like tendencies
while Django is a framework with CMS-like tendencies. The lines get
fuzzy.
To me, questions like "Is the fact that Drupal is not object oriented
and not MVC/MTV a major or minor annoyance?" (to me it's a major
annoyance).
So I'm aware of the overlaps and differences. I'm really looking for
responses to the questions in my OP.
./s
Mike Ramirez
> One key thing to remember is that Django and Drupal (and the other
> things you mentioned) are quite different things. You are comparing
> apples to oranges which makes the sell harder.
>
> Drupal is a CMS and has a different target audience. It has the level
> of complexity that comes from solving the CMS problems.
>
> Drupal like most CMS's will allow you to do things the Drupal way
> quite easily. As soon as you stray from that path, you'll be in trouble.
>
> I recommend understanding your audience and the difference in tools
> and how this affects them.
> --
> Andy McKay
> www.clearwind.ca
This is very true, but he can sell it as a cms with one of the many cms for
django[1]. Here he can pick one that matches the known requirements the
managers are looking for, then sell django along with the cms.
After that there are really only three main selling points, customization,
django has plenty of prebuilt apps[2] and the ability to build your own app
with ease. Secondly, speed of development, all php needs is header files to be
a poor mans version of C. Django has made making web apps almost trivial and
the most time I spend now, is on the ui (both dojo and jquery make this almost
trivial also), rather than the backend.
Finally, there is the maturity of the language. PHP is still adding in
features other, similar languages already have had. For example namespaces are
just barely a year old in php, initial release in the dev versions, less than
6 months for the actual first appearance in a stable release.
To quote wikipedia[3] on missing features from PHP:
"PHP currently does not have native support for Unicode or multibyte strings;
Unicode support will be included in PHP 6 and will allow strings as well as
class, method and function names to contain non-ASCII characters."
Seriously, in todays global world and well, for the past what 10-15 years,
hasn't this been mandatory?
I do not understand why web developers who use php, still do. I don't
understand why companies and schools support it. When there has been other
better languages to use, python, perl, java and haven't changed as much as php
has and still have more, better, what I call mandatory features, plus better
or equal performance. Well I do understand how it happened at first and
recognize it's not going anywhere. I just wish it would go back to the toy
bin/kindergarden for web developers to understand the nature of dynamic web
pages.
See the wikipedia page for related security topics also.
The only strength php has that I believe is a strength and a weakness is it's
drag and drop install. It's a weakness the same reason php security is, bad
web developer choices, like storing include files and other files with
sensitive information in web accessible directories. (Who remembers the
inlcude() hack or fread on a remote url?)
This is my main argument; the ability/maturity of the language itself.
I do think that a lot of people who use php are smart individuals and just
make honest mistakes that led to phps bad repution in security. But, by
default, because of the intelligence of the django devs in getting this part
right, that it is harder for new developers to make similar security mistakes.
Really only in a few places allow you to.
The reason I came to django, because of the language it's based in. Though
many a day I wonder how django would do as a C++ framework. I may find out one
day, but not in the near future.
Mike
[1] http://code.djangoproject.com/wiki/CMSAppsComparison
[2] http://djangozen.com/
[3] http://en.wikipedia.org/wiki/PHP
P.S. quoting me is fine, but I think the wiki page and links will make a
better impression, so I suggest paraphrasing me if you find any of this
useful.
--
Anyone who cannot cope with mathematics is not fully human. At best he
is a tolerable subhuman who has learned to wear shoes, bathe and not
make messes in the house.
-- Lazarus Long, "Time Enough for Love"
Christophe Pettus
On Oct 31, 2009, at 11:52 AM, Mike Ramirez wrote:
> I do not understand why web developers who use php, still do.
PHP has a large, and (perhaps more importantly) easy-to-find ecosystem
surrounding it. I think that Python's superiority as a language is
simply not open to debate, but if you are looking for "I need a
library that does <x>", PHP frequently has acceptable solutions closer
to hand.
And, as with PostgreSQL vs MySQL, shared web hosting is very strongly
oriented around PHP, and that (until the relatively recent rise of
VPS) was the primary entry point for a lot of web developers.
--
-- Christophe Pettus
x...@thebuild.com
Mike Ramirez
It was a rhetorical question. Tho the same goes for MySQL. Why?
I do understand, I was there too watching and developing back in the early
2k's with php4 and first few versions of 5 helping clients cause I ran one of
those hosts. Sorry for not being specific about that. Truth is that we used
MySQL and PHP mainly because CPanel (and other virtual host control panels)
had the support built-in and made it easy for the users and less headaches on
us.
Mike
--
Squirming:
Discomfort inflicted on young people by old people who see no
irony in their gestures. "Karen died a thousand deaths as her father
made a big show of tasting a recently manufactured bottle of wine
before allowing it to be poured as the family sat in Steak Hut.
-- Douglas Coupland, "Generation X: Tales for an Accelerated
Culture"
Preston Holmes
On Oct 31, 8:44 am, shacker <shac...@birdhouse.org> wrote:
> At the university where I work, there is a LOT of momentum behind
> Drupal. A large and active users group, and dozens of departmental
> sites running it. I've succeeded in building a few departmental sites
> with Django but still feel like it's an uphill battle convincing
> managers to agree to go with a relative unknown, both in terms of
> language (Python) and platform. Things like the announcement that
> whitehouse.gov switched to Drupal just cement the deal in many
> managers' minds.
>
> I'd like to put together a summary sheet and blog post summarizing all
> the reasons why I feel Django is the better choice for many sites, to
> try and help make the "sale" to managers. I have my own set of reasons
> but am not going to include them in this message. I'm especially
> interested in hearing from people who have done development in both
> Django and Drupal (or WordPress or Joomla, or other). Would be
> interested in hearing comments on things like:
>
This was at the tail of Drupal 5, and haven't used it a ton since, but
had set up several smaller drupal sites before then.
There are going to be lots of "it depends"
> - Overall development time
For a basic CMS site - Drupal will be faster and more full featured
out of the box.
Page design time is going to be about the same either way
> - Ease of making changes to templates
files and the inheritance system is simple - there are books about
doing templates in Drupal
> - Ease of finding 3rd party functionality (modules vs. reusable apps)
problem with Drupal is its relatively fast moving core - so that
modules for the "current version" are hard to find, or often
abandoned. Also Drupal modules almost always seem to do 80% of what
you need.
> - Ease of building data models that reflect the needs of the
> organization
is usable by non devs to create custom content types, and the Views
module allow for simple generic_view style pages. When it comes to
more complex objects, Django's ORM is far superior.
> - Ease of finding other developers to take on a project when someone
> leaves
small fixes, or maintenance. Everyone was looking for the big fish of
bigger full site design with more $$$ involved.
> - User friendliness (admin and editorial interface)
can be made much more clear and focused. Where Drupal has its single
biggest advantage, is that a technical user, a sys-admin etc, can get
Drupal up and running. Someone doesn't have to know PHP AT ALL to get
drupal going. This is because Drupal has a decent admin-UI - where
modules are pretty much drop in, activate and configure.
Setting up even a basic Django site REQUIRES someone who has some
programming skills, even if thats just a matter of setting up the
settings.py file.
What happens is that non-developer/technical decision makers will
evaluate Drupal and think that all their needs will be met out of the
box. When they find out they aren't, they need to hire developers,
and then those developers have to massage existing modules to
customize and tweak. Then at some point they have this monster of
hodgepodge code. But its that entry point that is the key to Drupal's
popularity.
What Django needs IMHO is an admin UI for Pinax. Pinax project plans
to do this "someday". When Pinax can have a web-based install, with
an admin UI to enable/disable pluggable apps - Django will experience
huge win. Because the same thing will happen as does for Drupal,
there will be technical users who evaluate pinax and think it can do
everything for them. At some point they will need a custom app - they
HIRE a django dev. That Django dev writes a well done reusable app -
and often with the blessing of the hiring company, releases that into
the world. Let this process continue and you can see that eventually
the Django app universe will grow.
I don't think people appreciate how much Drupal development is spawned
by this existence of a usable entry point for Drupal by non-
developers. (and that it has 1-click installs on hosts, and in general
uses the far more common infrastructure of PHP-MySQL)
> - Ease of getting the system to do highly custom tasks
Drupals assumptions translate into your code having to jump through a
lot of hoops - where as in Django, you make the assumptions and you
make the hoops.
Dougal Matthews
Things like the announcement that
whitehouse.gov switched to Drupal just cement the deal in many
managers' minds.
I can't find the source for this (the original tweeter has protected tweets) but if true its an interesting stat.
http://twitter.com/pydanny/status/5263754707
Plone not Django, but its closer than Drupal.
Cheers,
Dougal
shacker
this thread. Sorry I got side-tracked for a while. I've just put up a
pretty complete draft of a post on this topic, written with decision
makers (managers, supervisors) in mind. It's still probably somewhat
technical for that group, but that's the nature of the topic.
http://birdhouse.org/blog/2009/11/11/drupal-or-django/
Before I send it out to some people I need to see it, wanted to bounce
it off you guys - make sure I didn't screw anything up, get anything
wrong, mis-attribute anything, etc.
Feedback and further contributions welcome.
Thanks all,
Scot
bruno desthuilliers
On 12 nov, 01:16, shacker <shac...@birdhouse.org> wrote:
> I've just put up a
> pretty complete draft of a post on this topic, written with decision
> makers (managers, supervisors) in mind. It's still probably somewhat
> technical for that group, but that's the nature of the topic.
>
> http://birdhouse.org/blog/2009/11/11/drupal-or-django/
>
>
>
1/ wrt/ performances AND rapid development : I recently had to work on
a not-so-complex (functionaly-wise) Durpal project, and the response
times on my local station - all caches disabled of course - turned the
development process into a sluggish nightmare. Never had this kind of
problems with Django, even for far more complex apps.
2/ wrt/ rapid development again: I started yesterday afternoon (on my
spare time) a simple virtual gallery application for a painter friend
of mine. I had more than half of the application (including templates
etc) working in a couple hours, and most of the still missing features
will be provided by existing pluggable djang apps. It shouldn't take
more than a couple more hours to have the whole thing up and running.
And when I say "a couple hours", I really mean it, litteraly !-)
Else, I just can second most of the developper's comments : from my
experience, it can take more time doing "simple customisations" on
Drupal than you'd need to implement the same features from scratch in
Python.
My 2 cents.
Nick Lo
> I just wanted to thank everyone for their excellent contributions to
> this thread. Sorry I got side-tracked for a while. I've just put up a
> pretty complete draft of a post on this topic, written with decision
> makers (managers, supervisors) in mind. It's still probably somewhat
> technical for that group, but that's the nature of the topic.
I can of course only speculate here, but I imagine that the appeal of Drupal you are trying to compete against is that, from their perspective, in going from 0-60, Drupal appears to already be at 50. It really doesn't matter to them that it could have taken 4 times as long to get from 0-50 as it would have taken if Django was used. To them the tangible is where Drupal is now.
It's also a jump to be able to realise that the 50-60 bit takes even longer and may actually never quite get there with a pre-existing solution. Your post almost deepens the sense that yeah, Django may be great but it's at 0 and as a manager I have to put ALL my trust in you that you're right. Partly because all those things Drupal already has I don't have either the time or knowledge, or both, to manage the development of anyway.
With that in mind I think you need to start at a more comparable point to Drupal. It has loads of solutions already built that actually DO work together which you don't mention. Drupal is a CMS so why not refer to existing CMS apps or better, let NASA do it for you:
http://pydanny.blogspot.com/2009/11/picking-django-powered-cms.html
There is one point that you made that you should push a lot more, albeit a little differently: "In Django, all development starts by defining the data models that describe the organization, publication, or site.". That single point is huge for an organization; Compared to a pre-existing solution Django is used to build something that fits the organization not the other way round.
Where I think you need to reword is that you say "starts by". Does the manager really know where the start is? Do they picture a blank page with a blinking cursor? Of course they'd be nervous if that is what they see. You and the rest of us on this list know of course that Django is itself already very well equipped and what it doesn't contain it has an ever increasing list of 3rd party solutions that can be used even if temporarily.
I could probably go on but I think I need to let sleep have it's way for a change!
Cheers,
Nick
Ray
> I just wanted to thank everyone for their excellent contributions to
> this thread. Sorry I got side-tracked for a while. I've just put up a
> pretty complete draft of a post on this topic, written with decision
> makers (managers, supervisors) in mind. It's still probably somewhat
> technical for that group, but that's the nature of the topic.
>
> http://birdhouse.org/blog/2009/11/11/drupal-or-django/
>
You should probably send a link over to the Drupal forum as well to
get some feedback from the other side of the fence.
To sum it up, anyone who is good developer and experienced in either
platform will probably produce very similar results in a similar
timeframe.
It really comes down to:
"do you (or your department) want to write code in PHP or Python"
because unless you have hugely complex or popular sites, either would
work quite comfortably.
Regards,
Ray Smith
scot....@gmail.com
substantial changes and additions based on your feedback.
Yes, I'd like to get feedback from some Drupal people, but again want
to focus on devs who have worked in *both* systems. If you know of
anyone who has, feel free to point them to the document.
http://birdhouse.org/blog/2009/11/11/drupal-or-django/
./s
Kenneth Gonsalves
> Thanks everyone for the additional comments. Draft #2 is up now, with
> substantial changes and additions based on your feedback.
>
> Yes, I'd like to get feedback from some Drupal people, but again want
>
> http://birdhouse.org/blog/2009/11/11/drupal-or-django/
>
holes in drupal over the past year with the one hole in django in the past 4
years. btw, I tried to comment on your blog, but was rejected saying I was
behind a proxy. Given that practically any one on a LAN is behind a proxy,
this in practice prevents comments.
--
regards
Kenneth Gonsalves
Senior Project Officer
NRC-FOSS
http://nrcfosshelpline.in/web/
shacker
> >http://birdhouse.org/blog/2009/11/11/drupal-or-django/
>
> looks like you have missed out on security - count the number of critical
> holes in drupal over the past year with the one hole in django in the past 4
> years. btw, I tried to comment on your blog, but was rejected saying I was
> behind a proxy. Given that practically any one on a LAN is behind a proxy,
> this in practice prevents comments.
anything is "more secure" than anything else. We don't want to give
false hopes/impressions to managers, and we have to remember that part
of the reason for Django's security track record is because it's
"below the radar" of attackers. That could change at any time. Still,
security is an important consideration and I've included a bit on it
in the "final" version, which is up now.
Thanks all for your contributions.
Scot
Kenneth Gonsalves
> That's a tricky area - we have to be very careful about saying that
> anything is "more secure" than anything else. We don't want to give
> false hopes/impressions to managers, and we have to remember that part
> of the reason for Django's security track record is because it's
> "below the radar" of attackers.
>
debate comes up, most people take the view that if django was more widely
used, it would show up with more security holes. And I find it impossible to
counter this. I do also point out to plone vs drupal, but there again the
argument is the drupal is more widely used and hence has more observable
vulnerabilities. It does not sound logical.
Christophe Pettus
On Nov 15, 2009, at 5:10 PM, Kenneth Gonsalves wrote:
> I do also point out to plone vs drupal, but there again the
> argument is the drupal is more widely used and hence has more
> observable
> vulnerabilities. It does not sound logical.
software being widely adopted somehow creates new security
vulnerabilities in it. I believe the assumption is that all software
of a given level of complexity has roughly the same number of
vulnerabilities, either exposed or hidden. Thus, the more used a
piece of software, the more attention the bad guys give it, and thus
the more of those hidden security problems become exposed.
james_stevenson
now and Drupal as well. In fact, at my workplace (60-person web design/
development shop) I'm leading a similar charge to move us away from
Drupal development towards Django.
I took a look at your post and thought I'd add a few things:
1. It's not exactly correct to say Drupal isn't Object Oriented. Like
Django, some of Drupal is written in a typical procedural style, some
OOP. It's more accurate to say Drupal is less Object Oriented. More
here: http://drupal.org/node/547518 In any case I'm not sure it's a
huge selling point.
2. Same for MVC: Drupal does it...kinda. More here:
http://archivemati.ca/2006/01/21/drupal-as-a-mvc-framework/ I'd say
Django maintains a separation of concerns much better, though, and I'd
say this is a big selling point, unlike OOP
3. +10 on templates: Drupal templates are very frustrating. A single
page is usually generated by an elaborate nesting of templates. Let's
say you have a page that lists a bunch of nodes. You have a template
for the page, for the list, for node itself and maybe (with CCK)
individual node fields. This is a lot to keep track of and why there
are whole books written about Drupal templating. What's more, you
don't have enough control over markup. A lot of devs where I work feel
very frustrated when the lean, clean, semantic html mockups they
produce get completely torn up by the way Drupal works. Django almost
never forces any markup constraints on you. This allows front end dev
to proceed more or less parallel with back-end dev in Django, which
buys you a lot of time if you have teams that work that way. In
Drupal, the templating phase is intimately tied into the back end
development phase, partly because of the less-than-stellar separation
of concerns mentioned in #2 above. That's a slower way to work.
4. Drupal doesn't have an ORM, really. With you can get a mapping of
DB fields to a php object, so that say, the "title" DB column maps to
an object : $node->title, but that's not really an ORM in any sense
that I think of it.
5. Security. Django makes a lot of design decisions that make it hard
to write insecure code. Not impossible, but hard. Some attack vectors,
like SQL injection (and other input sanitization exploits) are pretty
much eliminated by Python's DB API and Django's ORM and Form
validation tools. This is not to say you couldn't create an exploit in
a Django app, but that you'd have to be trying to on purpose. They
also give you tools to prevent CSRF which were optional, but in newer
releases are being promoted to "required" in contrib.admin at least
(http://docs.djangoproject.com/en/dev/ref/contrib/csrf/ )
One of PHPs biggest failings re: security , IMHO, is they made it too
easy to do the wrong thing for far too long. This is improving, but I
think you still see this lax approach reflected in the large number of
Drupal exploits that have appeared and in the way many people don't
seem to take security as seriously in the PHP universe.
6. Deployment. I tend to think of Deployment as more than just
installing an app and for that reason, I think Drupal's deployment is
far inferior to Django's. It's relatively easy to set up a Lamp stack
and install Drupal on it. Django requires you to install Python,
Apache, your RDBMs, python drivers to connect to it, PIL (probably)
and mod_wsgi (Hopefully that's what you're using). These things
represent the baseline for installing an app, IMHO, and for people
without a *nix background, setting them up is harder than in Drupal
(although with debian and dpgk, it's not that bad). But to me,
deployment means more than installing a LAMP stack. Deployment means
packaging. PHP doesn't really have good package management tools.
Python does. Deployment means being able to run a test suite on your
install and know immediately if anything has broken: Django let's you
write tests for your app, Drupal does not. Deployment means being
able to maintain dev, staging and production environments in sync. In
Drupal this is very hard: one of my biggest complaints is that Drupal
is that it mixes application configuration and data in the DB so that
they are completely inextricable. This is a huge problem if, for
example, you want to migrate some new views from your staging
environment to your production environment. Deployment also means
upgrading: In Drupal you've got the upgrade treadmill and it sucks.
The more modules you have the more it sucks. Upgrades not infrequently
break things, and since you have no unit tests or functional tests,
there's no way to know if something broke without clicking around and
hoping you catch the problem. Django + Python give you:
+ package management (distutils, virtual_env, zc.buildout)
+ unit and functional tests
+ fabric to help deploy in multiple environments across the cluster
+ south to help you migrate schemas
+ a complete separation of data from everything else
My argument against Drupal boils down to 2 things: 1. It's doesn't
know if it want to be a CMS or a framework, and the confusion shows.
It's an OK CMS if your problem set matches it's capabilities. It's not
a good framework for the reasons mentioned above and more which many
commenters here have caught. 2. Drupal makes deployment of a real,
professional site (where less than 99.99% uptime is not an option)
very difficult and there doesn't seem to be anyone doing much about
it. This is a start http://groups.drupal.org/aegir-hosting-system
...but it's not enough.
Anyway, from someone who has been there, I feel your pain. We've done
a few parallel development projects @ my workplace to show Drupal vs.
Django and the results have been encouraging. For the kind of site we
often do, an average Drupal build means moderate to heavy template
customization, CCK and custom content types, 20 or so 3rd party
modules modules and 1 or 2 custom modules we write. If this is the
kind of site you're doing, Django is very likely a better fit.
Kenneth Gonsalves
I do not know how to counter it ;-)
Melvyn Sopacua
wrote:
You give it to someone else to proofread and it's likely he/she finds
a few more typos. The longer the letter, the more mistakes you'll
make (absolute), while the percentage might stay the same.
The more eyes look at it, the better your chances are that you will
send a flawless letter.
Now, the question arises whether a program is more secure if it has
more exposure (proofreaders) or less and a bit of both is true.
The more proofreaders the less chance a bug remains, yet since
exploiting the bug requires knowledge to be shared and/or
incorporated into attack software, the chance that *you* as a user
gets exploited through one of these bugs lessens.
Think of this as the difference between a cabin in the mountains,
no locks on the door and a 5 mile steep hike to get there, versus
a bank downtown. Obviously, the bank is more secure, yet it's
much less likely that someone will try and rob the cabin.
--
Melvyn Sopacua
Tom Evans
Mike Ramirez
How is it not logical? Product A is widely used, Product B is used less. Bad
Guy A. is smart enough to realize that product A if broken can be used to gain
him more presents because more users have it. This is because of the human
condition of laziness and the majority are not really paying attention to what
they are doing. This is a fact. If you're one that thinks about everything
they are doing, i.e. every litteral step yout take down the hall is carefully
planned. Then you are most likely going to avoid Bad Guy A, and be a
minority. I hardly meet people who do this, they just act without thinking.
Its illogical to think that everyone or the majority will not succumb to
laziness because this is our ideal goal as a society. Everything we build do
is to make our lives easier so we can be lazy without worry.
Mike
--
The chat program is in public domain. This is not the GNU public license.
If it breaks then you get to keep both pieces.
-- Copyright notice for the chat program
CLIFFORD ILKAY
> On Mon, Nov 16, 2009 at 5:25 AM, Melvyn Sopacua
> <msop...@warp10.thruhere.net <mailto:msop...@warp10.thruhere.net>> wrote:
>
> On Mon, 16 Nov 2009 08:53:26 +0530, Kenneth Gonsalves
skills and who knows English fluently is likely to have fewer spelling
mistakes and grammatical errors than someone who uses Google Translate
to translate even a short and simple report to English from some other
language.
--
Regards,
Clifford Ilkay
Dinamis
1419-3266 Yonge St.
Toronto, ON
Canada M4N 3P6
<http://dinamis.com>
+1 416-410-3326
Kenneth Gonsalves
> > it is precisely this assumption that does not seem logical to me. But
> > frankly I do not know how to counter it ;-)
> >
>
> How is it not logical? Product A is widely used, Product B is used less.
> Bad Guy A. is smart enough to realize that product A if broken can be
> used to gain him more presents because more users have it.
>
guys train their weapons on django it is going to be shot as full of holes as
drupal (or even phpbb). In which case why are the devels focussing so much of
their time trying to make the app safe and secure? Should they not be better
of lighting candles in the rain and praying that the bad guys radar doesn't
function? I personally am of the opinion that constant harping on safe
practices and not doing silly things like permitting code inside html (for
example) will create an inherently safer app - and the bad guys will
congregate elsewhere. After all bitbucket is big enough to be on their radar -
and it got hosed - although I hear that was an amazon problem, not a django
issue (could be wrong).
Mike Ramirez
> On Monday 16 Nov 2009 10:44:27 pm Mike Ramirez wrote:
> > > it is precisely this assumption that does not seem logical to me. But
> > > frankly I do not know how to counter it ;-)
> >
> > How is it not logical? Product A is widely used, Product B is used less.
> > Bad Guy A. is smart enough to realize that product A if broken can be
> > used to gain him more presents because more users have it.
>
> so if we follow your logic to the inevitable conclusion, the moment the bad
> guys train their weapons on django it is going to be shot as full of holes
> as drupal (or even phpbb).
No, I did say 'product A if broken' -- keyword being if.
But Bad Guy A will try everything to put holes in django, and whats worse is
that he'll have a different perspective than you or I and might see something
that we didn't or someone else didn't and walla, we have a hole. We all know
there is potential for security problems in well established software that
aren't discovered today, because of this and human error in future revisions
and changes. Now am I saying the django devs are lazy or incompetent? If I
really believed that I would be using something else and calling you all
idiots for using a badly developed piece of software. No, I'm calling them
human, if they aren't human, then well aliens are finally proven.
> In which case why are the devels focussing so
> much of their time trying to make the app safe and secure?
> Should they not
> be better of lighting candles in the rain and praying that the bad guys
> radar doesn't function?
> I personally am of the opinion that constant
> harping on safe practices and not doing silly things like permitting code
> inside html (for example) will create an inherently safer app - and the
> bad guys will congregate elsewhere. After all bitbucket is big enough to
> be on their radar - and it got hosed - although I hear that was an amazon
> problem, not a django issue (could be wrong).
>
Open source helps this a lot, lets not forget this.
PHP application problems that we see are bad coding techniques, mostly in
older software that's been coded since php4 and updated for later versions of
php, which says to me that they didn't take into account half of the known
vulns today because they weren't known yesterday.
We also have to take into account all the ways a user might try to use our
software, because they are lazy and not always vigilent, which is the main
area that bad guys prey on. For example, redirecting after a login to break
the back button so the next user can't get the login form details. It's hard
to speculate everything a person will do, too many individuals with different
view points. Even using large test groups it's hard be 100% correct 100% of
the time.
In the end all you can do is prevent what is known today, hope that you've
covered for tomorrow.
Mike
--
Red Hat Unveils New Ad Campaign
Linux distributor Red Hat has announced plans for a $650,000 ad campaign. The
ads will appear on several major newspapers as well as on a few selected
websites. "These ads will be targetted towards Windows users who are fed up
but
aren't aware of any OS alternatives," a Red Hat spokesman said. "We feel that
there is a large audience for this."
One of the ads will be a half page spread showing two computers side-by-side:
a
Wintel and a Linux box. The title asks "Is your operating system ready for the
year 2000?" Both computers have a calendar/clock display showing. The Windows
box shows "12:00:01AM -- January 1, 1900" while the Linux box shows
"12:00:01AM
-- January 1, 2000". The tagline at the bottom says "Linux -- a century ahead
of the competition."
Kenneth Gonsalves
general, I put safe code as number one in the list. And I personally am
confident (after seeing the work done in the last 5 years in django, python and
postgresql) that this will remain. Holes will appear - but I have a feeling
they will be few and far between and patched fast too. This is what I tell
people.
Mike Ramirez
> anyway, in pitching for django (in particular), python and postgresql in
> general, I put safe code as number one in the list. And I personally am
> confident (after seeing the work done in the last 5 years in django, python
> and postgresql) that this will remain. Holes will appear - but I have a
> feeling they will be few and far between and patched fast too. This is
> what I tell people.
>
Agreed all the way across.
One of the reasons I use django is because it's hard to shoot yourself in the
foot and by making sure the lower level apis is where most of the important
security features we all want live, and makes customizing our own special ones
easy. Python, well it's the love of the language, postgresql cause of the
features it has, has had them a lot longer than mysql and a nicer memory
footprint.
And the latter part of your statement is exactly why we all think that open
source software is more secure than propietary software and swear by it.
Mike
--
Talkers are no good doers.
-- William Shakespeare, "Henry VI"
Melvyn Sopacua
wrote:
>> > it is precisely this assumption that does not seem logical to me. But
>> > frankly I do not know how to counter it ;-)
>> >
>>
>> How is it not logical? Product A is widely used, Product B is used
less.
>> Bad Guy A. is smart enough to realize that product A if broken can be
>> used to gain him more presents because more users have it.
>>
>
> so if we follow your logic to the inevitable conclusion, the moment the
bad
>
> guys train their weapons on django it is going to be shot as full of
holes
> as
> drupal (or even phpbb).
There are definitely design decisions you can make to prevent holes, one of
the obvious ones is to validate user input.
There are two assumptions made in this discussion that are not absolute
truths:
1) If an application receives more attention from critical eyes, it is more
secure as it lessens the chance that mistakes have been left in
releases.
However, this doesn't exclude the possibility that there are no mistakes
to be found to begin with or even that these eyes find them or that they
are practical security risks. MD5 is a good example. It has been secure
for many years, because the computational power wasn't there to make
any practical attack vectors.
2) If something is used more, it becomes more of a target. This still
doesn't
exclude the possibility that an attacker will never find your machine.
--
Melvyn Sopacua
andreas schmid
sry i dont want to be unkind but could you please turn the mail delivery
confirmation off when you write to a list?!
thx
Angel Cruz
This is true of most things that get hacked (remember when DirectTV had pirated boxes all over the place where one can purchase on craigslist or where a weekend intermittent hacker can easily get instructions on a website? DirectTV got more ingenious playing the cat and mouse game with hackers with the result of DirectTV now having a more secure system. The same with Game Console discs being copied. Try and see how easy it is to copy and have a playable Playstation 3 Game (where designers responded to pirating by now embedding chips on the BluRay disc)).
The key to the whole situation is if the product is designed well to respond. Having seen to much php spaghetti mess in my career, I think Django and Python are well designed for such things.
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=.