Re: Security updates realized by new releases, case for backports?
Hi all,
long time reader, first time responder.
IMHO this backporting, support of version 0.001 etc. etc. should be
dropped. Linux is already the mess it is with all the developer
fragmentation. Don't like the way the file menu is? Fork the program and
take a couple of the best developers with you, teaching them to hate the
people they used to work with and you are done. It's the GPL way!
Security fixes should NOT be patches affecting old code, but instead a
security fix found by someone should be pushed upstream to be
incorporated in a newer upstream release. I understand the need to
support extremely old versions of software. After all it makes a lot
more sense to have 10 developers patching old code so that person X can
run Linux on his old Pentium (1) machine, than to spend the 400 euros to
get a brand new laptop that's able to run newer software versions. Never
mind the used computers available at better prices. Spending your money
is always a bad thing, therefore developers should invest their time
scratching their head on how to support your outdated software. Do I
really need a sarcasm disclaimer in this post? I guess so, since this IS
the facebook generation. This paragraph is pure sarcasm. In no way
should developers be forced to maintain old code.
The biggest problem with the way things work right now, is the
misunderstood meaning of the GPL. The GPL is not there so that we can
have 100 text processors and 20 browsers. If you are rushing to type a
response to this sentence, please stop and go re-read the GPL. This is
not the intended "software freedom". It's there so that if a text
processor is stopped being developed by its maintainer, a new maintainer
can take over. "What's this have to do with security updates?" I hear
you ask. Having 1 text processor to properly maintain instead of 100
makes it a lot easier to incorporate security updates.
Fixing something that's broken (open source software in general in this
case) means firstly identifying that a problem exists (too much software
performing the same function), planning corrective measures (code merges
to incorporate the best strengths of all text processing software into
one, for example. Please leave vi out of talks, the faster we get rid of
it, the better for humanity), implementing the corrective measures
(getting round the fact that no matter who you are, you want to be
famous, so your software is always the best and should be considered the
end all be all software for its intended purpose), making the community
more involved in testing the corrective measures (having exactly 2
versions of each software, includes debian in general: upcoming,current)
so code changes get tested faster, and finally releasing a new version.
Please see paragraph below.
---Small break here--- Correct interpretation of the two version
approach: Upcoming: 99 security fixes, 1 new feature. Current: Imagine
an upcoming release after a new upcoming is released. No security fixes,
no new features. Temporary stepping stone for when "it" hits the fan.
Should NOT be considered a "long term release". It's only there because
Mr. X decided to remove the "Open" functionality from the file menu,
which broke the software for a lot of people. Mr. Y is already working
on a fix, to be incorporated in the new Upcoming. ---End of break---
Having the correct versioning scheme (assuming (never assume) that the
developers have since reading "implementing the corrective measures"
above realised they need to embrace the community and not code something
on their own without asking anyone, this is directed at Mozilla) allows
me, as a testing user to check for a new version, say "hey, a new
version is about to come out. Oh goody it fixes all those bugs. I'll
give it a try on my testing machine to make sure nothing is broken, then
contact the developers saying "tested today. no problems found" so they
can release it faster to all the rest".
A new current release means to a regular user a new version for his/her
software. Correct community spirit dictates that you should update to a
new version to fix bugs and improve security. The user will then say
"ah, I'll check to see if someone reported anything broken on the new
release.... nope nothing, guess I'll upgrade" and the whole cycle is
completed. Yes I know deb packages need to be created first, repackaging
something is a lot easier than patching it. If you think I'm wrong about
this, please re-read the last 2 paragraphs 42 times, copy them down on
paper (handwritten) 42 times, scan them 42 times, and re-read the
scanned images 42 times. You missed the whole, nothing breaks part. A
new version repackaging should mean (to ANY distro's package
maintainers) a simple repackaging. No patching needed. Just take this
code, compile it, package it, and put it out for distribution. Yes I'm
aware of the changes needed to fully support all distros, but please go
watch "Why Linux sucks" first and then "Why Linux doesn't suck"
afterwards. Then post a reply citing parts from the presentations on
your reasoning why we have different distributions. If you are already
typing a "You know nothing about Linux, it's all about freedom" all hope
is lost for you at this point. Please seek professional help immediately.
This reply is an attempt to bridge the wide gap the GPL has created
between actual users, theoretical users, actual developers and
theoretical developers. It should not be considered a rant, a
disapproval of any software (except vi), maintainers (except vi's),
developers (except vi's) and users (they should realize by now that
actually typing something and getting it to show up on the screen is not
vi's intended use), unless stated directly (this means you vi developers).
A preemptive reply to those trying to injure their selves furiously
typing up a reply. I fully understand that the problems mentioned in
this reply will never be fixed, since people's mentality dictates that
they should never say "hey, you know what, this guy is right". The best
thing we can do right now is trying to get people to upgrade to a
current release with backport versions installed, as mentioned
previously. Gives the most up-to-date software. Maybe having new
installs default to this behaviour or implementing the backports
directly into the stable release, but that will take at least 9 years to
implement (assuming (never assume) each and every single developer gets
involved in this, 16 years if even 1 stays home sleeping)
Reply to: