Daniel Rahn <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sat, 05 Apr 2008 10:20:51 +0200:
> Not everybody recompiles half of the distribution day after day. What, not everyone wants to run Gentoo as I do? Why, I'd have never guessed! =8^) (OT but... OTOH, after my recent upgrade to dual-core Opteron 290s on my dual Opteron box, so quad-core, I realized that for most stuff, compile time is now almost trivial, compared to the other stuff, figuring out what's new, config, etc, that comes along with installs/upgrades and that people have to do regardless of whether they use a binary or source based distribution. As a result of this personal experience, I'm now convinced that in a few years, a couple Moore's law upgrade cycles, when this sort of machine is no longer a monster but in fact rather normal, some source based distribution, probably /not/ Gentoo as it's too power-user oriented, but someone, could easily break into the top three distribution list. Imagine if you will, with compile time no longer a major factor, people will choose their distribution based on the usual things they choose it now on, packages available, support, ease of use in general, quality and ease of use of automated config tools, etc. Source based does have a few advantages as does binary, but for most today the compile time factor vastly outweighs any other consideration. When that's no longer the case other factors will be a greater influence, and while source based will be stronger in some areas and weaker in others, it'll be those factors influencing the decision, not source vs binary or associated compile-time worries directly. What a difference that could make!) > There are people that just _use_ the machine and require a bugfix once > in a while. So if the distribution is still maintained, I don't see why > a bugfix in svn should break compatibility. Agreed. > And after all, glib changed the API, not PAN. One project ignoring > unwritten rules (never change the API without changing the major > release) should not make other projects follow the same path. Absolutely right! There are times an API change is useful or necessary, but other things depend on them (sort of the definition of API, right?) so it shouldn't be willy-nilly, and when they occur, a clear break, traditionally indicated by a major version increment, should be part of the process. All this trouble with glib for a minor version increment... Why? Just... why? What else is there to say? -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
