1 |
On Mon, 18 Mar 2019 18:09:47 +0100 Michał Górny wrote: |
2 |
> On Mon, 2019-03-18 at 19:30 +0300, Andrew Savchenko wrote: |
3 |
> > On Mon, 18 Mar 2019 16:09:18 +0100 Michał Górny wrote: |
4 |
> > > On Sun, 2019-03-17 at 11:30 +0300, Andrew Savchenko wrote: |
5 |
> > > > On Sat, 16 Mar 2019 18:38:48 +0100 Michał Górny wrote: |
6 |
> > > > > On Sat, 2019-03-16 at 13:14 +0300, Andrew Savchenko wrote: |
7 |
> > > > > > On Sat, 16 Mar 2019 10:35:18 +0100 Michał Górny wrote: |
8 |
> > > > > > > On Sat, 2019-03-16 at 09:31 +0000, James Le Cuirot wrote: |
9 |
> > > > > > > > On Fri, 15 Mar 2019 10:23:00 +0100 |
10 |
> > > > > > > > Michał Górny <mgorny@g.o> wrote: |
11 |
> > > > > > > > |
12 |
> > > > > > > > > # Michał Górny <mgorny@g.o> (15 Mar 2019) |
13 |
> > > > > > > > > # Last reverse dependency of dev-libs/libgcrypt-1.5* (#656378). Current |
14 |
> > > > > > > > > # version is outdated, maintainer is MIA and the new versions are |
15 |
> > > > > > > > > # in distro-unfriendly AppImage format (#661740). |
16 |
> > > > > > > > > # Removal in 30 days. Bug #677486. |
17 |
> > > > > > > > > dev-util/staruml-bin |
18 |
> > > > > > > > > =dev-libs/libgcrypt-1.5* |
19 |
> > > > > > > > |
20 |
> > > > > > > > I don't care about staruml-bin but libgcrypt is one of those legacy |
21 |
> > > > > > > > libraries that would be helpful to keep around for older proprietary |
22 |
> > > > > > > > software that is not in the tree. In particular, it is used by |
23 |
> > > > > > > > Half-Life 2 and Portal, not exactly obscure games. It is included in |
24 |
> > > > > > > > the Steam runtime but we highly recommend against using that because it |
25 |
> > > > > > > > causes many issues. |
26 |
> > > > > > > |
27 |
> > > > > > > I don't understand why would you want to run some proprietary native |
28 |
> > > > > > > executables requiring obsolete libraries on your system when HL2 works |
29 |
> > > > > > > perfectly via wine, and gets a nice performance boost via Gallium Nine. |
30 |
> > > > > > |
31 |
> > > > > > Because native code works faster than API emulation via wine. |
32 |
> > > > > > |
33 |
> > > > > |
34 |
> > > > > Do you have any data to support that? Or is it 'obvious'? |
35 |
> > > > |
36 |
> > > > Yes, I have. Because Half-Life 2 on native steam works on my old |
37 |
> > > > box with GF 7300 and Athlon-XP and does not work at all on the |
38 |
> > > > same box via wine-d3d9. |
39 |
> > > > |
40 |
> > > |
41 |
> > > That's not really a data point. Unless you can actually test it (or |
42 |
> > > otherwise prove that it would be slower if it worked), you're merely |
43 |
> > > complaining that you can't use the faster solution. |
44 |
> > > |
45 |
> > > I'm sorry that you've bought non-OSS-friendly video card and now you're |
46 |
> > > stuck with the choice between awful proprietary drivers and far-from- |
47 |
> > > complete OSS drivers. However, that doesn't prove that the native |
48 |
> > > version would be faster at all. |
49 |
> > |
50 |
> > If wine-based version does not work, its performance is zero. That's |
51 |
> > why the native version is faster. |
52 |
> > |
53 |
> |
54 |
> Wrong. If it doesn't work, it consumes very little CPU/GPU cycles. |
55 |
> Therefore, it is much more efficient than the working version. |
56 |
|
57 |
But it hangs, consuming all CPU cycles possible. |
58 |
|
59 |
Best regards, |
60 |
Andrew Savchenko |