6 ms·

The author essentially states that he just wants to build a website and "be done with it" and never have to touch it again. He seems to acquiesce that security

The author essentially states that he just wants to build a website and "be done with it" and never have to touch it again. He seems to acquiesce that security updates are necessary, and I suppose his greatest complaint is that old versions of software (eg python 2, django 1.11) are no longer receiving security updates, which necessitates him to update to python3 and django 2. I feel that. But on the other hand, without trying to sound too mean: what exactly does he expect? Is he also complaining that "Windows's goals are not our goals" because Microsoft stopped supporting Windows XP? Does he complain that Ubuntu version 11 is no longer getting updates? Java SE 9? For better or for worse, this is simply how software works. Things have to be updated. Unless you want to eschew security updates (which is not smart), there is never such a thing as a fully "finished" product. Software maintenance is part of the job responsibilities. This post is particularly targeted at Django, but I feel that it applies to almost every web framework or piece of software, and I'm afraid this is unfairly casting Django in a bad light. I'm also afraid that we're going to see a lot more posts like this in the second half of 2019 as we move towards python 2's EOL date.

reaperducer 7y ago
The author acknowledges that some maintenance is necessary, especially for security updates. My reading of it was that his complaint is that in keeping up with the security upgrades, Django breaks other things. This is true of a number of frameworks I've worked with. If you want security, you have to constantly stay on top of the other changes that the framework makers implement, often "fixing" things that aren't broken, removing features, or changing the way things work. I don't know how practical it is, but it would be nice to see a framework where security updates and feature updates were separate things. One could keep one's site secure through updates without having to debug formerly working things every few months.
- txcwpalpha 7y ago
  > I don't know how practical it is, but it would be nice to see a framework where security updates and feature updates were separate things. One could keep one's site secure through updates without having to debug formerly working things every few months. This is more or less what an LTS release is. The problem as I see it is that, as the codebases diverge, it becomes more and more work for the dev teams to support what is now essentially two different products. And especially in the open source world, it seems futile to expect unpaid or low-paid contributors to continue to do extra work simply because someone else's dev team doesn't want to put in the work doing updates.
- aeternus 7y ago
  Unfortunately it's not practical because the test matrix explodes. They would have to develop and test every security update on every previous version which is quite costly, especially if the codebase has diverged. The best strategy is probably what many large distros like Ubuntu have adopted: designate only a few long term support (LTS) versions, and commit to supporting only those versions.
  - 1337shadow 7y ago
    The only matrix i support now is latest release and master, not even LTS anymore because it quickly gets too old. I consider not updating my software to be tech debt: something I must do before adding a new feature. In return, my software is always up to date and ready for new features, except once in a year when I do the said upgrades.
- orf 7y ago
  > My reading of it was that his complaint is that in keeping up with the security upgrades, Django breaks other things. Django takes great pains to ensure that this isn't true. We don't backport anything other than bugfixes and security updates to releases. It's not like we suddenly introduce a new feature into a previous release that's backwards incompatible with your current code. If you're on the LTS release then you can be happy in upgrading Django to the latest point release with all the latest fixes. And the Django project has finite resources. It cannot backport security fixes indefinitely which is why we have the LTS release in the first place. If you want something stable: sit on that for several years at a time, or spend your time backporting any security fixes yourselves. Unfortunately software is a moving target, but Django tries to make it easy to upgrade from one LTS release to the next. The upgrading difficulty often comes from third party packages, which is hard to avoid in any framework or language.
deleted 7y ago
[deleted]
svnpenn 7y ago
Yep. I was interested in the post as I've always felt Django is python software "done right". I stopped reading when they started complaining about python 3. Python 3 has been out for over 10 years now. Did OP really think Django was going to use python 2 forever? Frankly that's a selfish outlook, and I'd go as far as saying it's a cancer of software development. Backward compatibility needs to be a thing, but not forever. Things need to be deprecated eventually.
- faitswulff 7y ago
  > Backward compatibility needs to be a thing, but not forever. Things need to be deprecated eventually. That might not need to be the case. I guess we'll see: one of Rust's tenets is perpetual backwards compatibility. New features (and potential breaking changes) are opt-in with a per project configuration setting.
  - k__ 7y ago
    Doesn't JavaScript do it the same way?
- philwelch 7y ago
  > Backward compatibility needs to be a thing, but not forever. Things need to be deprecated eventually. This mentality is the true cancer of software development IMO. Can you imagine the utter insanity and chaos if any other form of engineering worked this way? Programming languages are like protocols and standards: they are a common platform that people build on; simply deprecating them with no plan for backwards compatibility requires everything to be rebuilt, which represents a tremendous cost. Sometimes these changes are worth it, but outside of software, these are usually once-in-a-lifetime changes. I can't think of any fundamental technical change between Python 2 and Python 3 that make this scale of disruption worthwhile. If the maintainers of Python don't want to maintain Python 2 anymore, they are completely free to make that decision, but it's a decision worth criticizing and complaining about. It is not a good thing for all software developers to be forced to rebuild the same sand castles every time the tide goes back out.
orev 7y ago
> For better or for worse, this is simply how software works. This post is more or less a lament about that fact, not necessarily a complaint or gripe. Chris is a Sysadmin, and there’s a big difference in perspective between this and a developer of an app whose reason for being is THE APP. A Sysadmin needs to provide a bunch of services that are not the core revenue generator, and multiples of them, meaning that every internal app has this same kind of updating overhead. It becomes tiresome to have to keep all of them up to date all the time. We know that is a fact of life, but not all facts of life are fun and people like to blow off steam about that.
mikekchar 7y ago
There is a saying amongst growers of bonsai trees: A tree isn't "finished" until it is dead. In other words, it keeps growing and so you constantly have to keep working on it. You can't just think of a design, prune the tree and then say, "Oh, I'm done! Let it stay like this forever". Software is exactly the same. Your needs may never changes, but the world around you does. You have no control of that and so you must constantly maintain your code -- even if there are no changes that you want. It's not just Python or django. It's hasn't even possible to compile Ruby 1.8.7 with recent versions of GCC for at least a year (don't ask me how I know... :-P ). Starting a software project -- any project -- is a long term commitment. If you want it to survive, you need to care for it.
verisimilitudes 7y ago
>I feel that. But on the other hand, without trying to sound too mean: what exactly does he expect? It's not unreasonable to expect to be finished with software. >For better or for worse, this is simply how software works. This is false. The author has already fallen into this trap by using a programming language which is also subject to this, however. >Things have to be updated. Unless you want to eschew security updates (which is not smart), there is never such a thing as a fully "finished" product. There is such a thing as finished software, but I can understand why something such as a WWW framework wouldn't be. The WWW is ugly and misguided and inspires disgusting systems to accomodate it. >Software maintenance is part of the job responsibilities. When you have a project with no real design goals, apparently, I agree. Otherwise, you can remark on how a program achieves its goals and so is finished. That doesn't stop minor improvements or reworkings, but those would be entirely unnecessary. >This post is particularly targeted at Django, but I feel that it applies to almost every web framework or piece of software I agree, because, again, the WWW is a disgusting tangle of systems that encourages similarly disgusting systems. One language I enjoy is Common Lisp. The standard hasn't changed in decades and there are many implementations. I can finish a library and then never need to touch it again. Python can't compare.

reaperducer 7y ago

The author acknowledges that some maintenance is necessary, especially for security updates. My reading of it was that his complaint is that in keeping up with the security upgrades, Django breaks other things. This is true of a number of frameworks I've worked with. If you want security, you have to constantly stay on top of the other changes that the framework makers implement, often "fixing" things that aren't broken, removing features, or changing the way things work. I don't know how practical it is, but it would be nice to see a framework where security updates and feature updates were separate things. One could keep one's site secure through updates without having to debug formerly working things every few months.

txcwpalpha 7y ago
> I don't know how practical it is, but it would be nice to see a framework where security updates and feature updates were separate things. One could keep one's site secure through updates without having to debug formerly working things every few months. This is more or less what an LTS release is. The problem as I see it is that, as the codebases diverge, it becomes more and more work for the dev teams to support what is now essentially two different products. And especially in the open source world, it seems futile to expect unpaid or low-paid contributors to continue to do extra work simply because someone else's dev team doesn't want to put in the work doing updates.
aeternus 7y ago
Unfortunately it's not practical because the test matrix explodes. They would have to develop and test every security update on every previous version which is quite costly, especially if the codebase has diverged. The best strategy is probably what many large distros like Ubuntu have adopted: designate only a few long term support (LTS) versions, and commit to supporting only those versions.
- 1337shadow 7y ago
  The only matrix i support now is latest release and master, not even LTS anymore because it quickly gets too old. I consider not updating my software to be tech debt: something I must do before adding a new feature. In return, my software is always up to date and ready for new features, except once in a year when I do the said upgrades.
orf 7y ago
> My reading of it was that his complaint is that in keeping up with the security upgrades, Django breaks other things. Django takes great pains to ensure that this isn't true. We don't backport anything other than bugfixes and security updates to releases. It's not like we suddenly introduce a new feature into a previous release that's backwards incompatible with your current code. If you're on the LTS release then you can be happy in upgrading Django to the latest point release with all the latest fixes. And the Django project has finite resources. It cannot backport security fixes indefinitely which is why we have the LTS release in the first place. If you want something stable: sit on that for several years at a time, or spend your time backporting any security fixes yourselves. Unfortunately software is a moving target, but Django tries to make it easy to upgrade from one LTS release to the next. The upgrading difficulty often comes from third party packages, which is hard to avoid in any framework or language.

deleted 7y ago

[deleted]

svnpenn 7y ago

Yep. I was interested in the post as I've always felt Django is python software "done right". I stopped reading when they started complaining about python 3. Python 3 has been out for over 10 years now. Did OP really think Django was going to use python 2 forever? Frankly that's a selfish outlook, and I'd go as far as saying it's a cancer of software development. Backward compatibility needs to be a thing, but not forever. Things need to be deprecated eventually.

faitswulff 7y ago
> Backward compatibility needs to be a thing, but not forever. Things need to be deprecated eventually. That might not need to be the case. I guess we'll see: one of Rust's tenets is perpetual backwards compatibility. New features (and potential breaking changes) are opt-in with a per project configuration setting.
- k__ 7y ago
  Doesn't JavaScript do it the same way?
philwelch 7y ago
> Backward compatibility needs to be a thing, but not forever. Things need to be deprecated eventually. This mentality is the true cancer of software development IMO. Can you imagine the utter insanity and chaos if any other form of engineering worked this way? Programming languages are like protocols and standards: they are a common platform that people build on; simply deprecating them with no plan for backwards compatibility requires everything to be rebuilt, which represents a tremendous cost. Sometimes these changes are worth it, but outside of software, these are usually once-in-a-lifetime changes. I can't think of any fundamental technical change between Python 2 and Python 3 that make this scale of disruption worthwhile. If the maintainers of Python don't want to maintain Python 2 anymore, they are completely free to make that decision, but it's a decision worth criticizing and complaining about. It is not a good thing for all software developers to be forced to rebuild the same sand castles every time the tide goes back out.

orev 7y ago

> For better or for worse, this is simply how software works. This post is more or less a lament about that fact, not necessarily a complaint or gripe. Chris is a Sysadmin, and there’s a big difference in perspective between this and a developer of an app whose reason for being is THE APP. A Sysadmin needs to provide a bunch of services that are not the core revenue generator, and multiples of them, meaning that every internal app has this same kind of updating overhead. It becomes tiresome to have to keep all of them up to date all the time. We know that is a fact of life, but not all facts of life are fun and people like to blow off steam about that.

mikekchar 7y ago

There is a saying amongst growers of bonsai trees: A tree isn't "finished" until it is dead. In other words, it keeps growing and so you constantly have to keep working on it. You can't just think of a design, prune the tree and then say, "Oh, I'm done! Let it stay like this forever". Software is exactly the same. Your needs may never changes, but the world around you does. You have no control of that and so you must constantly maintain your code -- even if there are no changes that you want. It's not just Python or django. It's hasn't even possible to compile Ruby 1.8.7 with recent versions of GCC for at least a year (don't ask me how I know... :-P ). Starting a software project -- any project -- is a long term commitment. If you want it to survive, you need to care for it.

verisimilitudes 7y ago

>I feel that. But on the other hand, without trying to sound too mean: what exactly does he expect? It's not unreasonable to expect to be finished with software. >For better or for worse, this is simply how software works. This is false. The author has already fallen into this trap by using a programming language which is also subject to this, however. >Things have to be updated. Unless you want to eschew security updates (which is not smart), there is never such a thing as a fully "finished" product. There is such a thing as finished software, but I can understand why something such as a WWW framework wouldn't be. The WWW is ugly and misguided and inspires disgusting systems to accomodate it. >Software maintenance is part of the job responsibilities. When you have a project with no real design goals, apparently, I agree. Otherwise, you can remark on how a program achieves its goals and so is finished. That doesn't stop minor improvements or reworkings, but those would be entirely unnecessary. >This post is particularly targeted at Django, but I feel that it applies to almost every web framework or piece of software I agree, because, again, the WWW is a disgusting tangle of systems that encourages similarly disgusting systems. One language I enjoy is Common Lisp. The standard hasn't changed in decades and there are many implementations. I can finish a library and then never need to touch it again. Python can't compare.