Re: Selection of roadmap for i386 platform End-of-Life (EOL)

[Chris Turner <c.turner@xxxxxxxxxxxxxxxxxxx>]

On 05/01/13 03:07, Francois Tigeot wrote:
> On Fri, Apr 26, 2013 at 08:34:59AM +0200, Francois Tigeot wrote:
>> On Wed, Apr 17, 2013 at 01:15:34PM +0200, John Marino wrote:
>>>
>> I'd like to have an estimate of how many i386 users do we still have.
>>
>> There are surely download statistics for the various ISO images and binary
>> packages.
>
> Since there were no reliable ones, I'll use dports package downloads
> numbers on mirror-master.dragonflybsd.org to cook up some.

I (for one) wouldn't show up here since I'm updating the system
from source locally, and building packages from source manually.

> In the meantime, here are some numbers from a few Linux distributions.
...
> i386 usage is decreasing slowly but surely; approximately 80% of downloaded
> packages are amd64 versions at the moment.
> Most remaining i386 users are also using amd64-compatible CPUs.

I personally think the important part is not so much what percentage
of users, as is 'system capabilities' vs 'maintainership overhead'.

For example, we keep telnet server/client in base - it doesn't
really 'cost anything' to keep it, but (aside from historical integrity)
it provides an occasionally useful feature/capability with low
maintainence overhead, despite a very low percent of active users.

Yes this is much lower maintenance overhead than a CPU architecture.

Of course counts of user base might help weigh the utility of the feature,
this to me seems secondary to 'core features' vs 'maintainership'.

E.g I'd conceptualize this something like:

(feature-usefulness * userbase) / maintenance-overhead => worthyness

Again, not being a curmudgeon, and not stepping up for maintainership,
but I think it's important to weigh things correctly based on software/system
requirements and not *only* follow mainline hardware trends -
while at the same time not being bogged down with supporting 'cruft'

For example, there have been multiple, tricky, x86-64 bugs in the last
few years which were more easily debugged by cross-checking against x86 -
This is a capability which would be lost, even if it is only kept for
this purpose.

Inverting the above figures -

One could say 'wow, even scientific linux which is more technical/server
oriented and therefore more likely to be 64-bit heavy still has 1/3
user base on x86 and the percentage isn't going down that much'
for example.

As for myself, I'll probably be switching any remaining systems to 64bit
later in the year as soon as I can hack together a scsh-64bit package
and virtualize any needed 32bit binary-only stuff on KVM/Linux + X windows,
with the exception of my soekren, which I'll keep on openbsd :D
So personally, either roadmap is probably fine for me - just commenting.

Cheers,

- Chris