Am 10.10.2014 um 16:20 schrieb Yamaban:

On Fri, 10 Oct 2014 16:06, Michael Riess wrote:

...

Hi, tried to install Factory on AthlonXP.

It was a little bit frustrating because of several Apps closing with error "Illegal instruction"

i have read a lot on SSE2 optimizations on the list, which are rewind for Qt5 http://bugzilla.opensuse.org/show_bug.cgi?id=897758 but even Firefox doesnt work on AthlonXP

Simple question: Is it possible to upgrade a AthlonXP machine without SSE2 to Factory or 13.2 or is the last possible openSUSE for this machine really 13.1?

I use Factory on AthlonXP 1GHz / 2GB ram as a testing server, with minimal X11, no qt[45] or gtk libs.

Using Yast is possible in "text-mode" e.g. calling "yast2 --ncurses".

For the apps, either you have to recompile the kernel with "emulation" support for SSE2, or recompile the libs and apps without SSE2. Both ways have their on difficulties. Select your poision.

If available you have to select the .i586 packages instead of the .i686 ones.

There will be no easy solution, to small the niche, at least for openSUSE. recompiling the kernel on such a machine would be a pain also trial an run-error and recompile all the needed apps

also recompiling is not an option for people willing to convert from WindowsXP to Linux As openSUSE 13.1 is working fine and LTS it would be an option or just another Distri is needed I am a bit disapointed i cannot recommend openSUSE anymore for anyone :-( and i cannot explain MS-converters why to use the old version of openSUSE, would be to complicated and not encouraging to try it. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El 10/10/14 a las #4, Yamaban escribió:

The last AthlonXP sold as new comp was more than seven or so years ago. Fedora, for example, does not give any guaranty for being usable on hardware more than five years old.

Also..SSE2 has been around for over 10 years by now..

For such old machines there are other distros that deliver more support than openSUSE ever could. For example the "Puppy"-distro.

Have a overview at http://distrowatch.com/ or similar sites.

No need for that really, if 13.1 is an LTS release, one can use that as it will probably outlive the hardware in question. One can also buy SLE 11 for long term support.. there is no 32 bit SLE 12 though ..only 32 bit compatibility packages to run binaries in x86_64. -- Cristian "I don't know the key to success, but the key to failure is trying to please everybody." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, Oct 10, 2014 at 1:18 PM, Jan Engelhardt wrote:

On Friday 2014-10-10 17:48, Cristian Rodríguez wrote:

...

El 10/10/14 a las #4, Yamaban escribió:

...

The last AthlonXP sold as new comp was more than seven or so years ago. Fedora, for example, does not give any guaranty for being usable on hardware more than five years old.

Also..SSE2 has been around for over 10 years by now..

So what? SSE2 is an *optional extension* for x86, and only mandatory on x86_64. Hardware makers can leave it out if they think it benefits their chip complexity or TDP.

That's a good point but... ...are there any modern chips without them? AFAIK even Atoms have it. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 10.10.2014 um 17:48 schrieb Cristian Rodríguez:

El 10/10/14 a las #4, Yamaban escribió:

...

The last AthlonXP sold as new comp was more than seven or so years ago. Fedora, for example, does not give any guaranty for being usable on hardware more than five years old.

Also..SSE2 has been around for over 10 years by now..

may be for Intel but not for AMD

...

For such old machines there are other distros that deliver more support than openSUSE ever could. For example the "Puppy"-distro.

Have a overview at http://distrowatch.com/ or similar sites.

No need for that really, if 13.1 is an LTS release, one can use that as it will probably outlive the hardware in question.

I hope so

One can also buy SLE 11 for long term support.. there is no 32 bit SLE 12 though ..only 32 bit compatibility packages to run binaries in x86_64.

(only one of)the point(s) is: last year: if you told someone try Linux instead of your old WinXP on your old PC, it will work and will be faster than ever! this year: you tell this one you cant update it is like Windows, you need new hardware! this one will tell you: i told you last year, it doesnt make sense, only work, if i have to buy new hardware i will get a new working Windows with it! Yes, you can argue a lot about this, but not on this list.... I am getting off topic! If it is not possible to set up a i586/non-SSE2 via OBS-compile-flags i have to stick with 13.1 or another Distri (you see: SLE11 is not an option) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El 10/10/14 a las #4, Claudio Freire escribió:

I don't think RPM supports arch modifiers (like i686+sse2). Does it?

Nope, you will have to build an i686 package with -msse2 in that case. -- Cristian "I don't know the key to success, but the key to failure is trying to please everybody." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El 10/10/14 a las #4, Claudio Freire escribió:

On Fri, Oct 10, 2014 at 1:52 PM, Cristian Rodríguez wrote:

...

El 10/10/14 a las #4, Claudio Freire escribió:

...

I don't think RPM supports arch modifiers (like i686+sse2). Does it?

Nope, you will have to build an i686 package with -msse2 in that case.

Well, yeah. What I meant is marking the package as using sse2, and making rpm know not to install it on hardware that doesn't have sse2 (or auto-select any working alternative), so you could build both i686 and i686+sse2 versions and have the best of both worlds.

Nope.. no such feature exists unfortunately.. the only sort of thing that exists is a mechanism for providing shared libraries with or without particular CPU features enabled.. for example in factory you will find in /lib/noelision/ a version of libpthread without Intel TSX support, same can be done with other CPU features. Unfortunately it is an unspecified implementation detail..in the sense it is not documented how to use it, or at least there was no info last time I checked. -- Cristian "I don't know the key to success, but the key to failure is trying to please everybody." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El 10/10/14 a las #4, Cristian Rodríguez escribió:

Unfortunately it is an unspecified implementation detail..in the sense it is not documented how to use it, or at least there was no info last time I checked.

I stand corrected, this is briefly documented in the ld.so(8) man page.. -- Cristian "I don't know the key to success, but the key to failure is trying to please everybody." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 10.10.2014 um 21:20 schrieb Achim Gratz:

Cristian Rodríguez writes:

...

Nope.. no such feature exists unfortunately.. the only sort of thing that exists is a mechanism for providing shared libraries with or without particular CPU features enabled.. for example in factory you will find in /lib/noelision/ a version of libpthread without Intel TSX support, same can be done with other CPU features.

An extension that does not work correctly is enabled by default? How's that a good idea?

Back to SSE2 in i686: if that extension is not present or does not work correctly on all members of the i686 family of processors (that includes the Pentium Pro IIRC which had no SSE, much less SSE2), then it simply cannot be used for this architecture or must be guarded by feature checks. Anything else is a bug.

And please no comments about how old my computers are, I'm fully aware of that. They are still working just fine, doing what they've been doing for over a decade now. If I wanted to buy new hardware each time a new OS version rolled around, I'd be using Windows.

I really fully agree with this. Somewhere in the community process for 13.2 it must have been a discussion an decision in NOT supporting these CPUs any more cause in 13.1 it all works fine. Could someone explain please, why this decision was made i missed it somehow. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 13.10.2014 um 09:55 schrieb Andreas Schwab:

Claudio Freire writes:

...

Problem is, AthlonXP is an i686, but obs builds an i686 package that doesn't run on i686.

No, it doesn't. None of the (two) i686 packages are using SSE2 without testing for the feature.

There are only 2 packages with SSE2 enabled? which are they? "Illegal instruction" in Firefox and Konqueror is another bug? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 2014-10-14 15:03, Michael Riess wrote:

Am 13.10.2014 um 09:55 schrieb Andreas Schwab:

...

Claudio Freire writes:

...

Problem is, AthlonXP is an i686, but obs builds an i686 package that doesn't run on i686.

No, it doesn't. None of the (two) i686 packages are using SSE2 without testing for the feature.

There are only 2 packages with SSE2 enabled? which are they?

If you look through the build logs, you will find some packages that have -msse on the command line even though they probably should not Mesa.i586 MozillaFirefox.i586 MozillaThunderbird.i586 SDL2.i586 audacity.i586 babl.i586 blender.i586 clanlib-doc.i586 clanlib.i586 crystalhd-libs.i586 darktable.i586 dd_rescue.i586 ffado-mixer.i586 ffado.i586 fftw3.i586 freerdp.i586 gcc48.i586 gegl.i586 gf2x.i586 gimp.i586 glibc.i686.i586 gnubg.i586 guitarix.i586 libatlas3.i586 libdevil.i586 libffi48.i586 libgcj48.i586 liboil.i586 libqt4.i586 libqt5-qtbase.i586 libqt5-qtdeclarative.i586 libwebp.i586 openal-soft.i586 openttd.i586 pixman.i586 plasma-addons.i586 seamonkey.i586 soundtouch.i586 urbanlightscape.i586 valgrind.i586 vlc.i586 zinnia.i586 Additionally, there are - glibc.i686: tuned for i686 (can't say if it requires i686) - kernel-desktop: ExclusiveArch: i686; uses CMOV - kernel-pae: ExclusiveArch: i686; uses CMOV -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Stefan Seyfried composed on 2014-10-14 19:12 (UTC+0200):

So those interested in having a working i586 distribution should probably quickly file bugs against these packages, so that they can get fixed.

To what end if one of the oldest (filed 31 July) and worst (cannot GUI install) gets no love? YaST crashes just trying to start installation: http://bugzilla.opensuse.org/show_bug.cgi?id=889714 -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Stefan Seyfried composed on 2014-10-14 19:28 (UTC+0200):

Felix Miata composed:

...

Stefan Seyfried composed on 2014-10-14 19:12 (UTC+0200):

...

...

So those interested in having a working i586 distribution should probably quickly file bugs against these packages, so that they can get fixed.

...

To what end if one of the oldest (filed 31 July) and worst (cannot GUI install) gets no love? YaST crashes just trying to start installation: http://bugzilla.opensuse.org/show_bug.cgi?id=889714

Well, I have not looked at your bug, but at least Jan found the actual problem and does not just state "it does not work", so a bug with the actual cause of the problem might be more likely to get attention.

Had you looked you might have noticed it got attention right away. A core was attached that narrowed the problem description, but the report apparently has since been ignored: /usr/lib/YaST2/startup/YaST2.call: line 289: 3393 Illegal instruction (core dumped) $OPT_FBITERM y2base "$Y2_MODULE_NAME" $Y2_MODE_FLAGS $Y2_MODULE_ARGS $Y2_UI_ARGS The way I understand it, the installer is built on QT5, which depends on sse2, which is not supported by all i686 CPUs. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, 14 Oct 2014 19:48, Jan Engelhardt wrote:

On Tuesday 2014-10-14 19:43, Felix Miata wrote:

...

Had you looked you might have noticed it got attention right away. A core was attached that narrowed the problem description, but the report apparently has since been ignored:

/usr/lib/YaST2/startup/YaST2.call: line 289: 3393 Illegal instruction (core dumped) $OPT_FBITERM y2base "$Y2_MODULE_NAME" $Y2_MODE_FLAGS $Y2_MODULE_ARGS $Y2_UI_ARGS

The way I understand it, the installer is built on QT5, which depends on sse2, which is not supported by all i686 CPUs.

The installer is also built on ruby - another source of unconditional SSE2.

The OpenQA cluster definitely needs an AXP in the testsuite. (My offer of donating a fully equipped box still stands, but I might have overheard OQA uses a form of virtualization [which is principially tweakable]...)

Could the OpenQA 32bit machines modified to emulate a non-SSE2 cpu? That would get the trouble visible and fast. But agreed on QT5 and ruby, their 32bit builds should be enforced NO SSE2 at all, or we need different 32bit packages e.g i586 and i686, with i586 on the install medium. For the SUSE enterprise fraction: In light of SLE12 = 64 bit only, the step modify the 32bit machines to no SSE2 would only hit SLE11(SP3) and even there the preformance impact should not be relevant -- except maybe for single digit edge cases. - Yamban. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 14.10.2014 um 20:28 schrieb Jan Engelhardt:

On Tuesday 2014-10-14 20:11, Yamaban wrote:

...

Could the OpenQA 32bit machines modified to emulate a non-SSE2 cpu? That would get the trouble visible and fast.

But agreed on QT5 and ruby, their 32bit builds should be enforced NO SSE2 at all, or we need different 32bit packages e.g i586 and i686, with i586 on the install medium.

Even for i686, you must deactivate unconditional SSE.

"qemu-kvm -cpu pentium2 -cdrom i686.iso" boots, and /proc/cpuinfo claims to not support sse2 nor sse, but it does not expose the bug (YaST2 starts up just fine), so I guess it actually does support sse and sse2 (which is logical, because the CPU is not emulated but "passed through" from the host, it's just the cpuid commands that are emulated probably). So using this in openqa does not really help. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Yamaban writes:

Sh.t, so much for emulated validation, at least with qemu.

If you want that you need to use full emulation (no kvm). Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 14.10.2014 20:11, schrieb Yamaban:

Could the OpenQA 32bit machines modified to emulate a non-SSE2 cpu? That would get the trouble visible and fast.

openQA is hosted on github.com/os-autoinst - feel free to play around it to reproduce the problem. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Found a nice little tool called analze-x86 Packages: https://build.opensuse.org/project/show/home:StefanBruens:analyze-x86 Usage: analyze-x86 <executable or library> Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 work: +49 2405 49936-424 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Oct 14, 2014 at 5:18 PM, Jan Engelhardt wrote:

On Tuesday 2014-10-14 20:11, Yamaban wrote:

...

...

...

The way I understand it, the installer is built on QT5, which depends on sse2, which is not supported by all i686 CPUs.

The installer is also built on ruby - another source of unconditional SSE2.

The OpenQA cluster definitely needs an AXP in the testsuite. (My offer of donating a fully equipped box still stands, but I might have overheard OQA uses a form of virtualization [which is principially tweakable]...)

Could the OpenQA 32bit machines modified to emulate a non-SSE2 cpu? That would get the trouble visible and fast.

If there is no hardware exception for an illegal instruction, how do you know it's illegal? You would have to analyze/tweak the binary code beforehand, meaning your half-emulation layer turns into a full-blown one, and that appears to be likely a slow business.

That is why it seems easiest to just throw a non-SSE silicon in the loop which will always raise the exception.

The only faster thing is looking at the build logs for low-hanging fruit, I named several packages where this seems to be the case.

Perhaps rpmlint could be taught about the issue? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 14.10.2014 19:29, Daniele wrote:

Il 14/10/2014 17:04, Jan Engelhardt ha scritto:

...

On Tuesday 2014-10-14 15:03, Michael Riess wrote:

...

Am 13.10.2014 um 09:55 schrieb Andreas Schwab:

...

Claudio Freire writes:

...

Problem is, AthlonXP is an i686, but obs builds an i686 package that doesn't run on i686.

No, it doesn't. None of the (two) i686 packages are using SSE2 without testing for the feature.

There are only 2 packages with SSE2 enabled? which are they?

If you look through the build logs, you will find some packages that have -msse on the command line even though they probably should not But -msse is ok, the evil is -msse2

Daniele.

If you build a i586 package i'd go with no. The original pentium did not have support for it. There was a nice table somewhere in this thread. Packages with -msse should be i686 only! I think we need even more split for the packages. i586 / i686 / sse1 / sse2 for 32Bit Builds. Greetings, Tobias -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Michael Riess composed on 2014-10-17 13:49 (UTC+0200):

(yes i know 13.2 Release is near, it is critical to do changes but RC is for eliminating bugs and i think this is a bug)

How could it not be a bug that GUI YaST crashes simply trying to initialize from installation media? http://bugzilla.opensuse.org/show_bug.cgi?id=889714 -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Michael Riess composed on 2014-10-17 16:58 (UTC+0200):

Felix Miata composed:

...

How could it not be a bug that GUI YaST crashes simply trying to initialize from installation media? http://bugzilla.opensuse.org/show_bug.cgi?id=889714

I thought this was solved with: https://bugzilla.novell.com/show_bug.cgi?id=872908

This is an openSUSE mailing list. Please do not post novell.com bug links on opensuse lists.

isnt it?

How would anyone know? https://bugzilla.opensuse.org/show_activity.cgi?id=872908 was marked fixed 13 Oct, and has never been mentioned in 889714. The yardstick I go by to try installation again is in http://download.opensuse.org/factory/repo/oss/boot/i386/loader/ where linux and initrd are two days older (11 Oct).

Myself did the install via 13.1 and zypper dup to avoid the problem did no new install since then -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation)

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 17.10.2014 16:28, Claudio Freire wrote:

On Fri, Oct 17, 2014 at 8:49 AM, Michael Riess wrote:

...

The longer i think about it: Are there any arguments or any messurements that proof in any way any REAL benefits of the optimize-flags(-msse2 -msse ...)? Most of the libs that truly benefit from this already do runtime feature detection.

The biggest offender is probably perl, but it's easy to correct (patch the makefile), and Mozilla (this one may be a lot harder).

Problem with Mozilla, is that maybe SpiderMonkey's JIT generates SSE2?

If it really relys on sse2 and can't be patched (easily) it just is a i686 or i686+ package. Creating a JIT which does not generate SSE2 Instructions is way to much hassle, given we'd have to maintain it, not upstream. It is really bad not to have such packages on i586, maybe we can find another browser for these (few) cases. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, Oct 17, 2014 at 12:37 PM, Michael Riess wrote:

@ClaudioFreire: you said: perl problems could easily be solved could you please open a description in Bugzilla how to patch the makefile? (you seem to know what to do, dont you?)

Sorry, ruby. Got a bit confused, I even got to the point of branching perl to try to fix it :-p Lets go after ruby now. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Michael Riess composed on 2014-10-10 18:29 (UTC+0200):

Cristian Rodríguez composed:

...

Yamaban composed:

...

...

The last AthlonXP sold as new comp was more than seven or so years ago. Fedora, for example, does not give any guaranty for being usable on hardware more than five years old.

...

Also..SSE2 has been around for over 10 years by now..

may be for Intel but not for AMD

...

...

For such old machines there are other distros that deliver more support than openSUSE ever could. For example the "Puppy"-distro.

...

...

Have a overview at http://distrowatch.com/ or similar sites.

...

No need for that really, if 13.1 is an LTS release, one can use that as it will probably outlive the hardware in question.

I hope so

...

One can also buy SLE 11 for long term support.. there is no 32 bit SLE 12 though ..only 32 bit compatibility packages to run binaries in x86_64.

(only one of)the point(s) is: last year: if you told someone try Linux instead of your old WinXP on your old PC, it will work and will be faster than ever! this year: you tell this one you cant update it is like Windows, you need new hardware! this one will tell you: i told you last year, it doesnt make sense, only work, if i have to buy new hardware i will get a new working Windows with it! ... If it is not possible to set up a i586/non-SSE2 via OBS-compile-flags i have to stick with 13.1 or another Distri

I bought the following (Socket A) Sempron (no SSE2) 8 years ago as of next week. http://www.newegg.com/Product/Product.aspx?Item=N82E16819104203 http://www.cpu-world.com/CPUs/K7/AMD-Sempron%202400%2B%20-%20SDA2400DUT3D%20... Using it in July I discovered installation YaST segfaults trying to start and filed https://bugzilla.opensuse.org/show_bug.cgi?id=889714 to report it. On that machine I have working Firefox on both Fedora 21/KDE 4.14.1 and on Mageia 5/KDE 4.14.1, both updated in recent hours, both running newer kernels (3.17) than 13.2 will be released with (3.16). Both F21 and M5 are scheduled for release more than a month after 13.2 release. It's a shame openSUSE packagers have committed to jumping the gun over at least two distros listed higher than openSUSE in distrowatch.com ranking, including the top ten distro with the bleeding-edge reputation, in forcing existing users to choose between abandoning their distro, and abandoning working hardware. At what cost? For what advantage? openSUSE users who *need* whatever performance benefit sse2 offers can upgrade *their* hardware, and choose 64 bit openSUSE. What this is apparently about in reality is openSUSE is being dragged by decisions optimized for SLE12, where there will be no 32 bit offering at all, plus the usual explanation for dropping support for older hardware, dwindling supply of older hardware in the hands of those that do the work. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Friday 2014-10-10 16:20, Yamaban wrote:

For the apps, either you have to recompile the kernel with "emulation" support for SSE2

You speak of some emulation setting, but where is it? Can you actually back up your claims? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org