On August 29, 2015 12:00:07 PM EDT, Yamaban <foerster(a)lisas.de> wrote:
On Sat, 29 Aug 2015 17:04, Richard Brown wrote:
On 29 August 2015 at 11:51, Michal Kubecek
> 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
>> Jim, people (and myself) have pointed that out earlier in this
>> 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
> the mantra keeps being repeated until today
and will be repeated on
> It's the same here: my first 64-bit machine built in 2003 or 2004
> 2GB of RAM (perhaps even 1GB, I'm not
sure); my strongest machine
> (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
> more). That's factor of 16 and I hope
even you will agree that's
> more than the ratio between x86_64 and i586
> At one moment, you simply need to bite the bullet and switch.
> you will keep repeating the "bigger
memory consumption" mantra even
> from the long term perspective, it gets more
and more ridiculous.
> reward of getting rid of all the low/high mem
trickery, vmalloc area
> limited to ~130 MB, limited register and instruction set or
> parameter passing (and I surely forgot a lot
more) is worth it.
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
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
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
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
much would be won (and less noise here).
Talk to Wolfgang Rosenauer about that.
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
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
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
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.
Sent from my Android device with K-9 Mail. Please excuse my brevity.
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org