[the responses in the latter parts of this are more relevant to PHP-general than the first half... Sorry... Skim down for "PHP-GENERAL STUFF"]
On Thu, June 16, 2005 7:28 am, Jason Barnett said: > Richard Lynch wrote: >> 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 > :) It's not that bad, in Truth, only in Marketing. See, they want to SELL the RedHat name to Enterprise for big money. But they quickly found (after a disastrous attempt to only have Enterprise) that they *need* the OpenSource community to develop and, more importantly QA the new versions. In Truth, an FCx box is really just the same as the old RedHat (Mandrake, whatever) boxes. You can, if you want, be risky and add in non-recommended bleeding edge packages... But it doesn't do that unless you push it. > But that's hard to do with my W2K workstation... with that pompous > sound that blares out of the speakers every time I reboot! ;) Errrm. Just turn off all the Sounds in the Control Panel? I haven't heard that annoying sound in AGES. PHP-GENERAL STUFF > 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. I meant the intellectual/open-source "bank" of Developers and their time. I don't really care about the subscription-based OS companies, frankly. I wouldn't expect them to change on this, as it's revenue they can't pass up to *also* charge extra fees every time a major upgrade happens... Or they'll just be "forced" to make incompatible hardware changes, and make up the money there. Most likely both, if history is any indicator. :-^ > 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 don't know, for sure, but I think there's a *LOT* of dependency checking in RPMs... At least, I've failed to install RPMs I needed, because of dependency failures. Over-riding those safeties generally led to glitches, at best, or downright un-usable systems. Especially that glibc thing. Man, that really sucked. [Yes, I know why they did what they did. It *still* sucked from the user perspective.] And I believe the reason the PHP RPMs tend to lag so much is specifically so the RPM-makers can hammer out everything to make the various Modules of PHP they feel they need to have in the RPM still "work" and they even QA them a fair amount. Maybe the RPM-makers don't dig down into the guts of PHP Modules as much as they should in an automated way. Or maybe they do. They *must* be doing something somewhere along the line, even if it's making a whole new source RPM and throwing out any Modules (by hand) that don't work, and if you need PHP Module X, and had PHP Module X before, you either lose out, or you don't get the new RPM because it "knows" it won't work. Either way, though, it seems to me that whatever it is all these systems/people/processes are doing in that regard, it isn't going to be any WORSE off to just jump from PHP 4.x to PHP 5.0 for *most* people, or at least to give them that option in a one-click, ez-rollback way. And to do the same for the OS, which is where, for me at least, I really need this change-over to "just work" Ideally, all the "big" PHP packages out there (even the ones I won't use due to their security history) that everybody uses is already working on having a PHP 5 version to roll out -- even if that means they just slapped an ini-setting line at the top of their code to be PHP4 BC until they really fix it. >> 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...] I've only been intending to set up my own CVS server for my own code for ... Errr, for so long I've decided to go with SVN if I ever actually get off my butt and do it. I think that would help me go a long way to making better software for myself, though it's no magic bullet, of course. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
