On August 29, 2015 12:00:07 PM EDT, Yamaban <foerster@lisas.de> wrote:
On 29 August 2015 at 11:51, Michal Kubecek wrote:
On Fri, Aug 28, 2015 at 10:23:07PM +0200, Per Jessen wrote:
Jim Henderson wrote:
To what end? Why would you install a 32-bit OS on 64-bit hardware?
Jim, people (and myself) have pointed that out earlier in this
On Sat, 29 Aug 2015 17:04, Richard Brown wrote: thread:
running 32bit apps running 32bit virtual guests.
Both use less memory in 32bit.
The reminds me the argument that we shouldn't switch to IPv6 because routing tables would need more memory which would make routers more expensive. Memory prices (in e.g. dollars per MB) have dropped by several orders since the argument started to appear back in the 90's but the mantra keeps being repeated until today and will be repeated on and on.
It's the same here: my first 64-bit machine built in 2003 or 2004 had 2GB of RAM (perhaps even 1GB, I'm not sure); my strongest machine today (built in the end of 2012) has 32GB - and I might have actually paid less for these 32 GB than for those 2GB back in 2003 (certainly not much more). That's factor of 16 and I hope even you will agree that's much more than the ratio between x86_64 and i586 memory consumption.
At one moment, you simply need to bite the bullet and switch. Otherwise, you will keep repeating the "bigger memory consumption" mantra even if, from the long term perspective, it gets more and more ridiculous. The reward of getting rid of all the low/high mem trickery, vmalloc area limited to ~130 MB, limited register and instruction set or inefficient parameter passing (and I surely forgot a lot more) is worth it.
Michal Kubeček
+1
There is also the support lifetime of Leap to consider
32bit intel downloads have been declining for openSUSE from 11.4's release in March 2011 (when 32-bit media represented 55% of all openSUSE downloads) to date
By openSUSE 12.3 in March 2013 32-bit downloads had become the minority (40%) and that decline has continued unabated
Remember, 13.2 saw openSUSE's download numbers almost double compared to openSUSE 12.3. The proportion of 32-bit downloads have halved in the same period.
But we're not just talking about the past, we have to think about the future.
Leap 42.x is expected to be supported until at least November 2018
It would be counter-intuitive to dramatically change Leap 42.x's hardware support midway through its 42.x lifespan, so if we start supporting 32-bit for Leap 42.1, I would say the expectation would be that we should support it until the release of 43.0 3 years from now.
The decline of 32-bit usage is not going to slow down over the next 3 years.
Experience has also shown us that as time goes on, especially after hardware is no longer produced, it becomes harder and harder to keep supporting that old hardware.
If we decided to support 32-bit in Leap, we'd be committing to a lot of work, an increasing amount of work, for a long time, for an ever decreasing number of users.
That just does not seem sensible - I'm not going to block or work against anyone if they decide they're able and willing to do the work, but I look at the realities of our project, other projects, our users and the industry at large, and I really do not see the compelling argument for flogging the 32-bit dead horse for another 3 years.
It would make much more sense to offically endorse a continuation of OSS 13.1 as Evergreen 13.1 (32 + 64 bit) for that timeframe.
Nothing speaks against a possible actualisation of parts or components but absent manpower. If those that cry wolf on missing 32 bit in Leap 42.x would enage there, much would be won (and less noise here).
Talk to Wolfgang Rosenauer about that.
- Yamaban.
I suggest that is a major effort too. Currently Evergreen supplier is roughly 3 years total. You're talking 5 years. Those last 2 years will find it harder and harder to backport security patches etc. Wolfgang can speak up, but without programmers stepping up to the plate and volunteering to do that blacklisting, I don't see it. If memory usage is the main concern, I still argue for a 64-bit kernel and 32-bit aerospace. The entire boot system could be 64-bit so uefi, grub2, initrd could all be 64-bit, but then main application stacks could all be 32-bit. (Apache, mysql, postfix, etc). Theoretically the 32-bit distro pattern could be updated to pull those key pieces from 64-bit builds, but leave everything else to pull from the 32-bit builds they already pull from. How hard would it be to do that? If reasonable, then a group of volunteers could opt to support just the 32-bit boot stack in ports. For me, I don't need a 2015 distro to run on 10+ year old hardware so I won't be part of supporting a 32-bit boot stack. I will keep my 13.1 ISOs around so I can boot old hardware from DVD live media. I don't connect those machines to networks when I boot them and I am the only user, so security patches/support is a non-issue for me. Greg -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org