Re: Retire a package from Fedora i686 (not x86_64)

[Kevin Kofler]

An update on this:

Kevin Kofler wrote:
> This is only a minor annoyance where a portable fallback exists (we can
> just ship the portable C/C++ version in /usr/lib and the SSE2 version in
> /usr/lib/sse2, as we are doing with Qt 5 QtDeclarative). The real problem
> is software which has no portable fallback at all, such as
> Chromium/QtWebEngine or Darktable. This completely screws not only
> non-SSE2 x86, but also all secondary architectures, and in some cases such
> as Darktable, even the primary architecture ARM. It is unfortunate that
> the number of such non- portable software seems increasing lately.
> Portability to any and all CPU architectures used to be a big selling
> point for Free Software. These days, more and more projects seem happy to
> sacrifice this on the altar of performance. :-(

I think I have what it takes to get QtWebEngine working on non-SSE2 now:
1. https://bugzilla.redhat.com/show_bug.cgi?id=1293190
2. https://bugzilla.redhat.com/show_bug.cgi?id=1244196#c24

Thankfully, V8 actually does support non-SSE2 x86: Shortly after support was 
removed from the "ia32" target, it was readded as a separate "x87" one. So 
only Chromium/QtWebEngine needs patching (because they started requiring 
SSE2 in their own code).

That said, this only helps 32-bit x86. Most secondary architectures are 
still screwed, because V8 does not have portable C/C++ fallback code (unlike 
Chromium's own code).

Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Retire a package from Fedora i686 (not x86_64)

[Reindl Harald]

Am 12.11.2015 um 21:49 schrieb Przemek Klosowski:

On the other hand, Harald, I have to say that in this case my irony
detector bent the needle. You often voice your displeasure in this forum
that some setup you used for years was broken by new stuff, and yet you say

you CAN NOT HAVE both - leading edge software and legacy support forever


I just see this quoted back at you in the future :)


it's a difference replacing working software with some 
alpha/beta-quality stuff lacking half of the features and waiting years 
to get useable as before or just drop the support for hardware older 
than 10 years for the sake of use capabilities of more recent one




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Germano Massullo]

A clear example of the mentioned problems for Darktable 32 bit
http://redmine.darktable.org/issues/10717
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Przemek Klosowski]

On 11/11/2015 03:54 PM, Reindl Harald wrote:


Am 11.11.2015 um 21:20 schrieb Fred New:


On the other hand, my >10 year-old 32-bit system (Fedora 22) is the only
place my LaserJet 4L printer works. My 64-bit systems drop control
sequences (like they don't flush the output buffer), leaving the last
page of every job sitting in printer memory. I reported the bug a few
years ago, but it got closed as WONTFIX and now I can't find it in 
bugzilla


we talk about a *bleeding edge distribution*

https://en.wikipedia.org/wiki/HP_LaserJet_4#4L_and_4P
"The LaserJet 4 series was discontinued in the 1990s"

why in the world does somebody install a operating system released in 
2015 to drive harwdare realeased 10-15 years ago and *why in the 
world* should recent hardware feautures ignored forever because of 
users with such hardware?


This should not be a big problem---the printer used to work, so we have 
a regression. From Fred's description, it looks like a simple issue, 
actually.


I agree with you that the ball is in Fred's court, though: he's the one 
that wants to keep his stuff running so at least he should help to 
diagnose and report the problem (which he did), and follow up by 
tracking it to some satisfactory resolution (which he didn't). It seems 
to me that Fred should find, reopen and pursue his bugzilla report.


On the other hand, Harald, I have to say that in this case my irony 
detector bent the needle. You often voice your displeasure in this forum 
that some setup you used for years was broken by new stuff, and yet you say

you CAN NOT HAVE both - leading edge software and legacy support forever


I just see this quoted back at you in the future :)



-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Fred New]

On Sat, Nov 7, 2015 at 6:03 AM, Reindl Harald 
wrote:

>
>
> Am 07.11.2015 um 05:00 schrieb Luya Tshimbalanga:
>
>> On 06/11/15 07:29 PM, Ralf Corsepius wrote:
>>
>>> But if upstream doesn't care, it's going to be a problem. :-(

>>> Exactly - That's the actual problem. Upstream does not care and Fedora
>>> seems unable to address this issue.
>>>
>>> Ralf
>>>
>>> According to my system, it has SSSE3. Is it SSE3?
>> Taken from A10-7400P laptop
>>
>
> any system not older than 10 years has SSE3 and frankly systems older than
> 10 years are hardly a traget for Fedora at all
>
> On the other hand, my >10 year-old 32-bit system (Fedora 22) is the only
place my LaserJet 4L printer works. My 64-bit systems drop control
sequences (like they don't flush the output buffer), leaving the last page
of every job sitting in printer memory. I reported the bug a few years ago,
but it got closed as WONTFIX and now I can't find it in bugzilla.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Reindl Harald]

Am 11.11.2015 um 21:20 schrieb Fred New:

On Sat, Nov 7, 2015 at 6:03 AM, Reindl Harald > wrote:

Am 07.11.2015 um 05:00 schrieb Luya Tshimbalanga:

On 06/11/15 07:29 PM, Ralf Corsepius wrote:

But if upstream doesn't care, it's going to be a
problem. :-(

Exactly - That's the actual problem. Upstream does not care
and Fedora
seems unable to address this issue.

Ralf

According to my system, it has SSSE3. Is it SSE3?
Taken from A10-7400P laptop

any system not older than 10 years has SSE3 and frankly systems
older than 10 years are hardly a traget for Fedora at all

On the other hand, my >10 year-old 32-bit system (Fedora 22) is the only
place my LaserJet 4L printer works. My 64-bit systems drop control
sequences (like they don't flush the output buffer), leaving the last
page of every job sitting in printer memory. I reported the bug a few
years ago, but it got closed as WONTFIX and now I can't find it in bugzilla


we talk about a *bleeding edge distribution*

https://en.wikipedia.org/wiki/HP_LaserJet_4#4L_and_4P
"The LaserJet 4 series was discontinued in the 1990s"

why in the world does somebody install a operating system released in 
2015 to drive harwdare realeased 10-15 years ago and *why in the world* 
should recent hardware feautures ignored forever because of users with 
such hardware?


you CAN NOT HAVE both - leading edge software and legacy support forever

that's the same disucssion as others have with "my PHP crap don't work 
with anything above PHP 5.2 so why can't i have newest software *but 
not* recent PHP




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Stephen John Smoogen]

On 11 November 2015 at 13:20, Fred New  wrote:
>
>
> On Sat, Nov 7, 2015 at 6:03 AM, Reindl Harald 
> wrote:
>>
>>
>>
>> Am 07.11.2015 um 05:00 schrieb Luya Tshimbalanga:
>>>
>>> On 06/11/15 07:29 PM, Ralf Corsepius wrote:
>
> But if upstream doesn't care, it's going to be a problem. :-(

 Exactly - That's the actual problem. Upstream does not care and Fedora
 seems unable to address this issue.

 Ralf

>>> According to my system, it has SSSE3. Is it SSE3?
>>> Taken from A10-7400P laptop
>>
>>
>> any system not older than 10 years has SSE3 and frankly systems older than
>> 10 years are hardly a traget for Fedora at all
>>
> On the other hand, my >10 year-old 32-bit system (Fedora 22) is the only
> place my LaserJet 4L printer works. My 64-bit systems drop control sequences
> (like they don't flush the output buffer), leaving the last page of every
> job sitting in printer memory. I reported the bug a few years ago, but it
> got closed as WONTFIX and now I can't find it in bugzilla.
>

I don't doubt it is WONTFIX :).

That printer is old enough to vote and drink in the United States.
Depending on how the printer is connected to the computer you would
need either a parallel port debugger or whatever monstrosity is
converting USB to RS232 (if you are using serial input).. or SCSI?

At a certain point this sort of hardware can only be supported if
there are owners who can do the kind of work needed to make it work.
Which usually means that at some point you move off of the
'cutting/bleeding' edge distributions to something like Debian or
CentOS 5.

-- 
Stephen J Smoogen.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Felix Miata]

Reindl Harald composed on 2015-11-11 22:10 (UTC+0100):

> when you and the other 5 users think they can demand support for ancient 
> hardware forever because these days cheap hardware is too much cost i 
> tell you that my lifetime for adpot a ton of regressions cuased by 
> replacing perfect fine working software with half baken replacements is 
> *much more* worth because you can buy reasonable hardware, i can't buy 
> additional lifetime wasted over the last years by braindead software 
> decisions

Must be nice to be affluent. This thread proves you simply don't get that not
everyone is in position to buy, buy, buy to replace what ain't broke just
because marketers and manufacturers have something ostensibly better to
offer. Many, many many have no choice but to make do with whatever they have
or can acquire without money. They too want to do the best they can with what
they have or can get without money, meaning for many, first choice would not
be a yesteryear distro. Compatibililty with more blessed peers or for other
reasons may be necessary, and dictate at least some "bleeding edge" software.
-- 
"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/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Reindl Harald]

Am 11.11.2015 um 21:54 schrieb Reindl Harald:


Am 11.11.2015 um 21:20 schrieb Fred New:

On Sat, Nov 7, 2015 at 6:03 AM, Reindl Harald 10 year-old 32-bit system (Fedora 22) is the only
place my LaserJet 4L printer works. My 64-bit systems drop control
sequences (like they don't flush the output buffer), leaving the last
page of every job sitting in printer memory. I reported the bug a few
years ago, but it got closed as WONTFIX and now I can't find it in
bugzilla


we talk about a *bleeding edge distribution*

https://en.wikipedia.org/wiki/HP_LaserJet_4#4L_and_4P
"The LaserJet 4 series was discontinued in the 1990s"

why in the world does somebody install a operating system released in
2015 to drive harwdare realeased 10-15 years ago and *why in the world*
should recent hardware feautures ignored forever because of users with
such hardware?

you CAN NOT HAVE both - leading edge software and legacy support forever

that's the same disucssion as others have with "my PHP crap don't work
with anything above PHP 5.2 so why can't i have newest software *but
not* recent PHP


and to make it clear:

when you and the other 5 users think they can demand support for ancient 
hardware forever because these days cheap hardware is too much cost i 
tell you that my lifetime for adpot a ton of regressions cuased by 
replacing perfect fine working software with half baken replacements is 
*much more* worth because you can buy reasonable hardware, i can't buy 
additional lifetime wasted over the last years by braindead software 
decisions




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Stephen John Smoogen]

On 11 November 2015 at 14:10, Reindl Harald  wrote:
>
> Am 11.11.2015 um 21:54 schrieb Reindl Harald:
>>
>>
>> Am 11.11.2015 um 21:20 schrieb Fred New:
>>>
>>> On Sat, Nov 7, 2015 at 6:03 AM, Reindl Harald >> any system not older than 10 years has SSE3 and frankly systems
>>> older than 10 years are hardly a traget for Fedora at all
>>>
>>> On the other hand, my >10 year-old 32-bit system (Fedora 22) is the only
>>> place my LaserJet 4L printer works. My 64-bit systems drop control
>>> sequences (like they don't flush the output buffer), leaving the last
>>> page of every job sitting in printer memory. I reported the bug a few
>>> years ago, but it got closed as WONTFIX and now I can't find it in
>>> bugzilla
>>
>>
>> we talk about a *bleeding edge distribution*
>>
>> https://en.wikipedia.org/wiki/HP_LaserJet_4#4L_and_4P
>> "The LaserJet 4 series was discontinued in the 1990s"
>>
>> why in the world does somebody install a operating system released in
>> 2015 to drive harwdare realeased 10-15 years ago and *why in the world*
>> should recent hardware feautures ignored forever because of users with
>> such hardware?
>>
>> you CAN NOT HAVE both - leading edge software and legacy support forever
>>
>> that's the same disucssion as others have with "my PHP crap don't work
>> with anything above PHP 5.2 so why can't i have newest software *but
>> not* recent PHP
>
>
> and to make it clear:
>
> when you and the other 5 users think they can demand support for ancient

Harald, he didn't demand anything. He just stated what he was using
and why. You need to back the angry sysadmin a bit :). Save it for
when someone wants to know why they can't get their Leading Edge i386
to work with Fedora anymore and what the developers are going to do
about it or else he will post nasty notes to slashdot.

> hardware forever because these days cheap hardware is too much cost i tell
> you that my lifetime for adpot a ton of regressions cuased by replacing
> perfect fine working software with half baken replacements is *much more*
> worth because you can buy reasonable hardware, i can't buy additional
> lifetime wasted over the last years by braindead software decisions
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct



-- 
Stephen J Smoogen.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Reindl Harald]

Am 11.11.2015 um 22:35 schrieb Felix Miata:

Reindl Harald composed on 2015-11-11 22:10 (UTC+0100):


when you and the other 5 users think they can demand support for ancient
hardware forever because these days cheap hardware is too much cost i
tell you that my lifetime for adpot a ton of regressions cuased by
replacing perfect fine working software with half baken replacements is
*much more* worth because you can buy reasonable hardware, i can't buy
additional lifetime wasted over the last years by braindead software
decisions


Must be nice to be affluent. This thread proves you simply don't get that not
everyone is in position to buy, buy, buy to replace what ain't broke just
because marketers and manufacturers have something ostensibly better to
offer. Many, many many have no choice but to make do with whatever they have
or can acquire without money. They too want to do the best they can with what
they have or can get without money, meaning for many, first choice would not
be a yesteryear distro. Compatibililty with more blessed peers or for other
reasons may be necessary, and dictate at least some "bleeding edge" software


it's not a matter of be affluent

if buying every decade a new computer is too uch just don't demand 
bleeding edge software runs on yours and use a LTS distribution - is 
that really so hard to understand?





signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Felix Miata]

Reindl Harald composed on 2015-11-11 22:44 (UTC+0100):

> Felix Miata composed:

>> Must be nice to be affluent. This thread proves you simply don't get that not
>> everyone is in position to buy, buy, buy to replace what ain't broke just
>> because marketers and manufacturers have something ostensibly better to
>> offer. Many, many many have no choice but to make do with whatever they have
>> or can acquire without money. They too want to do the best they can with what
>> they have or can get without money, meaning for many, first choice would not
>> be a yesteryear distro. Compatibililty with more blessed peers or for other
>> reasons may be necessary, and dictate at least some "bleeding edge" software

> it's not a matter of be affluent

Affluence is relative. If you don't have money, you don't buy new stuff,
especially to replace working stuff.

> if buying every decade a new computer is too uch just don't demand 

What's magical about a decade? Nothing. It's arbitrary. People last more than
a decade. Cars last more than a decade. Houses last more than a decade.
Refrigerators last more than a decade. No good reason a PC can't last more
than a decade before polluting a landfill.

> bleeding edge software runs on yours and use a LTS distribution - is 
> that really so hard to understand?

You seem unable to understand that there are far more than a few easily
classifiable use cases, or that bleeding edge doesn't imply being first to
tell computer users (or let them find out the hard way) theirs are too old
for continuing to use the distro they've been using and are used to and/or
prefer and/or shared with those they need or want to maintain maximum
compatibility with.
-- 
"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/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Reindl Harald]

Am 10.11.2015 um 00:52 schrieb Alexander Ploumistos:

On Tue, Nov 10, 2015 at 1:34 AM, Reindl Harald  wrote:

about money: with the energy costs i saved going away from P4 computers many
years ago my current one is already paied


Nobody is saying that a newer computer won't save you money on the
power bill. What they have repeatedly stated and for some (first
world, perhaps?) reason you refuse to acknowledge, is that you can't
trade future power use for a new computer; you have to pay up front,
it's a sort of investment, that not everyone is affluent enough to
make. Not every person or institution can afford to get a new Phenom
or Xeon or whatever every year, or even every X years.
What exactly do you suggest these people do? Get LFS, Gentoo or Arch
and clear all incompatible flags? Or should they apply for a loan to
their bank, detailing the ROI from reduced power usage?


i would suggest NOT use a fast moving distribution like Fedora for such 
antique hardware


why do you ask again when i statet *more than once* that i have zero 
understaind for combine more than 10 years old hardware with a 
bleeding-edge distribution and then demand the bleeding-edge 
distribution to support that hardware the next 20 years instead move forward




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Petr Pisar]

On 2015-11-09, Reindl Harald  wrote:
> server spin "maybe you are using the wrong operating system" and frankly
> for schools you typically use thin-cients one machine
>
Unfortunatelly recent desktop environments require OpenGL. Recent web
pages require hardware-accelareted video decoding. Not so recent widget
toolkits started to use pixmaps instead of X server-side rendering. Users
want to use sound output and USB devices.

This makes thin clients really hard to implement. Especially if all the
network-oriented features Linux deskop had are becoming obsolete.

What could work is a diskless thick client. But these old computers
usually have 100-Mbps NIC. That's 5 times slower than local ATA disk.
This does not matter when everything is loaded, but it hurts when
starting programs. Especially in classes where all students log in and
to the same stuff at the same time.

-- Petr

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Johannes Lips]

Please leave this thread alone. Since numerous days, nothing about the 
original subject has been added.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Kevin Kofler]

Kalev Lember wrote:
> I wonder if it might be a good time to bump the i686 minimal
> requirements for F24 to include sse2. Not for performance reasons, but
> for compatibility: almost all developers are on x86_64 these days and
> i686 is pretty much just limping along. If we include sse2 on i686, that
> removes another difference between x86_64 and i686 and makes things
> easier for us as a downstream.

I don't think this difference is a real issue.

> Apparently quite a few upstreams these days consider sse2 as a minimal
> requirement and it seems more and more that Fedora packagers need to
> work this around if we don't follow the lead.

This is more of a problem.

This is only a minor annoyance where a portable fallback exists (we can just 
ship the portable C/C++ version in /usr/lib and the SSE2 version in 
/usr/lib/sse2, as we are doing with Qt 5 QtDeclarative). The real problem is 
software which has no portable fallback at all, such as Chromium/QtWebEngine 
or Darktable. This completely screws not only non-SSE2 x86, but also all 
secondary architectures, and in some cases such as Darktable, even the 
primary architecture ARM. It is unfortunate that the number of such non-
portable software seems increasing lately. Portability to any and all CPU 
architectures used to be a big selling point for Free Software. These days, 
more and more projects seem happy to sacrifice this on the altar of 
performance. :-(

I think dropping support for non-SSE2 in all of Fedora would send entirely 
the wrong message to those upstreams and only contribute to the surge of 
non-portable software.

That said, we need a formal policy to deal with such software, which IMHO 
should be treated just like an ExcludeArch, except that you should not 
actually ExcludeArch the package as long as it supports SOME CPUs of that 
architecture. It should still be put on the relevant ExcludeArch tracker 
though, and if a fix/workaround exists, applying it should be required.

> I don't think this is worth doing for performance reasons. I don't think
> a few percentage of possible gain in micro benchmarks is worth it, but
> if it saves some hundreds of hours of developer time for people who are
> working on Fedora and don't have to work around missing sse2, I'd say
> it's very well worth the cost of losing ancient CPU support.

That would unfortunately decrease the usefulness of the i686 distribution a 
lot. Given that we want to push users of 64-bit-capable machines to the 
x86_64 version, it would leave basically only one generation of x86 machines 
for the i686 distribution: the Pentium 4 Northwood generation, including one 
or two generation(s) of AMD CPUs from the same time. Add to that some newish 
low-end Atoms where they removed x86_64 support "to save power" (actually to 
introduce an artificial market segmentation), no idea how popular those are. 
Everything else that has SSE2 also has 64-bit.

Unfortunately, that prerogative ("all 64-bit-capable machines should use 64-
bit binaries") is not universally shared by upstreams. For example, Qt sees 
the primary target of their 32-binaries as being modern machines that would 
also support x86_64, but where the user elected to use 32-bit for whatever 
reason, not old 32-bit-only machines as we see it. That is the primary 
reason for the different stance on non-SSE2 support. (That said, Qt, outside 
of QtWebEngine, does not actually REQUIRE SSE2. They just enable its use by 
default.) My argument that the default option ought to be the safe, portable 
one (non-SSE2) was rejected on the grounds of performance on what they think 
are the vast majority of machines using 32-bit Qt (whereas I argued that it 
was only really one generation, but as I wrote above, they have a completely 
different conception of the purpose of 32-bit binaries).

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Kevin Kofler]

Rex Dieter wrote:
> Qt5 (Gui and Declarative) pretty much requires sse2, and I/kde-sig asked
> about pushing the minimum i686 fedora spec to include sse2, but fesco was
> against that idea at the time.

For what it's worth, I was against it. Using /usr/lib/sse2 as we do now 
works just fine as a solution to this problem. People without SSE2 at least 
get a distribution that works for them, and even Qt 5 builds (except the 
soon-to-be-packaged QtWebEngine module, sadly, unless/until something 
happens at its upstream to fix the V8 non-portability) that work, albeit 
slowly. LXQt should even work at an acceptable speed, given that they use 
QtWidgets for their UI, which does not need the QML 2 interpreter or JIT (so 
you don't get the non-JIT interpreter). And people with SSE2 get SSE2-
optimized .so binaries where it matters.

The only thing the duplication costs is some disk space, but that is the 
price of portability.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Reindl Harald]

Am 09.11.2015 um 22:31 schrieb Samuel Sieb:

On 11/07/2015 10:23 AM, Reindl Harald wrote:

these days (and i talk about hardware from 2011) you can virtualize
things fast, easy and efficient and consolidate machines on more or less
cheap hardware


For servers, sure, but that doesn't work for desktops.


how many physical desktops does one use?


talking about a rapid moving distribution like Fedora and at the same
time hestitate to use technology available for a decade is strange - i
guess people plan to run their hardware for 10, 12, 15 years are not
using typically a distribution like Fedora


I manage all the IT for a private school.  There is a computer lab for
the students to use.  They don't have the money to buy new computers,
the computers they have were donated.  They are P4 desktops from around
2005 and they have SSE2.  I install Fedora on all the computers and
laptops there that I manage. (The older students manage their own
laptops, but even some of them want Fedora installed as well.)  I
upgraded all the P4 desktops to 2GB RAM and with F22 using a non-3D WM
they work perfectly for student use.

So yes, I'm using 10 year old hardware with the latest Fedora and it
works great.  (I'll update them to F23 next time I'm there.)


SSE3 was introduced in 2004

well, i tell you know the same which was told me all the time before the 
server spin "maybe you are using the wrong operating system" and frankly 
for schools you typically use thin-cients one machine


with the agrumentations of this thread hardware manufactuers could stop 
develop new hardware capabilities if we wait 20 years to consider make 
them default - in the IT 10 years is virtually forever and *yes* capable 
hardware these days is cheap if you don't need that much performance




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Samuel Sieb]

On 11/07/2015 10:23 AM, Reindl Harald wrote:

these days (and i talk about hardware from 2011) you can virtualize
things fast, easy and efficient and consolidate machines on more or less
cheap hardware


For servers, sure, but that doesn't work for desktops.


talking about a rapid moving distribution like Fedora and at the same
time hestitate to use technology available for a decade is strange - i
guess people plan to run their hardware for 10, 12, 15 years are not
using typically a distribution like Fedora

I manage all the IT for a private school.  There is a computer lab for 
the students to use.  They don't have the money to buy new computers, 
the computers they have were donated.  They are P4 desktops from around 
2005 and they have SSE2.  I install Fedora on all the computers and 
laptops there that I manage. (The older students manage their own 
laptops, but even some of them want Fedora installed as well.)  I 
upgraded all the P4 desktops to 2GB RAM and with F22 using a non-3D WM 
they work perfectly for student use.


So yes, I'm using 10 year old hardware with the latest Fedora and it 
works great.  (I'll update them to F23 next time I'm there.)

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Reindl Harald]

Am 09.11.2015 um 23:57 schrieb Samuel Sieb:

On 11/09/2015 02:22 PM, Reindl Harald wrote:

Am 09.11.2015 um 22:31 schrieb Samuel Sieb:

So yes, I'm using 10 year old hardware with the latest Fedora and it
works great.  (I'll update them to F23 next time I'm there.)


well, i tell you know the same which was told me all the time before the
server spin "maybe you are using the wrong operating system" and frankly
for schools you typically use thin-cients one machine


I really wonder where you come from.  I have never seen a grade school,
public or private, that uses thin-clients


http://www8.hp.com/us/en/thin-clients/education.html


As for "wrong operating
system", do you have any suggestions for a different distribution that
is as up-to-date as Fedora that would work on these computers?


i don't get why i need the most up-to-date software when at the same 
time i don't care about my hardware and run a P4 heater because that 
indicates low requirements


about money: with the energy costs i saved going away from P4 computers 
many years ago my current one is already paied



I've always run Fedora on my servers as well


me too






signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Samuel Sieb]

On 11/09/2015 02:22 PM, Reindl Harald wrote:

Am 09.11.2015 um 22:31 schrieb Samuel Sieb:

I manage all the IT for a private school.  There is a computer lab for
the students to use.  They don't have the money to buy new computers,
the computers they have were donated.  They are P4 desktops from around
2005 and they have SSE2.  I install Fedora on all the computers and
laptops there that I manage. (The older students manage their own
laptops, but even some of them want Fedora installed as well.)  I
upgraded all the P4 desktops to 2GB RAM and with F22 using a non-3D WM
they work perfectly for student use.

So yes, I'm using 10 year old hardware with the latest Fedora and it
works great.  (I'll update them to F23 next time I'm there.)


well, i tell you know the same which was told me all the time before the
server spin "maybe you are using the wrong operating system" and frankly
for schools you typically use thin-cients one machine

I really wonder where you come from.  I have never seen a grade school, 
public or private, that uses thin-clients.  As for "wrong operating 
system", do you have any suggestions for a different distribution that 
is as up-to-date as Fedora that would work on these computers?


I've always run Fedora on my servers as well.


with the agrumentations of this thread hardware manufactuers could stop
develop new hardware capabilities if we wait 20 years to consider make
them default - in the IT 10 years is virtually forever and *yes* capable
hardware these days is cheap if you don't need that much performance

"Cheap"?  I might be able to able to build a computer for $300, I 
haven't actually checked lately, that's what it was a few years ago. 
But for a computer lab?  Why would they want to try to come up with that 
much money when the existing computers work perfectly?

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Felix Miata]

Reindl Harald composed on 2015-11-09 23:22 (UTC+0100):

> *yes* capable hardware these days is cheap if you don't need that much 
> performance

Unless and until hardware prices drop to zero, there will be users for whom
any cost is an insurmountable hurdle. And, there will remain users content
with existing capability who only wish to upgrade software in order to
maintain security and/or access to software demanded by their needs. Ordinary
users don't care when SSE3 was introduced. They just want to keep using what
ain't broke as long as possible. Many don't see justification for capability
of newer hardware causing software to demand that capability either,
particularly when it breaks arch portability or produces no more than a
modest, or no, detectable performance improvement, among them, me.
-- 
"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/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Alexander Ploumistos]

On Tue, Nov 10, 2015 at 1:34 AM, Reindl Harald  wrote:
> about money: with the energy costs i saved going away from P4 computers many
> years ago my current one is already paied

Nobody is saying that a newer computer won't save you money on the
power bill. What they have repeatedly stated and for some (first
world, perhaps?) reason you refuse to acknowledge, is that you can't
trade future power use for a new computer; you have to pay up front,
it's a sort of investment, that not everyone is affluent enough to
make. Not every person or institution can afford to get a new Phenom
or Xeon or whatever every year, or even every X years.
What exactly do you suggest these people do? Get LFS, Gentoo or Arch
and clear all incompatible flags? Or should they apply for a loan to
their bank, detailing the ROI from reduced power usage?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Samuel Sieb]

On 11/09/2015 03:34 PM, Reindl Harald wrote:



Am 09.11.2015 um 23:57 schrieb Samuel Sieb:

On 11/09/2015 02:22 PM, Reindl Harald wrote:

Am 09.11.2015 um 22:31 schrieb Samuel Sieb:

So yes, I'm using 10 year old hardware with the latest Fedora and it
works great.  (I'll update them to F23 next time I'm there.)


well, i tell you know the same which was told me all the time before the
server spin "maybe you are using the wrong operating system" and frankly
for schools you typically use thin-cients one machine


I really wonder where you come from.  I have never seen a grade school,
public or private, that uses thin-clients


http://www8.hp.com/us/en/thin-clients/education.html

I didn't say they didn't exist.  I've certainly heard of them and seen 
them in various places.  I said in all the schools I've been in, I've 
never seen any actually deployed.



As for "wrong operating
system", do you have any suggestions for a different distribution that
is as up-to-date as Fedora that would work on these computers?


i don't get why i need the most up-to-date software when at the same
time i don't care about my hardware and run a P4 heater because that
indicates low requirements

What does low requirements have to do with up-to-date software?  Why 
should I have to use an old version of LibreOffice just because I'm 
using a 10 year old computer when the latest version works perfectly well?



about money: with the energy costs i saved going away from P4 computers
many years ago my current one is already paied

I would be very surprised if the power savings are really that much.  I 
will do a power check the next time I'm on site.  Besides that, 
electricity is cheap here so it would take a very long time to recoup 
the cost of new computers.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Reindl Harald]

Am 08.11.2015 um 11:56 schrieb drago01:

On Sun, Nov 8, 2015 at 10:35 AM, Reindl Harald  wrote:

There is no such thing as "the complete distribution" ... the flags
used to compile libreoffice won't affect http or firefox


surely, there is such a thing

on a typical machine is running way more than a single application, you have
(growing) background-noise, currently plasma-desktop eats 25-30% of a core,
X eats some percent and so on


That sounds like a bug. Throwing in some compiler flags won't fix that.
Fixing that requires 1) finding out what it is doing (profile and/or
get stack traces) 2) fix the code


software is full of bugs (KDE5 is overwhelmed) all the time and you 
missed the point because "used to compile libreoffice won't affect http 
or firefox" is simply wrong on a MULTITASKING system sharing one CPU and 
so each application will affect others at the end of the day




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Reindl Harald]

Am 08.11.2015 um 09:47 schrieb drago01:

On Sat, Nov 7, 2015 at 9:24 PM, Reindl Harald  wrote:

Am 07.11.2015 um 20:36 schrieb drago01:


On Sat, Nov 7, 2015 at 7:40 PM, Reindl Harald 
wrote:


the point is compile a single application with new features won't gain
that
muc 8until you do the same with most libraries used by the software) but
having the whole distribution is a summary with a completly different
behavior than a single test of software xyz



Uh no you just have to compile the software any libraries used by the
hot paths of the software you are trying to test.



for which one?
that don't show the impact on a complete distribution anyways


There is no such thing as "the complete distribution" ... the flags
used to compile libreoffice won't affect http or firefox


surely, there is such a thing

on a typical machine is running way more than a single application, you 
have (growing) background-noise, currently plasma-desktop eats 25-30% of 
a core, X eats some percent and so on


htop shows 7-10%  i7-3770 CPU @ 3.40GHz by doing *nothing* expect write 
that mail and listen to a MP3 file in the background


the distribution flags are going to be interesting when each of this 
pieces is more efficient while you are doing CPU intense tasks also 
working more efficient




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Rex Dieter]

Felix Miata wrote:

>  For those without
> SSE2, Plasma 5 is completely unusable, but OK with any of the lightweigh

.

Qt5 (Gui and Declarative) pretty much requires sse2, and I/kde-sig asked 
about pushing the minimum i686 fedora spec to include sse2, but fesco was 
against that idea at the time.

-- Rex

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Kalev Lember]

On 11/08/2015 10:17 PM, Rex Dieter wrote:
> Felix Miata wrote:
> 
>>  For those without
>> SSE2, Plasma 5 is completely unusable, but OK with any of the lightweigh
> 
> .
> 
> Qt5 (Gui and Declarative) pretty much requires sse2, and I/kde-sig asked 
> about pushing the minimum i686 fedora spec to include sse2, but fesco was 
> against that idea at the time.

I wonder if it might be a good time to bump the i686 minimal
requirements for F24 to include sse2. Not for performance reasons, but
for compatibility: almost all developers are on x86_64 these days and
i686 is pretty much just limping along. If we include sse2 on i686, that
removes another difference between x86_64 and i686 and makes things
easier for us as a downstream.

Apparently quite a few upstreams these days consider sse2 as a minimal
requirement and it seems more and more that Fedora packagers need to
work this around if we don't follow the lead.

I don't think this is worth doing for performance reasons. I don't think
a few percentage of possible gain in micro benchmarks is worth it, but
if it saves some hundreds of hours of developer time for people who are
working on Fedora and don't have to work around missing sse2, I'd say
it's very well worth the cost of losing ancient CPU support.

-- 
Kalev
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[drago01]

On Sun, Nov 8, 2015 at 10:20 PM, Reindl Harald  wrote:
>
>
> Am 08.11.2015 um 22:17 schrieb Rex Dieter:
>>
>> Felix Miata wrote:
>>
>>>   For those without
>>> SSE2, Plasma 5 is completely unusable, but OK with any of the lightweigh
>>
>>
>> .
>>
>> Qt5 (Gui and Declarative) pretty much requires sse2, and I/kde-sig asked
>> about pushing the minimum i686 fedora spec to include sse2, but fesco was
>> against that idea at the time
>
>
> that was years ago, -msse2 is now the default

No as I said before its not. (Note the "i686").
On x86_64 you don't have to pass -msee2. SSE2 is part of the x86_64 ABI.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Reindl Harald]

Am 08.11.2015 um 22:21 schrieb drago01:

On Sun, Nov 8, 2015 at 10:20 PM, Reindl Harald  wrote:


Am 08.11.2015 um 22:17 schrieb Rex Dieter:


Felix Miata wrote:


   For those without
SSE2, Plasma 5 is completely unusable, but OK with any of the lightweigh


Qt5 (Gui and Declarative) pretty much requires sse2, and I/kde-sig asked
about pushing the minimum i686 fedora spec to include sse2, but fesco was
against that idea at the time



that was years ago, -msse2 is now the default


No as I said before its not. (Note the "i686").
On x86_64 you don't have to pass -msee2. SSE2 is part of the x86_64 ABI


indeed, the defaults even don't contain -msse2 in 2015
ridiculous

[builduser@buildserver64:~]$ cat /usr/lib/rpm/rpmrc | grep i686
optflags: i386 -O2 -g -march=i386 -mtune=i686



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Reindl Harald]

Am 08.11.2015 um 22:17 schrieb Rex Dieter:

Felix Miata wrote:


  For those without
SSE2, Plasma 5 is completely unusable, but OK with any of the lightweigh


.

Qt5 (Gui and Declarative) pretty much requires sse2, and I/kde-sig asked
about pushing the minimum i686 fedora spec to include sse2, but fesco was
against that idea at the time


that was years ago, -msse2 is now the default
that thread is about -msse3 available for a full decade



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[drago01]

On Sun, Nov 8, 2015 at 10:35 AM, Reindl Harald  wrote:
>
>
> Am 08.11.2015 um 09:47 schrieb drago01:
>>
>> On Sat, Nov 7, 2015 at 9:24 PM, Reindl Harald 
>> wrote:
>>>
>>> Am 07.11.2015 um 20:36 schrieb drago01:


 On Sat, Nov 7, 2015 at 7:40 PM, Reindl Harald 
 wrote:
>
>
> the point is compile a single application with new features won't gain
> that
> muc 8until you do the same with most libraries used by the software)
> but
> having the whole distribution is a summary with a completly different
> behavior than a single test of software xyz



 Uh no you just have to compile the software any libraries used by the
 hot paths of the software you are trying to test.
>>>
>>>
>>>
>>> for which one?
>>> that don't show the impact on a complete distribution anyways
>>
>>
>> There is no such thing as "the complete distribution" ... the flags
>> used to compile libreoffice won't affect http or firefox
>
>
> surely, there is such a thing
>
> on a typical machine is running way more than a single application, you have
> (growing) background-noise, currently plasma-desktop eats 25-30% of a core,
> X eats some percent and so on

That sounds like a bug. Throwing in some compiler flags won't fix that.
Fixing that requires 1) finding out what it is doing (profile and/or
get stack traces) 2) fix the code.

> htop shows 7-10%  i7-3770 CPU @ 3.40GHz by doing *nothing* expect write that
> mail and listen to a MP3 file in the background

The mp3 playback is already making use of SIMD instructions.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[drago01]

On Sat, Nov 7, 2015 at 9:24 PM, Reindl Harald  wrote:
>
>
> Am 07.11.2015 um 20:36 schrieb drago01:
>>
>> On Sat, Nov 7, 2015 at 7:40 PM, Reindl Harald 
>> wrote:
>>>
>>> the point is compile a single application with new features won#t gain
>>> that
>>> muc 8until you do the same with most libraries used by the software) but
>>> having the whole distribution is a summary with a completly different
>>> behavior than a single test of software xyz
>>
>>
>> Uh no you just have to compile the software any libraries used by the
>> hot paths of the software you are trying to test.
>
>
> for which one?
> that don't show the impact on a complete distribution anyways

There is no such thing as "the complete distribution" ... the flags
used to compile libreoffice won't affect http or firefox.

>>> if there would be no difference kernel upstream won't invest that much
>>> time
>>> for runtime-cpu-detection (look at the bootlog on different hardware)
>>>
>>> here are examples
>>> http://www.phoronix.com/scan.php?page=news_item=MTU0MTY
>>> http://www.phoronix.com/scan.php?page=news_item=MTI1Njc
>>
>>
>> You missed the point completely.
>>
>> 1. AVX != (S)SSE3
>
>
> i know that

Then don't cite unrelated links.

>> There are lots of workloads that would benefit from AVX but SSE3
>> doesn't add that much  (enabling SSE2 on i686 would gain you more for
>> instance).
>
>
> enable SSE3 don't diable SSE2
> so "gain you more" is impossible

I meant "i686 + SSE2" (which we don't do for the same reason) gains
more than "x86_64 + sse3".

>> 2. Runtime detection does not have the cost of dropping support for
>> specific hardware
>
>
> runtime detection needs to be implemented in every relevant software at it's
> own and hence has a *high cost*

Not really its a common practice for software that does matter; even
glibc does it.

> add -msse3 to the default falgs have no costs at all but only an impact of a
> unknown amount f *very* outdated hardware which is unlikely running a
> bleeding edge distribution

As you just wrote in that very paragraph the cost is dropping support
for a set of hardware.
We have no numbers on how much if at all it would help.

> frankly whatever somebody has run on a 10 years old machine can be easily
> virtualized and i doubt that many people have a 10 years old computer as
> their only device, as far there is something with a core2 or newer in the
> house you can virtualize the other machine and save a lot of energy

Depends on the device. Virtualizing a laptop for instance won't make much sense.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Germano Massullo]

A few lines of IRC chat, Freenode #darktable. Hanatos is Darktable
project founder.


[09:17]  ``requiring SSE3 is not really allowed ''
[09:17]  so much bundled cluelessness :/
[09:19]  Germano: re 32-bit
[09:19]  the sse thing is one thing
[09:20]  the other is the very limited virtual address space
(2G really)
[09:20]  everybody coding anything half way serious will tell
you the same story
[09:20]  (rawtherapee has the same issues iirc)
[09:20]  our old cache was allocing one big chunk of memory at
startup and maintained it manually
[09:20]  essentially duplicating a poor man's malloc,
specialised for our thumbnail caches
[09:21]  the new cache is much faster and easier to read
[09:21]  but based on malloc/free
[09:21]  which means your virtual address space (not the
physical one mapping to your ram)
[09:21]  will get fragmented and you quickly start addressing
blocks above the 10G range
[09:22]  which may not be a problem, even on systems with only
2G of physical ram, because blocks have been freed in between. it's just
on 32-bit systems you can't address it any more and die
[09:22]  basically, at this point, DT makes no sense on x86,
except maybe dt-cli
[09:22]  which is a similar argument as the sse3 is.
[09:22]  it's just not a worthwhile experience running this
software on this kind of hardware
[09:22]  boucman: yes, that.
[09:23]  hanatos_: I think jmalloc is also more clever than
glibc malloc wrt fragmentation. that's why blender uses it, afaik
[09:24]  *je
[09:24]  Germano: so i'd like to contradict the `upstream
doesn't care' bit
[09:25]  upstream does care.
[09:25]  just not about random principles and guidelines
[09:25]  but about how well darktable runs
[09:25]  Artefact2: jemalloc you mean
[09:25]  hanatos_: yes
[09:25]  yes, it's mostly multithreaded/
[09:25]  block per thread
[09:25]  might be worthwhile when running many threads for
thumbnail gen
[09:25]  but honestly i doubt it
[09:26]  it speeds up another piece of code i wrote
[09:26]  which uses many 10s of 1000s of malloc calls per second..
[09:26]  we don't do that in dt
[09:26]  (or tcmalloc for that matter)
[09:26]  simple enough to try with an LD_PRELOAD
[09:26]  oh yeah. calling malloc this many times is a bad
idea anyway
[09:32]  the alternative would have been allocate ridiculous
amounts of memory up front
[09:32]  bad idea, too
[09:32]  but if you have a better solution i'd sure like to
hear it :)
[09:32]  the problem is to construct a binary search tree
[09:32]  i'm not a memory guru, sadly :|
[09:32]  in parallel
[09:32]  so you start at the root and push the children as new
jobs (malloc job_t)
[09:32]  and so on
[09:33]  it's millions of nodes total, so you don't want to
allocate them up front
[09:33]  maybe a compromise. allocate a pool that can store,
say 10 jobs at a time
[09:34]  (and yes, i would agree.. calling malloc is almost
always a bad idea, unless you can't avoid it)
[09:34]  but see.. that pool per thread.. that's exactly what
jemalloc/tcmalloc do
[09:34]  this way you reduce the allocator load by a factor
of 10, while still not allocating huge amounts of contiguous memory
[09:35]  maybe the issue is elsewhere. what are you doing
millions of? is it possible to make "bigger" jobs and have less of them?
ie a smaller tree
[09:38]  nope, can't touch the tree
[09:38]  its some spatial acceleration structure for ray tracing
[09:39]  it's been optimised for fast ray tracing for many years
[09:39]  are we still talking about darktable? didn't know it
needed a raytracer
[09:40]  no, different piece of code.. as i said, i don't
think darktable needs thread-cached malloc
[10:11]  Germano: also feel free to refer those guys here to
us if they have questions. seems to me that some direct contact may be
better.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Reindl Harald]

Am 07.11.2015 um 16:01 schrieb Felix Miata:

Kevin Kofler composed on 2015-11-07 14:05 (UTC+0100):


Reindl Harald wrote:



come on and don't tell me 99% of i686 users have machines older than 10
years https://en.wikipedia.org/wiki/SSE3 because "ntel introduced SSE3
in early 2004 with the Prescott revision of their Pentium 4 CPU"


Any demarcation that is calendar based is purely arbitrary. 64 bit was
introduced far more than 10 years ago. There is plenty of 32 bit hardware
perfectly capable of doing what needs doing regardless of age. Not everyone
needs, or wants, the bloat that newer enables. Not everyone is "speed"
sensitive, while most are sensitive to the security that keeping current
provides


and these are the Fedora relevant users?

that machines are fare better served with CentOS (now there is even a 
i686 one while RHEL7 does not exist of 32bit) instead bleeding edge 
while i don't see a compelling reason that a bleeding edge distribution 
in 2015 ignores SSE3 while in the meantime SSE4.2/AVX/AVX2 where 
introduced for a handful of users


"I have approximately 40 Fedora installations on 32 bit CPUs" by one 
real computer and put them all inside virtual machines on top of it - 
problem solved - the power savings alone wil pay it!


our new DL380 has two Xeon(R) CPU E5-2643 v3 @ 3.40GHz, 128 GB RAM, runs 
the whole company 8 with a second node for failover) and consumes 115W 
power (average over 24 hours)




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Felix Miata]

Reindl Harald composed on 2015-11-07 16:12 (UTC+0100):

> Felix Miata composed:

>> Kevin Kofler composed on 2015-11-07 14:05 (UTC+0100):

>>> Reindl Harald wrote:

 come on and don't tell me 99% of i686 users have machines older than 10
 years https://en.wikipedia.org/wiki/SSE3 because "ntel introduced SSE3
 in early 2004 with the Prescott revision of their Pentium 4 CPU"

>> Any demarcation that is calendar based is purely arbitrary. 64 bit was
>> introduced far more than 10 years ago. There is plenty of 32 bit hardware
>> perfectly capable of doing what needs doing regardless of age. Not everyone
>> needs, or wants, the bloat that newer enables. Not everyone is "speed"
>> sensitive, while most are sensitive to the security that keeping current
>> provides

> and these are the Fedora relevant users?

Surely there are people who need relativly recent or current versions of
software other than web browsers who aren't concerned with speed or replacing
hardware at an arbitrary chronological age. Photographers using Darktable may
well be among them.

Under any given roof, it makes sense to keep all machines on the same OS when
practical. Who's to say a whole family or business should be using CentOS
because one machine is past its prime?
-- 
"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/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Kevin Kofler]

Ralf Corsepius wrote:
> Exactly - That's the actual problem. Upstream does not care and Fedora
> seems unable to address this issue.

I think the only way to really fix this package would be to track down and 
add patches reverting all commits like these:
http://redmine.darktable.org/projects/darktable/repository/revisions/a8f31a96385564303d98215f2c67313e69798bdd
http://redmine.darktable.org/projects/darktable/repository/revisions/2807ac99c0f415a174f6b6444cc7f4f154f7a108
…

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Felix Miata]

Kevin Kofler composed on 2015-11-07 14:05 (UTC+0100):

> Reindl Harald wrote:

>> come on and don't tell me 99% of i686 users have machines older than 10
>> years https://en.wikipedia.org/wiki/SSE3 because "ntel introduced SSE3
>> in early 2004 with the Prescott revision of their Pentium 4 CPU"

Any demarcation that is calendar based is purely arbitrary. 64 bit was
introduced far more than 10 years ago. There is plenty of 32 bit hardware
perfectly capable of doing what needs doing regardless of age. Not everyone
needs, or wants, the bloat that newer enables. Not everyone is "speed"
sensitive, while most are sensitive to the security that keeping current
provides.

FWIW, Prescott introduction roughly coincides with PCIe video slots replacing
AGP slots. Any motherboard with AGP likely is incapable of having a 64 bit
Intel CPU installed and supported by its BIOS.

>> those machines would not be able to run a recent Fedora due all the
>> bloat introduced over the years - try a system update with 512 MB and
>> shake your hands with the OOM-killer

> I have a computer without SSE3. It runs Fedora just fine. I initially had 1 
> GiB of RAM in it, I upgraded it to 3 GiB.

I have approximately 40 Fedora installations on 32 bit CPUs. About half of
those are on Prescotts. I'm unable to notice that those with more than 1G RAM
run any better than those with more RAM. I am able to notice that the older,
slower ones that do have SSE2 are able to run, but with Plasma 5, those are
very slow. Those do run respectably with lighter WMs/DEs. For those without
SSE2, Plasma 5 is completely unusable, but OK with any of the lightweights.
-- 
"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/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Reindl Harald]

Am 07.11.2015 um 16:40 schrieb Felix Miata:

Reindl Harald composed on 2015-11-07 16:12 (UTC+0100):

Felix Miata composed:

Any demarcation that is calendar based is purely arbitrary. 64 bit was
introduced far more than 10 years ago. There is plenty of 32 bit hardware
perfectly capable of doing what needs doing regardless of age. Not everyone
needs, or wants, the bloat that newer enables. Not everyone is "speed"
sensitive, while most are sensitive to the security that keeping current
provides



and these are the Fedora relevant users?


Surely there are people who need relativly recent or current versions of
software other than web browsers who aren't concerned with speed or replacing
hardware at an arbitrary chronological age. Photographers using Darktable may
well be among them.

Under any given roof, it makes sense to keep all machines on the same OS when
practical. Who's to say a whole family or business should be using CentOS
because one machine is past its prime?


well, who's to say that we stay forever on a level of CPU 
feature-support while there are instruction sets available for a whole 
decade which improve performance, save power in case you need fewer 
instructions doing the same work?


not that i say Fedora should go ahead and build with -mavx but a 
discussion about SSE3 in 2015 is really odd




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Reindl Harald]

Am 07.11.2015 um 05:41 schrieb Ralf Corsepius:

On 11/07/2015 05:03 AM, Reindl Harald wrote:


Am 07.11.2015 um 05:00 schrieb Luya Tshimbalanga:

On 06/11/15 07:29 PM, Ralf Corsepius wrote:

But if upstream doesn't care, it's going to be a problem. :-(

Exactly - That's the actual problem. Upstream does not care and Fedora
seems unable to address this issue.


According to my system, it has SSSE3. Is it SSE3?

That's what my question actually was about.


https://en.wikipedia.org/wiki/SSE3#CPUs_with_SSE3


I see ssse3 on all my x86_64ers, I see sse3 on my 32bit atoms, but I
don't know if ssse3 implies sse3 and I don't know what -msse3 actually
does to the instruction set when being used on x86_64ers and which
impact it has


https://en.wikipedia.org/wiki/SSE3#New_instructions


(-msse3 is not part of Fedora's gcc implicit CFLAGS).


and that is really sad because it wastes for 99.9% of users performance 
and hence i override the builds of perormance relevant software since 
years with optimized falgs while hat -fstack-protector-all in use long 
before Fedora supported and switched to -fstack-protector-strong


in other words: you get the small performance impact of hardening back 
by better utilize your existing hardware instead castrate your whole 
software to nostalgic decades



any system not older than 10 years has SSE3  and frankly systems older
than 10 years are hardly a traget for Fedora at all


So, Fedora or Linux as a resort to escape Windows on old HW is not a
Fedora target anymore?


come on and install a recent Fedora on such old machines, guess what 
SSE3 or not is your smallest problem




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Kevin Kofler]

Germano Massullo wrote:
> [09:22]  basically, at this point, DT makes no sense on x86,
> except maybe dt-cli

Well, I think that, in the absence of a real portability fix, building the 
package (with SSE3, or in general the minimum instruction set it supports) 
is better than ExcludeArch.

The goal of the portability policies is to make our packages useful to an as 
wide range of users as possible. If we interpret them as meaning that 
ExcludeArch is preferred to shipping a package that requires something like 
SSE3, they become counterproductive.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Kevin Kofler]

Reindl Harald wrote:
> come on and don't tell me 99% of i686 users have machines older than 10
> years https://en.wikipedia.org/wiki/SSE3 because "ntel introduced SSE3
> in early 2004 with the Prescott revision of their Pentium 4 CPU"
> 
> those machines would not be able to run a recent Fedora due all the
> bloat introduced over the years - try a system update with 512 MB and
> shake your hands with the OOM-killer

I have a computer without SSE3. It runs Fedora just fine. I initially had 1 
GiB of RAM in it, I upgraded it to 3 GiB.

> Fedora incompatible?
> 
> many software including the kernel has binary code for AVX and even AVX2
> and is using CPU runtime detection - using SSE3 instructions in a
> software is not bound to compiler flags and when a upstream developer
> don't care about 11 year old hardware you have to suck taht downstrem

What he means is that Fedora policies DO NOT allow REQUIRING those 
instruction sets. Runtime detection is of course fine.

The problem we are having now is upstream projects that do not support ANY 
kind of fallback, not even at compile time. (Those are also inherently non-
portable because they don't work on any other CPU architecture.) Chromium/V8 
is another such problem program.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Kevin Kofler]

Oh, and I forgot (sorry for replying to the same mail twice):

Ralf Corsepius wrote:
> ACK. Does anybody know if there are any x86_64/64bit-CPUs which do not
> support sse3?

The first Athlon64 CPUs did not support SSE3.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Pete Walter]

07.11.2015, 12:19, "Germano Massullo" :
> [10:11]  Germano: also feel free to refer those guys here to
> us if they have questions. seems to me that some direct contact may be
> better.

What those guys?

The only one who wants to kill off darktable is you, Germano. You almost 
succeeded last time and had it removed, before the community stepped in. Why 
are you trying to repeat it again?

Seriously. Just let darktable be.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Reindl Harald]

Am 07.11.2015 um 20:36 schrieb drago01:

On Sat, Nov 7, 2015 at 7:40 PM, Reindl Harald  wrote:

the point is compile a single application with new features won#t gain that
muc 8until you do the same with most libraries used by the software) but
having the whole distribution is a summary with a completly different
behavior than a single test of software xyz


Uh no you just have to compile the software any libraries used by the
hot paths of the software you are trying to test.


for which one?
that don't show the impact on a complete distribution anyways


if there would be no difference kernel upstream won't invest that much time
for runtime-cpu-detection (look at the bootlog on different hardware)

here are examples http://www.phoronix.com/scan.php?page=news_item=MTU0MTY
http://www.phoronix.com/scan.php?page=news_item=MTI1Njc


You missed the point completely.

1. AVX != (S)SSE3


i know that


There are lots of workloads that would benefit from AVX but SSE3
doesn't add that much  (enabling SSE2 on i686 would gain you more for
instance).


enable SSE3 don't diable SSE2
so "gain you more" is impossible


2. Runtime detection does not have the cost of dropping support for
specific hardware


runtime detection needs to be implemented in every relevant software at 
it's own and hence has a *high cost*


add -msse3 to the default falgs have no costs at all but only an impact 
of a unknown amount f *very* outdated hardware which is unlikely running 
a bleeding edge distribution


frankly whatever somebody has run on a 10 years old machine can be 
easily virtualized and i doubt that many people have a 10 years old 
computer as their only device, as far there is something with a core2 or 
newer in the house you can virtualize the other machine and save a lot 
of energy




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[drago01]

On Sat, Nov 7, 2015 at 7:40 PM, Reindl Harald  wrote:
>
>
> Am 07.11.2015 um 19:27 schrieb drago01:
>>
>> On Sat, Nov 7, 2015 at 7:23 PM, Reindl Harald 
>> wrote:
>>>
>>> maybe you did not get "not that i say Fedora should go ahead and build
>>> with
>>> -mavx" but we talk about SSE3
>>
>>
>> Compiling everything with sse3 does have a cost (dropping support for
>> some hardware) but what does it gain us?
>> Better performance in theory? To convince anyone you have to at least
>> provide numbers. Otherwise the discussion is a waste of time
>
>
> how do you expect to get such numbers?
>
> even if you test whatever application with -msse2 versus -msse3 mosdt parts
> of the operating system and the whole libraries are still built with only
> SSE2 support
>
> the point is compile a single application with new features won#t gain that
> muc 8until you do the same with most libraries used by the software) but
> having the whole distribution is a summary with a completly different
> behavior than a single test of software xyz

Uh no you just have to compile the software any libraries used by the
hot paths of the software you are trying to test.

> if there would be no difference kernel upstream won't invest that much time
> for runtime-cpu-detection (look at the bootlog on different hardware)
>
> here are examples http://www.phoronix.com/scan.php?page=news_item=MTU0MTY
> http://www.phoronix.com/scan.php?page=news_item=MTI1Njc

You missed the point completely.

1. AVX != (S)SSE3

There are lots of workloads that would benefit from AVX but SSE3
doesn't add that much  (enabling SSE2 on i686 would gain you more for
instance).

2. Runtime detection does not have the cost of dropping support for
specific hardware.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Kevin Kofler]

Felix Miata wrote:
>> I have a computer without SSE3. It runs Fedora just fine. I initially had
>> 1 GiB of RAM in it, I upgraded it to 3 GiB.
> 
> I have approximately 40 Fedora installations on 32 bit CPUs. About half of
> those are on Prescotts. I'm unable to notice that those with more than 1G
> RAM run any better than those with more RAM.

There are mainly 2 reasons I had to upgrade the RAM:
1. Akonadi / KMail 2.
2. "Modern" websites with massive abuse of inline images.
Both of those eat lots and lots of RAM.

> I am able to notice that the older, slower ones that do have SSE2 are able
> to run, but with Plasma 5, those are very slow. Those do run respectably
> with lighter WMs/DEs.

The main limiting factor there is probably not the CPU, but the GPU. If your 
GPU does not support OpenGL 2 (OpenGL 1.x is not enough because GLSL shaders 
are required), then QML 2 and thus Plasma 5 will fall back to software 
rendering through the llvmpipe, which of course on an old CPU is not 
impressive speed-wise.

What might help is disabling all the animations that can be disabled.

> For those without SSE2, Plasma 5 is completely unusable, but OK with any
> of the lightweights.

Without SSE2, you additionally also lose the QML/JavaScript JIT in QML 2. 
(There is no implementation of the JIT for the 387 FPU instructions, only 
for the SSE2 ones.) So you also get an interpreter in C++ there. (At least 
there IS a fallback, unlike in V8 and thus Chromium/QtWebEngine.) And of 
course the llvmpipe will also be slower without SSE2 instructions. And they 
will contend the CPU. There is not much Fedora can do about that, it is a 
result of the design choices in upstream Qt.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Reindl Harald]

Am 07.11.2015 um 18:30 schrieb Kevin Kofler:

Felix Miata wrote:

I have a computer without SSE3. It runs Fedora just fine. I initially had
1 GiB of RAM in it, I upgraded it to 3 GiB.


I have approximately 40 Fedora installations on 32 bit CPUs. About half of
those are on Prescotts. I'm unable to notice that those with more than 1G
RAM run any better than those with more RAM.


There are mainly 2 reasons I had to upgrade the RAM:
1. Akonadi / KMail 2.
2. "Modern" websites with massive abuse of inline images.
Both of those eat lots and lots of RAM


not to forget that we now have many cases where GTK2/GTK3/QT4/QT5 are 
loaded at the same time, with that memory not so long ago a whole 
graphical operating system including applications is working fine

_

below 1.5 GB RAM no way at all

frankly we recently upgraded our server-hardware and changed the 
clustermode to sandybridge, all seemed to work fine (except 
https://bugzilla.redhat.com/show_bug.cgi?id=1269014 which is a very 
interesting bug)


there are tiny backup VM's with 1024 Mb RAM over years for each 
production machine running a mysqld-slave and hourly rsync of the 
userdata for later offsite-backups from there


day 1 1:16: one of them crashed and got restarted by VMware HA
day 2 1:16: one of them crashed and got restarted by VMware HA

well, the screenshot vmware makes from the VT showed page allocation 
errors and finally i realized that the once per day added 
--delay-updates rsync param on the new hardware for whatever reason 
triggered that errors


increased *any* virtual machine to at least 1.5 GB RAM - no problems for 
2 months now






signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Reindl Harald]

Am 07.11.2015 um 19:26 schrieb Neal Gompa:

On Sat, Nov 7, 2015 at 1:23 PM, Reindl Harald 

Re: Retire a package from Fedora i686 (not x86_64)

[drago01]

On Sat, Nov 7, 2015 at 7:23 PM, Reindl Harald  wrote:
>
>
> Am 07.11.2015 um 19:01 schrieb Kevin Kofler:
>>
>> Reindl Harald wrote:
>>>
>>> well, who's to say that we stay forever on a level of CPU
>>> feature-support while there are instruction sets available for a whole
>>> decade which improve performance, save power in case you need fewer
>>> instructions doing the same work?
>>>
>>> not that i say Fedora should go ahead and build with -mavx but a
>>> discussion about SSE3 in 2015 is really odd
>>
>>
>> Sorry, but hardware simply does not get replaced instantly. This is a
>> matter
>> of both:
>> * cost – hardware is not free (as in beer)
>
>
> that *really* depends
>
> these days (and i talk about hardware from 2011) you can virtualize things
> fast, easy and efficient and consolidate machines on more or less cheap
> hardware
>
> besides it brings new CPU capabilities it saves a lot of energy:
>
> * one machine instead 2,3,4 or 10 machines
> * the new hardware needs so much less power
> * your UPS (in case you use one) can be cheaper or lasts longer
> * cooling is easier, cheaper and not that loud
>
> some numbers in that context:
>
> in early 2010 we planned a UPS systems to last for around 3 hours, with the
> current hardware and after consolidation the same UPS lasts 9 hours now and
> the air conditioner has lower load and longer lifetime
>
> the same applies to consumer hardware, my 365/7 running homeserver from 2011
> is a power beast and the whole IT needs around 50W while the previous
> hardware needed 120W - that's money, that's heat on summer days, that's less
> noise and hardddisks don't need to replaced that often because they are
> cooler
>
>> * ecology – there are huge landfills in China, India and Africa full of
>>  electronic trash from Europe and the USA; that gets mined for
>>  recyclable materials in an extremely polluting way that not
>> only
>>  ruins the environment, but also damages the health of the
>> people
>>  doing the mining (and the most dangerous materials are
>> handled
>>  by children). Materials used for electronic components are
>>  precious, someone has to recycle them or they would run out
>>  pretty soon.
>
>
> that is true but see above
>
>> As a developer who writes mathematical software for a living, I'd love
>> being
>> able to require AVX-512 right now (https://en.wikipedia.org/wiki/AVX-512 –
>> finally a way to specify the rounding mode per operation
>> (https://en.wikipedia.org/wiki/EVEX_prefix) rather than through the
>> extremely expensive stateful fesetround operations that reset the whole
>> prefetch queue, interval arithmetic should become MUCH faster with that),
>> but I have to deal with real-world CPUs that are here NOW (so it might
>> make
>> sense to have runtime detection for AVX-512 only in 1 or 2 years, and
>> requiring it is simply not possible within the next decade)
>
>
> maybe you did not get "not that i say Fedora should go ahead and build with
> -mavx" but we talk about SSE3

Compiling everything with sse3 does have a cost (dropping support for
some hardware) but what does it gain us?
Better performance in theory? To convince anyone you have to at least
provide numbers. Otherwise the discussion is a waste of time.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Neal Gompa]

On Sat, Nov 7, 2015 at 1:23 PM, Reindl Harald 
wrote:

>
>
> Am 07.11.2015 um 19:01 schrieb Kevin Kofler:
>
>> Reindl Harald wrote:
>>
>>> well, who's to say that we stay forever on a level of CPU
>>> feature-support while there are instruction sets available for a whole
>>> decade which improve performance, save power in case you need fewer
>>> instructions doing the same work?
>>>
>>> not that i say Fedora should go ahead and build with -mavx but a
>>> discussion about SSE3 in 2015 is really odd
>>>
>>
>> Sorry, but hardware simply does not get replaced instantly. This is a
>> matter
>> of both:
>> * cost – hardware is not free (as in beer)
>>
>
> that *really* depends
>
> these days (and i talk about hardware from 2011) you can virtualize things
> fast, easy and efficient and consolidate machines on more or less cheap
> hardware
>
> besides it brings new CPU capabilities it saves a lot of energy:
>
> * one machine instead 2,3,4 or 10 machines
> * the new hardware needs so much less power
> * your UPS (in case you use one) can be cheaper or lasts longer
> * cooling is easier, cheaper and not that loud
>
> some numbers in that context:
>
> in early 2010 we planned a UPS systems to last for around 3 hours, with
> the current hardware and after consolidation the same UPS lasts 9 hours now
> and the air conditioner has lower load and longer lifetime
>
> the same applies to consumer hardware, my 365/7 running homeserver from
> 2011 is a power beast and the whole IT needs around 50W while the previous
> hardware needed 120W - that's money, that's heat on summer days, that's
> less noise and hardddisks don't need to replaced that often because they
> are cooler
>
> * ecology – there are huge landfills in China, India and Africa full of
>>  electronic trash from Europe and the USA; that gets mined for
>>  recyclable materials in an extremely polluting way that not
>> only
>>  ruins the environment, but also damages the health of the
>> people
>>  doing the mining (and the most dangerous materials are
>> handled
>>  by children). Materials used for electronic components are
>>  precious, someone has to recycle them or they would run out
>>  pretty soon.
>>
>
> that is true but see above
>
> As a developer who writes mathematical software for a living, I'd love
>> being
>> able to require AVX-512 right now (https://en.wikipedia.org/wiki/AVX-512
>> –
>> finally a way to specify the rounding mode per operation
>> (https://en.wikipedia.org/wiki/EVEX_prefix) rather than through the
>> extremely expensive stateful fesetround operations that reset the whole
>> prefetch queue, interval arithmetic should become MUCH faster with that),
>> but I have to deal with real-world CPUs that are here NOW (so it might
>> make
>> sense to have runtime detection for AVX-512 only in 1 or 2 years, and
>> requiring it is simply not possible within the next decade)
>>
>
> maybe you did not get "not that i say Fedora should go ahead and build
> with -mavx" but we talk about SSE3
>
> talking about a rapid moving distribution like Fedora and at the same time
> hestitate to use technology available for a decade is strange - i guess
> people plan to run their hardware for 10, 12, 15 years are not using
> typically a distribution like Fedora
>
>
>
​The flip side of it is that Fedora is the foundation for RHEL and other
distributions. Most of the others don't matter so much, but RHEL does, as
that has to support servers and such. But even there, I would suggest to
say that we could say that RHEL 8 shouldn't have a problem bumping up,
since RHEL 7 supports those systems fine and will be supported for 9 more
years.​


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Reindl Harald]

Am 07.11.2015 um 19:27 schrieb drago01:

On Sat, Nov 7, 2015 at 7:23 PM, Reindl Harald  wrote:

maybe you did not get "not that i say Fedora should go ahead and build with
-mavx" but we talk about SSE3


Compiling everything with sse3 does have a cost (dropping support for
some hardware) but what does it gain us?
Better performance in theory? To convince anyone you have to at least
provide numbers. Otherwise the discussion is a waste of time


how do you expect to get such numbers?

even if you test whatever application with -msse2 versus -msse3 mosdt 
parts of the operating system and the whole libraries are still built 
with only SSE2 support


the point is compile a single application with new features won#t gain 
that muc 8until you do the same with most libraries used by the 
software) but having the whole distribution is a summary with a 
completly different behavior than a single test of software xyz


if there would be no difference kernel upstream won't invest that much 
time for runtime-cpu-detection (look at the bootlog on different hardware)


here are examples 
http://www.phoronix.com/scan.php?page=news_item=MTU0MTY 
http://www.phoronix.com/scan.php?page=news_item=MTI1Njc




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Reindl Harald]

Am 07.11.2015 um 19:01 schrieb Kevin Kofler:

Reindl Harald wrote:

well, who's to say that we stay forever on a level of CPU
feature-support while there are instruction sets available for a whole
decade which improve performance, save power in case you need fewer
instructions doing the same work?

not that i say Fedora should go ahead and build with -mavx but a
discussion about SSE3 in 2015 is really odd


Sorry, but hardware simply does not get replaced instantly. This is a matter
of both:
* cost – hardware is not free (as in beer)


that *really* depends

these days (and i talk about hardware from 2011) you can virtualize 
things fast, easy and efficient and consolidate machines on more or less 
cheap hardware


besides it brings new CPU capabilities it saves a lot of energy:

* one machine instead 2,3,4 or 10 machines
* the new hardware needs so much less power
* your UPS (in case you use one) can be cheaper or lasts longer
* cooling is easier, cheaper and not that loud

some numbers in that context:

in early 2010 we planned a UPS systems to last for around 3 hours, with 
the current hardware and after consolidation the same UPS lasts 9 hours 
now and the air conditioner has lower load and longer lifetime


the same applies to consumer hardware, my 365/7 running homeserver from 
2011 is a power beast and the whole IT needs around 50W while the 
previous hardware needed 120W - that's money, that's heat on summer 
days, that's less noise and hardddisks don't need to replaced that often 
because they are cooler



* ecology – there are huge landfills in China, India and Africa full of
 electronic trash from Europe and the USA; that gets mined for
 recyclable materials in an extremely polluting way that not only
 ruins the environment, but also damages the health of the people
 doing the mining (and the most dangerous materials are handled
 by children). Materials used for electronic components are
 precious, someone has to recycle them or they would run out
 pretty soon.


that is true but see above


As a developer who writes mathematical software for a living, I'd love being
able to require AVX-512 right now (https://en.wikipedia.org/wiki/AVX-512 –
finally a way to specify the rounding mode per operation
(https://en.wikipedia.org/wiki/EVEX_prefix) rather than through the
extremely expensive stateful fesetround operations that reset the whole
prefetch queue, interval arithmetic should become MUCH faster with that),
but I have to deal with real-world CPUs that are here NOW (so it might make
sense to have runtime detection for AVX-512 only in 1 or 2 years, and
requiring it is simply not possible within the next decade)


maybe you did not get "not that i say Fedora should go ahead and build 
with -mavx" but we talk about SSE3


talking about a rapid moving distribution like Fedora and at the same 
time hestitate to use technology available for a decade is strange - i 
guess people plan to run their hardware for 10, 12, 15 years are not 
using typically a distribution like Fedora





signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Kevin Kofler]

Reindl Harald wrote:
> well, who's to say that we stay forever on a level of CPU
> feature-support while there are instruction sets available for a whole
> decade which improve performance, save power in case you need fewer
> instructions doing the same work?
> 
> not that i say Fedora should go ahead and build with -mavx but a
> discussion about SSE3 in 2015 is really odd

Sorry, but hardware simply does not get replaced instantly. This is a matter 
of both:
* cost – hardware is not free (as in beer),
* ecology – there are huge landfills in China, India and Africa full of
electronic trash from Europe and the USA; that gets mined for
recyclable materials in an extremely polluting way that not only
ruins the environment, but also damages the health of the people
doing the mining (and the most dangerous materials are handled
by children). Materials used for electronic components are
precious, someone has to recycle them or they would run out
pretty soon.

As a developer who writes mathematical software for a living, I'd love being 
able to require AVX-512 right now (https://en.wikipedia.org/wiki/AVX-512 – 
finally a way to specify the rounding mode per operation 
(https://en.wikipedia.org/wiki/EVEX_prefix) rather than through the 
extremely expensive stateful fesetround operations that reset the whole 
prefetch queue, interval arithmetic should become MUCH faster with that), 
but I have to deal with real-world CPUs that are here NOW (so it might make 
sense to have runtime detection for AVX-512 only in 1 or 2 years, and 
requiring it is simply not possible within the next decade).

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Kevin Kofler]

Reindl Harald wrote:
> if there would be no difference kernel upstream won't invest that much
> time for runtime-cpu-detection (look at the bootlog on different hardware)

Exactly BECAUSE performance-critical software normally does runtime 
detection (except where upstream is really really lazy), hardcoding a 
requirement for newer instruction sets does not buy us anything.

The absence of a portable fallback also makes the software unusable on our 
secondary architectures, and in some cases (such as Darktable), even on the 
PRIMARY architecture ARM. (Now, whether ARM should be a primary architecture 
to begin with is a different matter, but it currently is.)

So I really don't understand those upstreams that provide ONLY platform-
specific vector code with no portable version.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Kevin Kofler]

Reindl Harald wrote:
> frankly whatever somebody has run on a 10 years old machine can be
> easily virtualized and i doubt that many people have a 10 years old
> computer as their only device, as far there is something with a core2 or
> newer in the house you can virtualize the other machine and save a lot
> of energy

Virtualization is not a solution for most home users:
* It assumes you have multiple machines to replace with one VM host and VMs.
* Virtualization also does not magically provide you with monitors and 
keyboards, which are essential parts of a home system. And the different 
seats (where there is more than one computer to begin with) are often in 
different rooms. This cannot trivially be replaced by a VM-based setup. 
You'd need at least thin clients in addition to the VMs.

As for the "core2 or newer" part: The average Core 2 system is going to run 
out of RAM very quickly if you try to run VMs on it. My Core 2 Duo notebook 
can do hardware virtualization, and I use that to test live ISOs, but if I 
start one Plasma 4 VM in addition to the Plasma 4 host, the RAM (4 GiB) is 
already full (and Plasma 5 is reported to be no better and probably worse 
there). (I need to allocate 2 GiB for the VM or Plasma will just not work in 
it. If you count the same for the host, it's no surprise that the 4 GiB of 
RAM end up full.)

You need to think outside of the company scenario you are used to (and even 
your home is not a typical home user environment).

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Kevin Kofler]

Reindl Harald wrote:
> frankly whatever somebody has run on a 10 years old machine can be
> easily virtualized and i doubt that many people have a 10 years old
> computer as their only device, as far there is something with a core2 or
> newer in the house you can virtualize the other machine and save a lot
> of energy

Virtualization is not a solution for most home users:
* It assumes you have multiple machines to replace with one VM host and VMs.
* Virtualization also does not magically provide you with monitors and 
keyboards, which are essential parts of a home system. And the different 
seats (where there is more than one computer to begin with) are often in 
different rooms. This cannot trivially be replaced by a VM-based setup. 
You'd need at least thin clients in addition to the VMs.

As for the "core2 or newer" part: The average Core 2 system is going to run 
out of RAM very quickly if you try to run VMs on it. My Core 2 Duo notebook 
can do hardware virtualization, and I use that to test live ISOs, but if I 
start one Plasma 4 VM in addition to the Plasma 4 host, the RAM (4 GiB) is 
already full (and Plasma 5 is reported to be no better and probably worse 
there). (I need to allocate 2 GiB for the VM or Plasma will just not work in 
it. If you count the same for the host, it's no surprise that the 4 GiB of 
RAM end up full.)

You need to think outside of the company scenario you are used to (and even 
your home is not a typical home user environment).

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Reindl Harald]

Am 08.11.2015 um 00:56 schrieb Kevin Kofler:

Reindl Harald wrote:

if there would be no difference kernel upstream won't invest that much
time for runtime-cpu-detection (look at the bootlog on different hardware)


Exactly BECAUSE performance-critical software normally does runtime
detection (except where upstream is really really lazy), hardcoding a
requirement for newer instruction sets does not buy us anything.


define performance critical

our cms systems got 5 times faster within 6 months by micro-optimizig 
each alone would not had any effect



The absence of a portable fallback also makes the software unusable on our
secondary architectures, and in some cases (such as Darktable), even on the
PRIMARY architecture ARM. (Now, whether ARM should be a primary architecture
to begin with is a different matter, but it currently is.)

So I really don't understand those upstreams that provide ONLY platform-
specific vector code with no portable version


i understand them well - not endless time and write effecient software 
without test on dozens of environments older than 10 years - as C 
programmer if i would write new code these days i would even go so far 
and rely on AVX


yes, that can't be done for a distribution, but i know that all machines 
sorrounding me are SandyBridge bases, even the network routers for small 
offices and so why would i care about anything else?




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[bitlord]

On Sat, 7 Nov 2015 04:29:48 +0100
Ralf Corsepius  wrote:

> On 11/06/2015 10:00 PM, Kevin Kofler wrote:
> > Germano Massullo wrote:  
> >> For example, SSE3 instructions set is one of the minimum
> >> requirements and 99% of 32 bit only CPUs do not support it. Only
> >> Pentium 4 >= Prescott architecture supports it.  
> >
> > I think building it with SSE3 is better than excluding the
> > architecture entirely. And FYI, requiring SSE3 is not really
> > allowed even for x86_64 (you are allowed to assume only SSE2), so
> > by that argument, there is no architecture left.  
> ACK. Does anybody know if there are any x86_64/64bit-CPUs which do
> not support sse3?
> 
> I don't see sse3 in /proc/cpuinfo of any machine I have, but I also 
> don't see any runtime error/warning from darktable.
> 

SSE3 is reported as 'pni' (Prescott New Instructions) 

> > Of course, a better solution would be to fix the package to work on
> > all CPUs you support.  
> ACK.
> 
> > But if upstream doesn't care, it's going to be a problem. :-(  
> Exactly - That's the actual problem. Upstream does not care and
> Fedora seems unable to address this issue.
> 
> Ralf
> 

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Ralf Corsepius]

On 11/07/2015 04:55 AM, Reindl Harald wrote:



Am 06.11.2015 um 20:11 schrieb Germano Massullo:

For example, SSE3 instructions set is one of the minimum requirements
and 99% of 32 bit only CPUs do not support it. Only Pentium 4 >=
Prescott architecture supports it


seriously?


Probably.


with that argumentation Fedora would drop i686 at all
No. darktable handles the situation on sse3-less CPUs gracefully at 
run-time.


The actually problem is darktable wanting to be compiled with -msse3, 
which means being compiled with a Fedora incompatible instruction set, 
on both i386 and x86_64.



well, i don't have any non x86_64 machien but the argumentation is bous
You are right, these days in professional PC-usage, i686ers likely are 
rare and hard to find.


But in personal (private) PC-usage, the situation is different. There, 
5/6-year old 32bit PCs are still wide spread and will be supported by 
Windows for many years. Also consider, people are using Linux on such 
machines to extend these machines life time.


Feel free to drop the i386, if you want drop the end-user/desktop market 
and to leave this market to Ubuntu, Debian and other distributions.


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Ralf Corsepius]

On 11/07/2015 05:03 AM, Reindl Harald wrote:



Am 07.11.2015 um 05:00 schrieb Luya Tshimbalanga:

On 06/11/15 07:29 PM, Ralf Corsepius wrote:

But if upstream doesn't care, it's going to be a problem. :-(

Exactly - That's the actual problem. Upstream does not care and Fedora
seems unable to address this issue.

Ralf


According to my system, it has SSSE3. Is it SSE3?

That's what my question actually was about.

I see ssse3 on all my x86_64ers, I see sse3 on my 32bit atoms, but I 
don't know if ssse3 implies sse3 and I don't know what -msse3 actually 
does to the instruction set when being used on x86_64ers and which 
impact it has (-msse3 is not part of Fedora's gcc implicit CFLAGS).



any system not older than 10 years has SSE3  and frankly systems older
than 10 years are hardly a traget for Fedora at all


So, Fedora or Linux as a resort to escape Windows on old HW is not a 
Fedora target anymore?


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Germano Massullo]

Il 07/11/2015 04:29, Ralf Corsepius ha scritto:
> I don't see sse3 in /proc/cpuinfo of any machine I have, but I also
> don't see any runtime error/warning from darktable.
Because SSE3 is shown as "pni", Prescott New Instructions [1] [2]

[1]: https://en.wikipedia.org/wiki/SSE3
[2]:
http://unix.stackexchange.com/questions/43539/what-do-the-flags-in-proc-cpuinfo-mean

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Reindl Harald]

Am 07.11.2015 um 05:00 schrieb Luya Tshimbalanga:

On 06/11/15 07:29 PM, Ralf Corsepius wrote:

But if upstream doesn't care, it's going to be a problem. :-(

Exactly - That's the actual problem. Upstream does not care and Fedora
seems unable to address this issue.

Ralf


According to my system, it has SSSE3. Is it SSE3?
Taken from A10-7400P laptop


any system not older than 10 years has SSE3 and frankly systems older 
than 10 years are hardly a traget for Fedora at all




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Luya Tshimbalanga]

On 06/11/15 07:29 PM, Ralf Corsepius wrote:
> On 11/06/2015 10:00 PM, Kevin Kofler wrote:
>> Germano Massullo wrote:
>>> For example, SSE3 instructions set is one of the minimum
>>> requirements and
>>> 99% of 32 bit only CPUs do not support it. Only Pentium 4 >= Prescott
>>> architecture supports it.
>>
>> I think building it with SSE3 is better than excluding the architecture
>> entirely. And FYI, requiring SSE3 is not really allowed even for
>> x86_64 (you
>> are allowed to assume only SSE2), so by that argument, there is no
>> architecture left.
> ACK. Does anybody know if there are any x86_64/64bit-CPUs which do not
> support sse3?
>
> I don't see sse3 in /proc/cpuinfo of any machine I have, but I also
> don't see any runtime error/warning from darktable.
>
>> Of course, a better solution would be to fix the package to work on
>> all CPUs
>> you support.
> ACK.
>
>> But if upstream doesn't care, it's going to be a problem. :-(
> Exactly - That's the actual problem. Upstream does not care and Fedora
> seems unable to address this issue.
>
> Ralf
>
According to my system, it has SSSE3. Is it SSE3?
Taken from A10-7400P laptop.

-- 
Luya Tshimbalanga
Graphic & Web Designer
E: l...@fedoraproject.org
W: http://www.coolest-storm.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Ralf Corsepius]

On 11/06/2015 09:50 PM, Stuart Gathman wrote:

On 11/06/2015 02:11 PM, Germano Massullo wrote:


For example, SSE3 instructions set is one of the minimum requirements
and 99% of 32 bit only CPUs do not support it. Only Pentium 4 >=
Prescott architecture supports it.


For that kind of thing, add a runtime test for required CPU features at
startup.

That's what they actually do.

cf. https://bugzilla.redhat.com/show_bug.cgi?id=1278064#c14
$ darktable
[dt_init] unfortunately we depend on SSE3 instructions at this time.
[dt_init] please contribute a backport patch (or buy a newer processor).



That may not be necessary if the app already fails in a friendly way on
old CPUs (as opposed to hanging or mysterious crashes).


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Ralf Corsepius]

On 11/06/2015 10:00 PM, Kevin Kofler wrote:

Germano Massullo wrote:

For example, SSE3 instructions set is one of the minimum requirements and
99% of 32 bit only CPUs do not support it. Only Pentium 4 >= Prescott
architecture supports it.


I think building it with SSE3 is better than excluding the architecture
entirely. And FYI, requiring SSE3 is not really allowed even for x86_64 (you
are allowed to assume only SSE2), so by that argument, there is no
architecture left.
ACK. Does anybody know if there are any x86_64/64bit-CPUs which do not 
support sse3?


I don't see sse3 in /proc/cpuinfo of any machine I have, but I also 
don't see any runtime error/warning from darktable.



Of course, a better solution would be to fix the package to work on all CPUs
you support.

ACK.


But if upstream doesn't care, it's going to be a problem. :-(
Exactly - That's the actual problem. Upstream does not care and Fedora 
seems unable to address this issue.


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Reindl Harald]

Am 06.11.2015 um 20:11 schrieb Germano Massullo:

For example, SSE3 instructions set is one of the minimum requirements
and 99% of 32 bit only CPUs do not support it. Only Pentium 4 >=
Prescott architecture supports it


seriously?

with that argumentation Fedora would drop i686 at all
well, i don't have any non x86_64 machien but the argumentation is bous



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Germano Massullo]

For example, SSE3 instructions set is one of the minimum requirements and
99% of 32 bit only CPUs do not support it. Only Pentium 4 >= Prescott
architecture supports it.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Tom Hughes]

On 06/11/15 14:18, Germano Massullo wrote:


I just removed 32bit CPU support from Darktable's spec file due
technical reasons.
Are there any other things I need to clean up in Fedora infrastructure?


Well you should start by reading the relevant guidelines:

https://fedoraproject.org/wiki/Packaging:Guidelines#Architecture_Support

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Pete Walter]

06.11.2015, 17:18, "Germano Massullo" :
> I just removed 32bit CPU support from Darktable's spec file due
> technical reasons.

It is hard to help if you just say "due to technical reasons". What are they?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Pete Walter]

06.11.2015, 22:11, "Germano Massullo" :For example, SSE3 instructions set is one of the minimum requirements and 99% of 32 bit only CPUs do not support it. Only Pentium 4 >= Prescott architecture supports it. Prescott is 11 years old. I would expect vast majority of people who are currently running 32 bit Fedora to have newer computers. I would go even as far as to say that nobody who has an older than a 11 year old computer would even try to launch Darktable. And your solution is to just kill it off, because a few ancient computers can't run it?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Stuart Gathman]

On 11/06/2015 02:11 PM, Germano Massullo wrote:


For example, SSE3 instructions set is one of the minimum requirements 
and 99% of 32 bit only CPUs do not support it. Only Pentium 4 >= 
Prescott architecture supports it.


For that kind of thing, add a runtime test for required CPU features at 
startup.  If you don't want to touch the original code, just add an 
introducer that checks current hardware, then execs the app in /usr/libexec.


That may not be necessary if the app already fails in a friendly way on 
old CPUs (as opposed to hanging or mysterious crashes).

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

[Kevin Kofler]

Germano Massullo wrote:
> For example, SSE3 instructions set is one of the minimum requirements and
> 99% of 32 bit only CPUs do not support it. Only Pentium 4 >= Prescott
> architecture supports it.

I think building it with SSE3 is better than excluding the architecture 
entirely. And FYI, requiring SSE3 is not really allowed even for x86_64 (you 
are allowed to assume only SSE2), so by that argument, there is no 
architecture left.

Of course, a better solution would be to fix the package to work on all CPUs 
you support. But if upstream doesn't care, it's going to be a problem. :-( 
We have a similar issue with QtWebEngine, because Chromium/V8 upstream 
requires SSE2 in their JIT and there is no interpreter fallback. (They are 
now working on an "interpreter" mode, but it is not a real interpreter 
fallback either, some stuff still uses the JIT.)

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct