Re: multiarch/bi-arch status (ETA) question
Gnu-Raiz <Gnu-Raiz@midsouth.rr.com> writes:
> I agree, if source software is unable to be compiled with 64
> bit support then I would suggest that the developer needs to
> get with it. Just look at the hardware that is in the
> channel, most 32 bit cpu's are getting phased out, yes you
> can still get them but soon it will cost more, and have less
> value then just getting a 64 bit cpu, motherboard. Intel,
> AMD will all have 64 bit cpu's through all their channels in
> a matter of months, this includes Celron, Sempron these will
> be 64 bit cpu's. By the time etch is out, I would not be
> surprised that most I386 code will be the exception not the
> rule, in fact I suspect that it will be somewhat like
> support for I386 was, ie you will have to compile in the
> special options for 32 bit code in most distro's. Too me
> multi-arch was a good idea a few years ago, but do you
> really want a mixed bag in say 12-24 months when everything
> is 64 bit anyway?
You are totaly forgeting sparc64, ppc64, mips64, mipsel64 and
s390x. Also you are forgetting linux/bsd multiarch systems.
While for amd64 32bit code is hardly any use mixing bsd and linux
might still be valuable. And for all other archs having the main
system in 32bit mode is a huge gain in spead and resources while a few
things gain from the larger address space of 64bit support
(e.g. postgresql).
I agree that multiarch isn't the holy grail for amd64 but a huge
benefit to those other archs.
> I also look at this as a good time for a source purge, those
> developers who refuse to support, or update their code
> should be left behind. The code that is not supported, or
> lacks developers likewise should be left behind, or if its
> important then they should work on a port. All one has to do
> is look at the orphaned code in debian, how much of this
> stuff would people actually miss if it was dropped, if it is
> important than the developers can support it. What this
> shows me is that developers don't care one way or the other,
> and if that is the case then they deserve to be left behind.
The code that makes problems isn't the year old unix hardened code
without any upstream anymore but all those new fancy things with
incapable programmers. Code quality has become much worse with i386
linux getting such a majority of programmers.
> As far as apt and dpkg is concerned sure the idea of fixing
> them for support sounds good, but is it necessary? I think
> that the developers of these packages should consider the
> marketplace in say 12-24 months see just where their
> developer time should be spent. I would rather see, better
> code, bug fixes, and overall stability then a fix for
> something that is getting phased out.
Yes it is worth it. Not because software won't compile 64bit (because
it does as other 64bit archs and pure64 shows) but because users don't
want it all 64bit. The inability of some people to write clean
architecture independant code was never an argument for multiarch
imho.
MfG
Goswin
Reply to: