Forum Debian Users Gang

@yossarian:

To jest siłą napędową rozwoju - ale wszystko musi mieć granice, jak 8 lat temu były 4 serwery dźwięku to nie był rozwój, tylko obciążenie bo każdy serwer działał tylko w specyficznym środowisku, każdy wymagał własnych obejść itd.

Oczywiście są rzeczy które z założenia muszą posiadać możliwość customizacji (np. schedulery - inny pod serwer, inny pod desktop i inny pod stację do generowania grafy 3D), ale jeżeli do dźwięku są 3 ścieżki to IMHO nie ma to żadnych zalet, za to KOSZT napisania i UTRZYMANIA kodu jest ogromny.

Ja bym bardziej porównał sytuację do tego jakbyś w samochodzie zamiast jednej skrzyni biegów miał 4, z tym że skrzynią pod prawą ręką możesz wrzucać tylko biegi 1 i 3 bez "luzu", skrzynią po lewej stronie to dwójka i luz, skrzynią w kierownicy tylko wsteczny, a biegi 4 i 5 wrzucają się automatycznie ;] oczywiście "zaleta" tego systemu to fakt że jak siądzie Ci skrzynia po prawej to możesz od dwójki jechać, a jak siądzie po lewej to z jedynki na trójkę da radę, ale wadą że masz 4 niezależne systemu, 4 miejsca w których coś może się zwalić, 4 miejsca które się niezależnie zużywają, 4 miejsca za które podczas serwisu trzeba płacić. Czy nie lepiej więc mieć jedną a porządną skrzynię ;]? W sofcie jest tak samo. Kiedyś czytałem o badaniach że programiści wolą zwykle napisać coś od 0 samemu niż wgryzać się w kod, bo wgryzanie jest z założenia nieprzyjemne - Linuks jest tego dobrym przykładem. Teraz po jajach z OpenSSL najpewniej będą co najmniej dwie biblioteki - jednak robiona przez zespół BSD, druga przez ludzi którzy dostana kaskę od firm... lepiej było by chyba zrobić jedną, a porządnie wspólnymi siłami...

Ja zdania nikomu nie narzucam, ale faktem jest że koszt utrzymania kilku rozwiązań ZAWSZE JEST (i będzie) większy niż koszt utrzymania jednego - min. dlatego spora ilość firm jest zniechęcona do Linuksa i twierdzi (słusznie) że koszt pisania softu jest wyższy niż na innych systemach.

@Huk

Przesadzasz, jak dasz w programie wyjście dźwiękowe Alsa, to będzie z tym wyjściem chodził i na Alsie, i na Jackd i na OSS.
Jeśli nie pójdzie na PA, to będzie wina PA, nie Twoja.

POWINIEN chodzić ;], powinien to słowo kluczowe niestety. Jasne że niby to nie jest wina twórców, ale spróbuj to wyjasnić userom - swego czasu fajny wątek na liście mailingowej WINE odnośnie tego dlaczego z PA nie działa, userów trochę to "waliło" że to wina PA i psioczyli na devów. Ludzie od WINE chyba się nie ugięli i do dzisiaj wsparcie jest takie sobie pod PA, ale sporo innych dorobiła wtyki korzystające bezpośrednio z API PA bo się fixów nie mogli doczekać.

A teraz wyobraź sobie że chciałbyś soft sprzedawać - serio wierzysz że jakiś user który zakupił od Ciebie soft przejąłby się tym że to przez PA nie śmiga? Było by: napraw albo kasa ;]

Widziałeś instalację OSS4, która nie ma warstwy kompatybilności z Alsą? bo ja nigdy.
Widziałeś Alsę, niekompatybilną z OSS? bo ja w normalnym Linuxie nigdy, tylko w Bubuntu.

Widziałem i to nie raz (w Debianie żeby nie było) - jak tylko zacząłem używać softu wymagającego ścisłego przestrzegania timingów audio - głównie emulatorów do SNES'a i Megadrive'e, ale i na WINE nie zawsze to chodziło jak powinno - fakt natomiast że w przypadku OSS4 to były może 2-3 aplikacje (i na szczęście wszystkie miały wyjście OSS obok ALSY -po przełączeniu chodziły jak złoto ), zaś z PA liczyłem to w dziesiątkach.

Także nie czaję, jaki problem jest z tym API dźwiękowym.
Jack-audio też chodzi z Alsą lub OSS, a nie z dziesięcioma różnymi API, i jak w asound.conf wyjście na jackd, to program korzystający z Alsy nawet nie wie, że wysyła dźwięk do serwera jackd, a nie bezpośrednio Alsy. Tak samo to działało kiedyś, jak były Artsdsp i ESD.

Ty tak serio pytasz czy to był sarkazm? Zanim napisałem swoją wtyczkę to przetestowałem dość grutnowanie ALSĘ, Jacka, OSS4 i PA i jedynie "czyste" rozwiazania (czytaj ALSA i OSS4) działały zawsze (no... w 99% przypadków - wspomniany wyżej błąd z OSS4). Jack miał swoje problemy i też nie ze wszystkim współpracował (ALE Jack nigdy nie był projektowany jako bazowy serwer dźwięku - co sam autor na liście mailingowej przyznał, min. dlatego serwer Jacka był dostępny tylko dla usera który go odpalił, nie wiem czy coś się od tamtej pory zmieniło), PA działało jak chciało, zaś ALSA nie obsługiwała kontroli głośności per aplikacja.

Natomiast PROBLEM polega na tym co już tłumaczyłem w innym wątku - KOSZT, koszt utrzymania kodu jest duży (utrzymanie kosztuje więcej niż napisanie w przypadku dużych aplikacji), każda gałąź kosztuje, dlatego z WINE wyleciało wsparcie dla wszystkiego poza ALSĄ (i chyba OSS4 ? ). Za czasów (nie tak dnawych przecież) aRts, ESD i OSS, musiałeś pisać 3/4 razy ten sam kod - raz ogólnie na ALSE, raz na Gnome, raz na KDE.

Czy coś miało wyjście na OSS czy na Alsę, zawsze bez problemu działało na KDE czy Gnome, pierwszym źródłem problemów z dźwiękiem był PA, i jego wieczne błędy.

ESD i aRts to był zastępnik dmix'a, zastępniki o tyle do dupy że były enviroment specific, ich "stabilność" i "kompatybilność" była żenująco słaba, akurat jestem na tyle stary że pamiętam czasy kiedy dmix był w powijakach i mój super hiper SoundBlaster 7.1 (bez mixowania sprzętowego) działał tylko z jedną apką na raz - wtedy testowałęm te rozwiązania i ŻADNE nie działao jak powinno a już na pewno nie jak działałes przez czyste wyjście OSS czy ALSY - jak wszystkie apki korzystały z ESD czy aRts (wykorzystując API tych mikserów) to owszem uchodziło, ale ograniczało to BARDZO użytkowanie kompa, dlatego ludzie (w tym ja) ratowali się zakupem karty ze sprzętowym mixerem. Dopiero jak dmix się ustabilizował zaczeło być normalnie, a potem przyszło PA i powróciły jajca...

Także mocno przesadzasz z tymi czterema skrzyniami biegów, jak nie wiesz, jak się robi coś z dźwiękiem czy obrazem, to ja radziłbym zajrzeć do API kernela, i zobaczyć, jak tam wygląda sytuacja.

No przecież dokładnie tak jak mówię działają w kernelu - kilka lat wstecz było chyba z 5 API do zarządzania kartami WIFI, teraz jest jedno, dzięki temu pisząc klienta mniej się trzeba namęczyć, a api z wydania na wydanie jest coraz stabilniejsze. Minus taki że część starszych sterowników do WIFI wyleciała lub została okrojona... coś za coś. Ostatnie wypowiedzi Linusa, dają nadzieję ze złapie w końcu devów za jajca i sporo innego syfu z kernela wyleci ;]

Podobnie np z OpenGL, pisząc program, masz interfejs /dev/dri/card*,
i nie musisz się interesować, jak to jest w Nvidii, jak w ATI a jak w Intelu.
Tak samo z OpenCL.

:D wiesz ze powyższym tekstem właśnie popierasz mój punkt widzenia ? Dokładnie o to chodzi - robić JEDNO API nisko/średnio poziomowe do którego to wszyscy się dostosowują (w końcu to producenci kart się muszą do OGL dostosować a nie Vice versa, tak samo do OpenCL się wszyscy dostosowują i piszemy kod raz, używamy gdzie chcemy), a nie w drugą stronę: jakby obok OpenGL i DX'a było jeszcze Glide, Mantle i 5 innych to pisanie sterów do kart było by tyle razy droższe. Kiedyś w grach na Windos pisano często 2 lub trzy renderery - OpenGL, Glide i DX, zwykle tylko jeden działał na FULL, a reszta to były porty z konieczności bo starsze karty wspierały tylko jedną metodę renderowania.

Potężny kłopot jest z Xorgiem, dlatego idzie na śmietnik historii, i krzyżyk mu na drogę.

Nie martw się - bedziesz miał MIR i Wayland... a może ktoś forka jeszcze zrobi i będze trzeci "gracz"... no ale im więcej tym przecież lepiej ... prawda ;] ?

Koszt pisania softu na Linuxa większy niż  na innych systemach?
Nie koszt, tylko potencjalny rynek zbytu jest znacznie większy, i nie w przypadku innych systemów, bo na Apple czy BSD nikt tu nic nie pisze, tylko w przypadku jednego, słusznego systemu.

Panie drogi, w zależności od wielkości aplikacji i podejścia po oddaniu produktu to napisanie to jest pomiędzy 30%-80% kosztów jakie trzeba ponieść. Pisząc coś seryjnego co ma zarabiać i przez X lat być na rynku, jeszcze trzeba to utrzymać, zapewnić wsparci i kompatybilność na ten okres czasu. Jak M$ wydał XP to po napisaniu APKI nie trzeba było zmieniać linii kodu przez 15 lat (a nawet po tym czasie, 95% apek chodzi w Win7 od strzała ), spróbuj sobie skompilować 15 latni program na Debianie bez poprawiania kodu - powodzenia życzę... Nie tak dawno próbowałem kod sprzed ~ 8 lat - ilość zmian w wykorzystywanych bibliotekach była tak duża, że ja dziękuję to przepisywać. Własnie dlatego wielu devów narzeka na Linuksa. Dupkę powinny chronić frameworki i Java do tej pory w miarę sobie z tym radziła... ale nie wszyscy piszą w Javie.

Żeby policzyć koszt pisania na jakiś system, to trzeba najpierw coś na niego napisać, chyba, że masz na myśli istniejący program  na NET Framework 3.5 i koszt przepisania go na Linuxa z użyciem QT, który będzie ogromny.

Coś ty się na ten .NET tak uwziął ;p ? Fetysz jaki czy co ?

Argument z OpenSSL też bzdurny, bo obie nowe implementację będą zgodne z pierwotną implementacją OpenSSL, oba projekty mają na celu oczyszczenie kodu ze śmieci, API się od tego nie zmieni znacząco.

Do czasu aż się rozjadą - nie wierzysz? To zobacz soebie jak "zgodne" są ze sobą przeglądarki - niby wszystkie implemetnucją specyfikację HTML... tylko każda trochę inaczej.

I nawet, jak będziesz miał obie nowe  implementacje, to programy i tak wołają o bibliotekę  /usr/lib/libssl.so, czy ta biblioteka będzie dowiązana od /usr/lib/liblibressl.so  czy do psa, który jeździ koleją, to żadnego programu korzystającego z biblioteki SSL nie powinno obchodzić.

Zakładsz że będą obie w każdym distrze? Biorąc pod uwagę politykę Debiana - szczerze wątpię, bardziej stawiam że będzie sytuacja w stylu LibAV vs FFMpeg.

Próbujesz dorobić ideologię do faktu, że na pisaniu na Linuxa w tej chwili nie da się zbyt dużo zarobić, więc, "koszt jest ogromny" i podobne brednie.

Tymczasem jakbym zaproponował pisanie przenośnego kodu np w QT, który można skompilować na dowolną platformę, to NET i tak będzie lepszy, bo w NET już wszystko jest napisane, i się tylko to poprawia,
a w QT trzeba by zaczynać od zera, a to jest "kosmiczny problem".

Hmmm JA dorabiam ideologie? To teraz mi pokaż w moim wcześniejszym poście gdzie ja coś o .NET wspominam (poza narzekaniem że instalator nie działa) czy Windos chwalę (zdajesz sobie sprawę że jest jeszcze Android i iOS, prawda)? No chyba że dowolna wzmianka - nawet negatywna -o .NET to zbrodnia, a pisanie że w Windos dźwięk działa bez pierdzenia -podczas gdy na PA pierdzi - to już w ogóle...

Radze po raz kolejny - napisz coś większego samemu, może zrozumiesz o co chodzi. Ja sobie nie wymyślam "z dupy" tego co piszę, to jest kompilacja tego co czytam na różnych forach, tłumaczeń firm dlaczego nie wydają softu na Linuksa jak i własnego doświadczenia z kompilacji rożnych programów starszych niż kilka miechów.

QT jest zajebiste, ale samo QT to za mało tak długo jak podejście będzie się nie zmieni.

Pozdrawiam.

@Jacekalex:

My się chyba zrozumieć nie możemy czy coś - ja nigdy, nigdzie nie powiedziałem że to co uważam za błędy, sprawiają że Linuks jest do dupy, beznadziejny itd. Ja bym bardzo chciał żeby się pingwin w końcu wybił... tyle że żeby do tego doszło trzeba przekonac zwykłych userów że system ten jest OK, że da się go używać tak samo, albo lepiej niż Windos. Ponadto developerów też trzeba przekonać że warto inwestować w system. Bez userów i programistów (komercyjnych) Linuks pozostanie systemem dla szpeców.

Dźwięk w Linuxie?

W kernelu masz Alsę, to trzymaj się Alsy.
Jak ma iść przez jakiś serwer dźwięku, to psim obowiązkiem tego serwera jest przyjmować dźwięk adresowany na wyjście Alsa, i kropka.
Jak jakiś zasrany PA tego nie obsługuje, to jebał go pies, a z nim wszystkie programy, które zaciągają PA i mogą chodzić tylko na wyjściu PA.

Sieć?
Masz Wpa-supplicanta? działa?
Masz pppd i vwdial - działają?
Masz dhclienta i dhcpcd - działają?

To co mi tu wyjeżdżasz z jakimiś patologiami typu NM czy Wifi-radar?

No właśnie - ja mam ALSA i zgadzam się że PA mi nie potrzebne, mam wpa-supplicant i tez mnie wali NM (no... ale wicda używam od czasu do czasu ;] )... tyle że Ja , Ty, yossarian, Bodzio i inny z tego forum, mają już WIEDZĘ że Linuks jest stabilny, łatwy i przyjemny (BO JEST!). Ale żeby przekonać nowych userów trzeba robić założenia. I ja zakładam (może błędnie - ale biorąc pod uwagę moje doświadczenia z ludźmi bez wiedz o kompie - to niestety wątpię że się mylę) że dla nowego user:


-Gnome lub KDE to będzie podstawowe środowisko
-PA to będzie podstawa obsługi dźwięku - bo ma ładne graficzne bzdety, obsługuje takie bzdety jak słuchawki na bluetooth out of the box (i to akurat jest plus nad zwykłą ALSĄ gdzie trzeba się trochę pomęczyć - chyba że coś się zmieniło),
-NM będzie podstawą sieci bo wszystko "widzi"
-O konsoli zapomnij, toć to czarna magia
-O wpisaniu "pppd call ppp0" też zapomnij - czarna magia

Do tego nowy user nie będzie wybaczający - zobaczy że dźwięk "pierdzi"? zaraz będzie "ŁEEE ten Links to gówno!", zobaczy że sterowniki do grafy się sypią? Jak wyżej. Zobaczy że nie może połączyć się z siecią przez NM? Jak wyżej itd.

To że Ja czy Ty zaraz damy:

sudo apt-get remove --purge NetworkManager

Czy PA czy cokolwiek co powoduje problem i zacznie śmigać nie ma znaczenia - nowy user nie będzie się męczyć, wróci na Windosa, przekonany że Linuks to jest gówno gdzie podstawowe rzeczy nie działają i takie info będzie słać w świat.

Jak ja zaczynałem przygodę, to kumpel miał fazę: "Debian jest the best of the best of the best" - chwalił wszystko, nawet jak wada była, mało mnie przez to nie zraził. Akurat zaczynałem od Knoppix'a, reinstalowałem go chyba ze 30 razy zanim trochę konsoli liznąłem (kumpel pomógł - z netem wtedy było krucho), i udało się kartę wifi zainstalować za pomocą ndiswrapper'a.

Ja chciałem się bawić bo mnie to ciekawiło, zwykły paź nie będzie chciał tylko zwieje z powrotem na Windos, MacOS czy Android. I właśnie dlatego uważam - i zdanie nie zmienię - że jak coś źle działa to trzeba to krytykować i wytykać, nie po to żeby sobie ponarzekać, tylko po to żeby ktoś bardziej decyzyjny to zauważył i poprawił, ale też żeby przygotować potencjalnego nowego usera, że nie wszystko jest tutaj tak cacy jak to niektórzy chwalą.

Z kolei z punktu widzenia programisty ważna jest stabilność i dojrzałość API, ale też (a raczej przede wszystkim) możliwość zarobienia na sofcie który się tworzy. Dlatego jak zamiast jednego API coś mogę zrobić na 3 czy 4 sposoby, i widzę że niektórzy to chwalą to ciężko żebym nie wskazał REALNYCH wad takiego podejścia, nie twierdzę że nie ma to żadnych zalet, ale z mojego (programisty) punktu widzenia - każde możliwe "rozgałęzienie" jest proszeniem się o problemy, bo trzeba sprawdzać czy coś co zostało ustawione przez moją aplikację, nie zostało nadpisane przez inne API bez mojej wiedzy, i znowu od programisty oczekuje się że jego aplikacja działa, usera nie obchodzi że nie działa bo PA, NM czy cykl księżyca - winny jesteś Ty, naprawić masz to Ty, a jak ktoś kasę zapłacił to naprawdę może wpakować się w niezłe szambo. Właśnie min. dlatego ludzie wolą "sprawdzone" nawet jak wiedzę że sprawdzone jest badziewne, bo czego by o Windos nie powiedzieć, to jednak API jest w dużej mierze stałe od lat, podobnie chyba jest w MacOS.

Co do NET i reszty - już pisałem w innym wątku -> dobry i przyjemny framework i dobre pieniądze się w nim zarabia - fakt że jest nieprzenośny to w sumie jedyna, aczkolwiek masakryczna, wada. Ale jak się przenośny nie, stanie to zostanie zjedzony w przeciągu kilku lat przez coś innego, nie byłby pierwszy i nie ostatni, tak więc nie ma co się przesadnie nim przejmować.

Bottom line:

Linuks się rozwija, ja to widzę, ale IMHO nie do końca idzie w dobrą stronę z wieloma rozwiązaniami desktopowymi, mimo niepodważalnych zalet ma też WADY o których trzeba pamiętać, tylko tyle i aż tyle.

Pozdrawiam.

P.S.

Prośba z mojej strony - fakt że .NET a raczej C# mi się podoba, nie znaczy że jestem jakimś fanbojem który nic innego nie używa, ciągłe dopisywanie jakichś dziwnych wrzutek że .NET to czy tamto, czy że głoszę jakieś ideologie, w  formie "szpileczek" psuje tylko dyskusję i do niczego nie prowadzi ;]