Richard Lynch wrote:
This is Computer Software philosophical musing, not specifically related
to just PHP, but applicable to PHP and, well, all other OpenSource
software...
As I sit here surrounded by machines (physically and virtually) and
realizing that while I've got most of them on "auto-update" as much as I
can, or I've foisted off the updating on somebody else (for $$$) because I
just don't *WANT* to be a SysAdmin...
I'm still left with a lot of hours I'd have to invest to really be as
"current" as I'd like to be.
Let's take RedHat and other OSes, for example, only because I don't want
this to devolve into the "what version of PHP should I use" thread that
would be a hot button here. [Not that RedHat and or its versions aren't
almost as hot, but...]
No kidding! The way that they switched their codebase was, erm,
interesting to say the least? I looked at Red Hat about 1.5 years ago
and it took me a while to realize that Fedora Core was the free /
development branch of their OS. And the prospect of using a box that
never makes it out of "development" is, um, a reason to invest in Rolaids :)
I've got RedHat 8, RedHat 9, FC2, and FC3 on different machines here and
at client's sites.
Oh, and Win XP Home, just for fun, for testing stupid IE bugs.
I'd love to just move them all to FC3 (4 now?) but it would really be
painful, and a lot more hours than I have available.
Now, the thing is, it's finally gotten to the point where I'm willing to
let the OS authors/maintainers (RedHat) update my box for me, because,
with the current arms race in viruses and whatnot, that's got to be better
than my inability to stay on top of things, even if occasionally it breaks
something that actually worked before.
Yes it's an unfortunate trade off, but not so bad if you Keep It Simple
Stupid (tm). Most of the patches that get released to the wild (i.e.
the stuff that you get if you don't closely watch any internals@ lists)
have been tested for the OBVIOUS problems. It's the edge cases that
cause the most bugs...
My philosophical question is:
Why can't the damn things just have an easy one-click button to go from
major version to major version, or if I'm willing to turn over control of
the OS versioning to RedHat (or whomever) just do it automatically?
Okay, I can accept that for Microsoft and other proprietary software,
that's a non-option, because they WANT to force you to BUY the new
version, though with their new subscription model... Well, let's not get
into THAT argument either. Forget the Windows box.
But that's hard to do with my W2K workstation... with that pompous
sound that blares out of the speakers every time I reboot! ;)
In the past, I've been told that the various pieces of software version
control and tracking means that you need the "clean break" of a major
release to keep sanity in versions.
I think that was true then, but is it really true now?
I would tend to say: yes. Take PHP for example. There are a lot of
Extensions floating out there (mostly in PECL) which rely heavily on
internal function calls / behaviors. So if the maintainers of the PHP
project decide to do something so fundamentally different that it's
likely to break, like, everything... well then every extension out there
needs to be recoded (and tested) or else it's going to break.
There are currently two issues on the PHP internal list that directly
affect this question of yours: Unicode and Module Dependencies.
As we all know (or should know) PHP lacks proper Unicode support. Perl,
Java, and a whole slew of others already have this support, but PHP
("the language of the web?") doesn't. So there is work underway to fix
this in the default distribution (I've heard maybe around PHP 5.5), but
let's face it: this is going to break almost everything. Strings are
the lifeblood of web applications and the addition of Unicode strings is
going to require a lot of extensions to be upgraded. An excellent
summary of this situation can be found here:
http://www.gravitonic.com/downloads/talks/intlphpcon2005/php_unicode.pdf
So clearly our extension authors need to get the word and upgrade their
packages. A lot of them probably will make the changes for PHP 5.5 (or
whatever version Unicode comes out in), but some might not. So if
Redhat comes in and upgrades your version of PHP (even if they're good
enough that they upgrade all of the extensions too!) then you're going
to have an application that doesn't work because your extensions don't
support Unicode.
Now we move on to another discussion on the internals@ list. Someone
(Jani?) mentioned they had started work on a patch for module
dependencies. The proposal is still being worked on, e.g. where do we
do the checking so that PHP startup doesn't slow down too dramatically?
However, if the module lists dependencies properly... and the parent
modules (e.g. PHP core) correctly indicate BC breaks... then we might
have something that would be "auto-update safe".
I mean, with all these fancy RPM/apt-get/cvs/svn thingies floating around,
and all the version control already inherent to those processes, and the
sheer amount of data being tracked by that...
Would it really break the bank to just have the OS go from major release
to major release without my spending days of my time shlepping data around
and dinking around with re-boots and CDRs and hard drives and whatnot?
If you're talking about literally breaking the bank... well, for
subscription-based companies I bet that an auto-updating OS would be "A
Good Thing." Because you're already sold on the new product (it got
updated to your machine for you!) and it's an easier sell to convince
you to keep your support contract for the new product.
From a technical perspective though... I just think there are too many
dependency nightmares for Redhat to deal with. :-/ Maybe I'm just not
aware of how the whole RPM thingy works, but I'm guessing that whoever
writes it doesn't check external libraries that PHP might depend on (or
libraries that are built on top of PHP for that matter).
I know a lot of you guys actually ENJOY that kind of stuff, and playing
with the new distro is your idea of a Good Time.
But is that what Joe Sixpack and Betsy Buick really want?
Not *this* Joe Sixpack. I gladly welcome auto-updating programs that
don't break BC. And often times I'll bite the bullet and break BC if
there's new functionality that proves worth the time and effort.
[thinks... perhaps I need to look into better version control for my own
code...]
Are we really presenting the average user with the BEST software when they
can only use it a year or two before they have to spend a day fraught with
stress and wondering if their hardware and data will survive, just so they
can be something like remotely "current"?
How does that bode for our long-term prospects in today's arms race with
viruses and trojans and other Bad Guys?
We *KNOW* too many average users simply aren't going to upgrade, because
of that pain.
We *KNOW* that telling them they need to be current doesn't cut it.
Hell, even *WE* can't stay current on every box. I know I'm not alone here.
Unfortunately, no you're not alone.
Why don't we actually solve this one, for those who are willing to let the
OS upgrade itself, with the technological "leap" of just keeping it
CURRENT even if it's from 4.4.13 to 5.0?
Am I just being crotchety here, or what? :-)
No... it's a pretty serious problem. Because on the one hand your
current servers that use PHP 4.x are going to run into problems when you
switch over to PHP5. This is especially true for all those
fancy-schmancy OOP coders. This has been quite a hot topic on the
internals@ list as well. However, I recently saw an excellent
suggestion for how to write PHP4 OOP that is PHP5 friendly:
http://marc.theaimsgroup.com/?l=php-dev&m=111887357126698&w=2
Andrey's usage of the syntax /* PHP5 */& to search and replace any
object reference will help, but then again you also need to work on
cloning objects where you expected copies instead of references. So
maybe you add something like:
<?php
/* PHP5 clone( */ $some_object_that_needs_to_be_copied /* ) */
?>
One other option that I've toyed around with is to switch over to a
PHP5.x binary, but have objects passed as copies (like in PHP4) instead
of by reference (the PHP5 default).
http://php.net/manual/en/ini.core.php#ini.zend.ze1-compatibility-mode
<?php
ini_set('zend.ze1_compatibility_mode', 1);
/** Rest of code goes here */
?>
This should allow you time to fix all of your E_STRICT problems while
still running code that behaves like PHP4.
--
NEW? | http://www.catb.org/~esr/faqs/smart-questions.html
STFA | http://marc.theaimsgroup.com/?l=php-general&w=2
STFM | http://php.net/manual/en/index.php
STFW | http://www.google.com/search?q=php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
