I'd like to add a counterpoint. Though I've reported that kind of problem regarding baloo and krunner (already fixed in libxapian -- bug 15457 ), from the Chrome/ium example it's possible to see some applications are not devised for older hardware. In this computer Chromium simply cannot be used (and with that almost the only way to use an updated Flashplayer).

Maybe that is the case also with Midori and Qupzilla (and perhaps with Opera, too).

C'est la vie... it's bad to rely only on FF, though.

But Opera 12 (not based on Chrome) is still available in M5... yay!

Further testing reveals that Midori actually can render simple sites -- those with just text like craigslist.org and others; Wikipedia though made Midori crash.

It's not about Flash, because it's not installed on this PC; instead, I suppose Webkit (and thus Qtwebkit) is the part that both use to render web pages and it seemingly requires SSE2.

Requiring SSE2 itself is also a subject for debate.

Sometimes there is a _need_ to use such instruction; in other times, lack of resources make a developer unable to maintain two versions of the code (with and without the use of SSE2). In that case, it is not required per se, but it is made to be required.

Sometimes developers simply have other problems and decide they won't solve this one; fair enough, the code is usually GPL'd, one is free to recompile things.

Interesting links:

http://en.wikipedia.org/wiki/SSE2#Notable_IA-32_CPUs_not_supporting_SSE2
https://forums.dolphin-emu.org/Thread-reason-why-sse2-is-required
http://musescore.org/en/node/31361
https://mischasan.wordpress.com/2011/06/22/what-the-is-sse2-good-for-char-search-in-long-strings/
https://software.intel.com/en-us/forums/topic/301144
http://forum.siduction.org/index.php?topic=4050.0

I think it is a kind of waste to deactivate some piece of hardware because of software. I've seen scanners thrown out because there was no driver for them in Windows 7, while they worked nicely in XP.

If the machine wasn't fast enough for high CPU demanding apps, it still would be good enough for many uses -- like some kinds of home server, for instance.
But in the case of this PC, it is good enough to play HD video (with mplayer or VLC).

Reflecting better on the subject, I wonder if the present bug could not also be qualified as a "feature request" (i.e. not a real bug).

For comparison, imagine that application X is supported by its coders as 64-bit software and not as 32-bit.

Some source-based distros could try to provide a 32-bit version and even then issues might arise which would have a very hard solution -- because the distro maintainers cannot actually solve coding problems (IMHO... for 30,000 packages that would be an insane task).

If the distro provides binaries for convenience of its users, the problem is even more pronounced.

So, to sum it up, user A wants app X to have support for non-SSE2 processors, because it has a quite fast old CPU which is able to run the app with moderate to good speed.

Developer B wants app X to compete with fast alternatives (like Chrome) and has not the financial clout to be able to maintain two versions of the X app.

Either user A opts for a bigger developer which can do it (like Firefox), uses a simpler app for older computers (Opera 12?) or starts a fork of app X (possibly not that well maintained) compiling X from source for the old CPU by him/herself.

In essence, the point here is that the distro folks must decide if they want to have a coding department and assume the fork... which probably will have some degree of conflict with the original developers in the future, no doubt.

Either way, one things is sure: a package must run in every i586 machine to be called "for 586".

If some app (like Qupzilla) is going to run only on certain i586 CPUs and not on others (also i586), we probably should have a new architecture, like that:

i486
i586
i586 with SSE2
x86_64

That's because a "software center", or package manager, must know which applications to offer based on a user system; offering Midori (as it is now) to a non-SSE2 system and letting the user "caveat" is, how can I put, sub-optimal.

Please excuse me if I sound "entitled". I assure everyone that is not my intention.

I thought on some things about which I'd like to comment:

a) This is not a Mageia bug

Since the end of 386 support by the kernel and because of the 64-bit trend, many distributions are drawing a line and just offer support for i686 and x86_64. It came to a situation where some comment about why some distributions still support i586 -- I fail to understand why this is relevant at all. The net effect is that some app developers bypassed the i586 entirely. The perspectives of support for i486 depend now on specialized distributions for "Old computers", like e.g. Puppy or antiX. And for some of these old computers, it may even be feasible to use an old distribution (like e.g. Mageia 3) for certain uses (e.g. an isolated machine).

b) It's not a widespread problem

Not everyone has computers which lack that instruction; and those who have may have other old computers which can execute it (e.g. me). In the end, one must make a trade-off and certain things simply fall out of the budget. 80% of costs come from 20% of the problems, so it may benefit the majority of users with more recent equipment if developers don't tackle corner cases. Realistically, it would be absurd to drop excellent alternatives like the browsers in question because of a few users. On the other hand, some of the problems are very demanding (like UEFI) and a better use of resources might be paying more attention to these. Besides, any fix for this bug will be temporary: the machines themselves will slowly fail with age.

c) Other solutions might arise if we think out of the box: for instance, some hardware maker could trade-in the old computer for a discount on the purchase of a new one (which would use less power, for instance).

These reasons make me doubt which component to attribute this bug -- maybe this apply to none of the alternatives.

Also, this could be viewed as a feature request like when XP had its support extended (thus not a bug).

For all that, I'm lowering the priority of this bug and changing its severity to minor (because the distro itself works on old hardware, it's just some applications that do not).

Alas, depending on internal Mageia talks, this bug could either:

a) originate a comment about level of support in the Release Notes or
b) simply be marked WONTFIX, if Mageia steps ahead to support only Pentium 4 or above.

Thanks for your attention and hard work. Other similar bugs (by me!) will be marked likewise (e.g. bug 10385).

If you disagree, please undo my changes.

Priority: Normal => Low
Severity: normal => minor

I had the chance to install Plasma 5 on this non-SSE2 machine, when testing M5 RC.

It gives an error -- kwin crashes repeatedly -- and the KDE crash analysis does not report "Illegal instruction", but just says unidentified error (I can't really recall the exact message but it's non-descriptive).

I recall having read somewhere that libQt5 uses that instruction.

Upon a certain number of crashes, KDE asks if the user wants to use another WM -- I had only Openbox installed which makes for a much more desolate experience.

The worse part is getting rid of Plasma5:

- unistalling task-Plasma5-minimal does not remove anything in reality;
- uninstalling everything called Plasma is not enough;

For instance, in that "taskbar with icons" widget the KDE configuration icon when called opened an empty window... because it was still systemsettings5. Fortunately, the menu had the correct entry, "systemsettings".

There is no need for a new architecture, libraries which behave really much better with it can have several versions built.

[pterjan@chopin-cauldron-64 ~]$ urpmf /usr/lib/sse2/
libmjpegtools2.0_0:/usr/lib/sse2/liblavfile-2.0.so.0
libmjpegtools2.0_0:/usr/lib/sse2/liblavfile-2.0.so.0.0.0
libmjpegtools2.0_0:/usr/lib/sse2/liblavjpeg-2.0.so.0
libmjpegtools2.0_0:/usr/lib/sse2/liblavjpeg-2.0.so.0.0.0
libmjpegtools2.0_0:/usr/lib/sse2/liblavplay-2.0.so.0
libmjpegtools2.0_0:/usr/lib/sse2/liblavplay-2.0.so.0.0.0
libmjpegtools2.0_0:/usr/lib/sse2/libmjpegutils-2.0.so.0
libmjpegtools2.0_0:/usr/lib/sse2/libmjpegutils-2.0.so.0.0.0
libmjpegtools2.0_0:/usr/lib/sse2/libmpeg2encpp-2.0.so.0
libmjpegtools2.0_0:/usr/lib/sse2/libmpeg2encpp-2.0.so.0.0.0
libmjpegtools2.0_0:/usr/lib/sse2/libmplex2-2.0.so.0
libmjpegtools2.0_0:/usr/lib/sse2/libmplex2-2.0.so.0.0.0
libxapian22:/usr/lib/sse2/libxapian.so.22
libxapian22:/usr/lib/sse2/libxapian.so.22.5.0
libqt5gui5:/usr/lib/sse2/libQt5Gui.so.5
libqt5gui5:/usr/lib/sse2/libQt5Gui.so.5.4
libqt5gui5:/usr/lib/sse2/libQt5Gui.so.5.4.0
libqt5core5:/usr/lib/sse2/libQt5Core.so.5
libqt5core5:/usr/lib/sse2/libQt5Core.so.5.4
libqt5core5:/usr/lib/sse2/libQt5Core.so.5.4.0

CC: (none) => pterjan

It's a matter of finding libraries which accidentally use it (usually because they will detect that the build machine supports it).

Well, first, thank you for showing the command above. As an end user, I didn't even know there was a "sse2" directory. Makes life a lot simpler.

Second,

> It's a matter of finding libraries which accidentally use it (usually because they will detect that the build machine supports it).

That, I think, is exactly the problem.

I may be wrong (if so, please correct me), but I think we have the following situations:

486 CPU
=======

Most installers think: this has not SSE2, so get the 486 libs (if the distro has tehm, of course).

586 CPU
=======

Most don't have the SSE2 instruction, but the more recent ones have it. A distro could:
a) assume it has not and go for the lib version which does not use SSE2 (even if the CPU has it);
b) assume it has and state in documentation: "we only provide libs for Pentium 4 and above, not inferior 586's";
c) do an extensive check on the CPU model (or just use "cat /proc/cpuinfo" and test whether "sse2" is present)

Most Ubuntu derived distributions today do (b) AFAIK, so they're inadequate for my CPU.

686 CPU
=======

Most assume SSE2 is available. That is the general rule -- except for my AMD Sempron 2300+ processor, which is an i686 and yet does not have that instruction.

-//-

What does that mean in practice?

It means I must use i486 software with my i686 CPU!

Is there a way for me to tell the installer not to install programs with the SSE2 instruction? :-)

=====

Or perhaps as a function of MCC's software installation -- it would if detected, even after installation, whether the CPU is compatible with each lib/package. That would require each package to carry an info field about which flags were used for compiling it... is that available?

====

I had already thought about just replacing the applications which require SSE2. I've read that Debian has something called "multiarch" in which you can ask things like (possibly wrong syntax):

apt-get install midori:486

Since I'm not a Debian user and a long-time Mageia/Mandriva/Mandrake user, I must look for special Mageia repos with 486 versions of these programs. Is that what you meant? Or are you telling me to compile from source with adequate flags?

If they exist, is there a way to find about such repos?

Thanks, again, for the suggestion.

The way it works when several libraries are built is that an application requiring the library will (on startup) get the best one depending on the current CPU.

It's not related to installing the packages, sse2 and non sse2 will usually be in the same package.

If some packages have something using sse2 not in the sse2 directory, this is a bug which should be fixed. It happens sometimes, usually because that software will decide to enable sse2 at build time because the machine compiling it has it working instead of building for generic i586 as requested.

That's very interesting to know and gives me renewed expectations.

> If some packages have something using sse2 not in the sse2 directory, this is a bug which should be fixed.

Well, from my personal point-of-view, even if some package has something using sse2 and still in the sse2 directory -- that is still a bug, because as you pointed out earlier, it should be using a non-SSE2 lib in the same package.

And that might arise from some confusion about the CPU -- for instance, it might be thinking: "oh, a nice 686 CPU, let's use SSE2 then"...

(These are installed, I just checked: libxapian, libQT5core and libQt5Gui).

> It happens sometimes, usually because that software will decide to enable sse2 at build time because the machine compiling it has it working instead of building for generic i586 as requested.

Yep, this is related to what I said above about developers with limited resources who decided to go for what kind of processor the majority has.

I think it's a valid decision, as long as one puts a disclaimer telling everyone about it.

I'll research a little more to see whether libQt5 is planned to work on older PCs... or not :-( .

Thanks for helping till now.

Hi, Pascal,

I was searching for another post of mine about the SSE2 instruction (search term=="baloo") and found a lot of bugs in which this situation is discussed.

Bugzilla didn't show them to me before probably because I was citing Midori and Qupzilla. Now that I added Plasma, I started to see tome connections.

I'm copying the bug numbers here for future reference: bug 14418 , bug 13991 , bug 14229 and bug 13383 (this one not about sse2).

In particular, in bug 14418, comment #3, Thomas Backlund mentions that Fedora built a dual-nature Qt 5.3 for i586 machines regarding SSE2 support. Probably that was not yet done in Mageia, or Midori/Qupzilla wouldn't crash.

Oh, well, maybe I should test plasma5 again to see what I can find...

Pascal, one question regarding your idea in comment 8...

In your opinion, who is supposed to build such better library version?

Is it a task to be left for the end user, who should apply the right compiler flags according to the target hardware?

The maintainer of the package should fix the package to either disable sse2 or provide both

Thank you for the quick answer, Pascal.

For the record, I also think that's a reasonable approach.

Hi, from the above clarifications, and aiming at a more efficient resolution of the cited issues, I concluded I should file separate bugs about the SSE2 requirement for Midori, Qupzilla and Plasma5.

That doesn't mean these software packages will work without such requirement -- WONTFIX is a possible "solution".

I'd like to mention though this definition from Wikipedia (1):

"In computing, Streaming SIMD Extensions (SSE) is a SIMD instruction set extension to the x86 architecture, designed by Intel and introduced in 1999 in their Pentium III series processors as a reply to AMD's 3DNow!. SSE contains 70 new instructions, most of which work on single precision floating point data. SIMD instructions can greatly increase performance when exactly the same operations are to be performed on multiple data objects. Typical applications are digital signal processing and graphics processing."

Also from Wikipedia (2):

"Single instruction, multiple data (SIMD), is a class of parallel computers in Flynn's taxonomy. It describes computers with multiple processing elements that perform the same operation on multiple data points simultaneously. Thus, such machines exploit data level parallelism, but not concurrency: there are simultaneous (parallel) computations, but only a single process (instruction) at a given moment. SIMD is particularly applicable to common tasks like adjusting the contrast in a digital image or adjusting the volume of digital audio. Most modern CPU designs include SIMD instructions in order to improve the performance of multimedia use."

So, it is mainly for multimedia, dsp and graphics.

Since multimedia, dsp and graphics already existed before SSE/SSE2, it follows that some of these uses do not require such instructions. 

Another way to put this is: some intensive floating-point spreadsheet use might require those instructions, but home budget use probably can do without them.

Of course, there's a whole lot of applications which are totally not floating-point nor multimedia. But if browsers require such instructions, it's almost certain that distributions like Mageia would be forced to demand them, too.

Servers, for instance, would probably very well do without them. I've used Mageia to power a server in the past; I don't whether there are or not plans to enter that area.

Also, retro games (a recent trend) wouldn't require them.

Somehow this seems like a way to force the usage of newer CPUs. That could be mean not only bigger sales of new CPUs, but even new revenues from relicensing newer designs. Which seems to be what the following page ("Stop the instruction set war") is about:


http://www.agner.org/optimize/blog/read.php?i=25


I found it interesting. It seems some old computers are the casualties of this war.

The net result is an accelerated obsolescence of the computer park in some places. While the 386 standard was deprecated after decades in use, 486 PCs, a good portion of 586 and even some 686 ones are going to turn into doorstops.

I think it's a waste of good computers and a burden for the budget of some families.

--------------

(1) https://en.wikipedia.org/wiki/Streaming_SIMD_Extensions
(2) https://en.wikipedia.org/wiki/SIMD

Sorry if I misused a word. In Portuguese, "computer park" means all the computers of an organization viewed as collection. This seems not to be the case in English.

So I meant something rather serious like making a significant part of the computers in an industry, school, hospital etc. obsolete faster.

Also, I seem to have read somewhere (can't recall now) that SSE instructions are important for JIT (just-in-time or on-the-fly) compilation of things like Javascript. That would make them important e.g. for cloud-based apps.

Nowadays, apps like Gmail or Google Maps usually have a simpler mode to be used with used with less powerful (or older) browsers. That could change in the future.

The present issue, in a very sketchy summary, is about not all 586 CPUs being supported by modern applications. For the most part, it's an upstream issue...

I'm reevaluating some bugs I filed from two points of view:

a) What is a bug and what is an enhancement:

Bug is something which should work but it's broken. Enhancement (as I see) is something which should work but still wasn't created (so I cannot be considered broken). Since distributions are not supposed to fix original software -- that's why they are called distributions -- an enhancement is better left for the original software author or for an interested third party.

b) The role of Mageia as a community distribution:

Some distributions are commercial and thus better funded; also, they cater to a special niche (e.g. business, "enterprise", "educational" users etc.), so they follow the priorities that such groups have. A community distribution OTOH is more general purpose and features are made available by the coders: issues like funding, resources etc. play a greater role. In order to be effective, community distros need to be more efficient regarding resource consumption.

Therefore, I guess it's reasonable to close this bug as WONTFIX. Please feel free to undo that if there's a way to solve it.

Status: NEW => RESOLVED
Resolution: (none) => WONTFIX