SPECS: gimp.spec - added missing png, makefile patch (to install t...

[Fryderyk Dziarmagowski]

On Sun, 26 Dec 2004 18:01:26 +0100
Jakub Bogusz <qboosh w pld-linux.org> wrote:

> > > On Tue, Dec 21, 2004 at 08:30:48PM +0000, freetz wrote:
> > > > Author: freetz                       Date: Tue Dec 21 20:30:48
> > > > 2004 GMT Module: SPECS                         Tag: HEAD
> > > > ---- Log message:
> > > > - added missing png, makefile patch (to install this png),
> > > > rereshed old
> > > >   py-compile, enabled posix shm by default, nfy
> > > 
> > > Dlaczego akurat posix (i nie bardzo "by default") - daje jakąś
> > > przewagę nad sysv?
> > 
> > Mamy już zgodne z POSIX wątki w glibcu. Dlaczego nie mielibyśmy iść
> > dalej w z zgodnośći ze standardami? W jack-audio-connection-kit od
> > dawna mamy obsługę posix shm, nie budziły jak do tej pory
> > kontrowersji.
> 
> Bo nikt nie testował? I było mylące "where available" w commit logu
> pluta?

Ja testowałem. W konfiuracji zalecanej przez autorów jacka, czyli z
posix shm.

> Dobrze, że zwróciłeś uwagę na zepsuty pakiet.

Z punktu widzenia dystrybucji jest popsuty. Z punktu widzenia
użytkownika nie.

> $ jackd -d oss
> jackd 0.99.0
> Copyright 2001-2003 Paul Davis and others.
> jackd comes with ABSOLUTELY NO WARRANTY
> This is free software, and you are welcome to redistribute it
> under certain conditions; see the file COPYING for details
> 
> cannot open existing shm registry segment (Function not implemented)
> Naruszenie ochrony pamięci (core dumped)

to jest problem afaik z oss, dlatego kiedyś protestowałem, że
wydzieliłeś podstawowy sterownik do podpakietu.

> Ładne mi "where available"... :/
> 
> (inna rzecz, że przy podmontowanym /dev/shm się często (p~0.3) wykłada
> się przy starcie z SIGFPE...)

j.w.

> > Gdzie
> > widzisz problem, zagrożenie?
> 
> W przypadku jacka właśnie zobaczyłem problem.
> W obsłudze błędów i braku fallbacka (do SysV shm czy czegokolwiek).
> 
> > > W domyślnym fstabie /dev/shm jest zakomentowane, bez zmiany tego
> > > przez administratora ten default nie będzie działał (tzn. pamięć
> > > dzielona nie będzie używana).
> > 
> > Możesz rozszerzyć jakie są negatywne skutki niedziałania defaulta?
> > bo aplikacja działa bez problemów w razie braku interwencji
> > administracyjnych.
> 
> Wolniejsze działanie - przesyłanie grafiki przez rurkę zamiast shm
> (nie ma fallbacka do SysV shm).
> 
> Przy aktualnym domyślnym fstabie to jest zmiana na gorsze.
> Dlatego pytam się, jakie korzyści daje POSIX shm w stosunku do SysV
> (oprócz tych 5 liter)?
> Gdyby to było wydajniejsze, można by użyć - ale _po_ uprzedniej
> zmianie domyślnego fstaba.

Nie jest wydajniejsze. Jest nowocześniejsze i zgodne z POSIX. Z tego co
czytałem nie ma też wiecej wad niż SysV shm, a główną różnicą jest
implementacja.

jest jakiś istotny powód dlaczego to w PLD jest w gestii administratora,
a nie domyślnie włączone?

[...]

-- 
Fryderyk Dziarmagowski