Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!

Ogłoszenie

Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.

#51  2014-05-09 08:54:08

  yossarian - Szczawiożerca

yossarian
Szczawiożerca
Skąd: Shangri-La
Zarejestrowany: 2011-04-25

Re: "Linux Sucks" - 2014

@Huk:
To już niedaleko od haseł: „Tylko jedno stabilne środowisko graficzne”, „Jedna dystrybucja”, „Jeden model samochodu” itp ;)

Dla mnie to zaleta, gdy każdy programista może tworzyć coś nowego. Lepsze projekty powinny (w teorii) z czasem wypierać te gorsze.
Zazwyczaj jest tak, że jakaś grupa nie chce z różnych powodów pracować nad jakimś projektem i tworzy konkurencyjne.
Żadne zakazy nie zmuszą ich do dalszej pracy nad projektem, który im nie pasuje.

Nawet w domu, gdy cos remontujesz możesz używać różnych narzędzi ;)
Jeden preferuje młot, drugi jakieś bardziej wyrafinowane metody ;)

Ostatnio edytowany przez yossarian (2014-05-09 08:59:53)

Offline

 

#52  2014-05-09 09:18:18

  Huk - Smoleńsk BULWA!

Huk
Smoleńsk BULWA!
Zarejestrowany: 2006-11-08

Re: "Linux Sucks" - 2014

@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.

Offline

 

#53  2014-05-09 12:01:24

  Jacekalex - Podobno człowiek...;)

Jacekalex
Podobno człowiek...;)
Skąd: /dev/random
Zarejestrowany: 2008-01-07

Re: "Linux Sucks" - 2014

@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.

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.
W Alsie zgodność z OSS jest realizowana na poziomie kernela, a nie biblioteki.
To kosmicznie uproszcza sprawę.
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 ustawisz 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.

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.

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.
Przy okazji, kiedy ostatnio kompilowałem jajo, to żadnego modułu do PA w nim nie widziałem. :D

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.
Potężny kłopot jest z Xorgiem, dlatego idzie na śmietnik historii, i krzyżyk mu na drogę.

Także ten straszny problem z czterema skrzyniami biegów, to raczej jest problem z kilkoma rożnymi rodzajami opon, z których można wybrać tylko jeden model.

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.

Ż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.

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.

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ć.

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".

Przy czym to jest problem biznesowy, a nie techniczny, i żadnej ideologii ani religii  do niego dorabiać nie trzeba.

Ostatnio edytowany przez Jacekalex (2014-05-09 22:33:42)


W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem  para bellum  ;)       |       Pozdrawiam :)

Offline

 

#54  2014-05-09 17:32:08

  Huk - Smoleńsk BULWA!

Huk
Smoleńsk BULWA!
Zarejestrowany: 2006-11-08

Re: "Linux Sucks" - 2014

@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.

Offline

 

#55  2014-05-09 19:09:41

  Jacekalex - Podobno człowiek...;)

Jacekalex
Podobno człowiek...;)
Skąd: /dev/random
Zarejestrowany: 2008-01-07

Re: "Linux Sucks" - 2014

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?

Po uporządkowaniu OpenSSL, co jest koniecznością, i po wywaleniu Xorga, co też jest koniecznością, największe problemy  Linuxa będą przeszłością, choć zawsze pozostanie kilka innych.

Podejście do Linuxa już się zmienia, jest tu i tam ostre czyszczenie kodu, ostatnio wzięli się za czyszczenie kernela.
Że ten system nie jest idealny? a znasz jakiś system idealny?

Jeżeli tu masz nadmiar bibliotek, to co można powiedzieć o Windowsowym Program Files, gdzie każdy program trzyma własne dll.ki, które czasami się dublują, kiedy np masz 10 gier, i każda trzyma własne biblioteki.

I cóżeś się tak uczepił jak rzep psiego ogona, tego PA, nawet to pieprzone GNome-3 można zbudować bez PA, KDE nigdy PA bezwzględnie nie wymagało, Xfce tez nie, o Fluxboxie, OpenBoxie, LXQT,
i mniejszych menadżerach okien nie wspominając.

A może podobnie jak pewien "developer cośtamOS" też wierzysz, że Alsa już jest niepotrzebna, bo przecież jest PA?

Jak developerzy jakiejś dystrybucji pchają PA na siłę, to ich wybór, ich małpa i ich cyrk.
Jakoś nie zauważyłem w Debianie, ani w Gentoo, żeby PA było do czegoś niezbędne.
Jedynie Gnome3 ciągnie PA w zależnościach, i nie ma za bardzo możliwości tego uniknąć, chociaż można go po prostu nie włączać, jeśli w czymś przeszkadza.

Ciągle w Twoim uzasadnieniu pojawiają się PA i NM, jakby z nich składał się Linux.
Uważam to za sporą przesadę.
Jak ktoś chce wydać program na Linuxa, to go wyda, i najwyżej wbuduje w binarkę wszystkie potrzebne biblioteki, albo je dostarczy razem z programem, np Quake4 instaluje się z własną biblioteką libSDL.
Ja widzę problem w produkcji programów na Linuxa właśnie w takich technologiach jak NET, DirectX, z których się diabelnie trudno przestawić na inne narzędzia.
Jeśli nawet w takiej korpo jak Steam, kiedy zaczęli się interesować Linuxem, to najpierw zaczęli od poszukiwania specjalistów od OpenGL,
po to, żeby za rok niespełna wydać konwerter DX9 do OpenGL  (Togl),
to widać, jakie jest przywiązanie producenta softu do M$.

Dla Linuxa przyszłością jest nie PA, tylko integracja z Androidem,
czyli wspólne API w takim zakresie, w jakim jest to możliwe.
W tym przypadku możliwości są znacznie większe, niż duże.

IOS natomiast, to jest produkt Apple, więc po support i dokumentację zapraszam do Apple.

I przy okazji, nie widzę, żeby w sofcie do przeciętnego biura w Linuxie czegoś brakowało.

W Polsce jest problem z programami "biznesowymi" typu Insert czy Symfonia, ale są ze dwa programy, które mogą je zastąpić, inne narzędzia specjalistyczne już przeważnie trzeba przetłumaczyć.
Nawet Photoshopa i Ilustratora można często całkiem sprawnie odpalić pod Wine,  co dowodzi, że Adobe chyba bardzo nieudolnie robi ten program, skoro chodzi również na innej platformie, niż Windows. :D

Do prawdziwego rozwoju Linuxa w Polsce brakuje jakiegoś mocnego Impulsu, np w Indiach po utracie wsparcia dla XP, na Linuxa migruje administracja w prowincji kilka razy większej, niż Polska.

Także w Polsce też przyjdzie czas na inny soft, może nie jutro, nie pojutrze, ale chyba  widać na horyzoncie ten moment.

A tu przykład ewolucji softu w Linuxie:

Kod:

qsize -m libreoffice-bin openoffice-bin
app-office/openoffice-bin-4.0.1: 4642 files, 373 non-files, 409 MiB
app-office/libreoffice-bin-4.1.4.2: 2963 files, 326 non-files, 280 MiB

Oczywiście nie wszystko równocześnie, ale  też widać stopniową poprawę, i usuwanie spieprzonych elementów, jak np wywalenie HALa,
myślę też, że Systemd to będzie projekt przejściowy, podobnie jak PA.

Dobry equalizer i twój PAVC-plugin, i w ogóle nie trzeba PA, a jego też może jakiś dobry człowiek kiedyś przepisze.
Lennart teraz partoli systemd, także PA może wreszcie stanie się używalne. :D


W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem  para bellum  ;)       |       Pozdrawiam :)

Offline

 

#56  2014-05-09 20:50:02

  Huk - Smoleńsk BULWA!

Huk
Smoleńsk BULWA!
Zarejestrowany: 2006-11-08

Re: "Linux Sucks" - 2014

@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:

Kod:

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 ;]

Offline

 

#57  2014-05-09 21:56:06

  Jacekalex - Podobno człowiek...;)

Jacekalex
Podobno człowiek...;)
Skąd: /dev/random
Zarejestrowany: 2008-01-07

Re: "Linux Sucks" - 2014

Zgadzam się, że Linux idzie czasem w kierunku autodestrukcji.
Np Systemd, albo skończy jak HAL, albo Linux się skończy, takie jest moje prywatne zdanie.
Nigdy żaden system nie wyszedł dobrze nad czymś, co robi wszystko, odpowiada za cale bezpieczeństwo systemu, i sam loguje to, co robi.

NM:
Czasem działa, czasem nie.
Jak nie działa, a Pacjent już trochę na Linuxie spędził, to wie, co robić.
Jak nie działa u Nooba po  instalacji, zazwyczaj mówi się trudno.

PA?
Obowiązkowe poza paroma kawałkami Gnome nie jest, i też prędzej czy później, albo osiągnie dobrą jakość, albo pójdzie do krainy wiecznych errorów.

Jak na razie, konieczność używania w Gnome-3 PA znacząco powiększyła grono użytkowników KDE, Xfce, Mate.
Jednak wystarczy, żeby domyślnym środowiskiem graficznym w CD1 Debiana stało się Xfce, i Gnome szybko pójdzie po rozum do głowy, pytanie tylko, czy go jeszcze tam znajdzie. :D
Ubuntu przepisuje Unity na QT, jeszcze rok-dwa, i Gnome może się stać niszowym środowiskiem, jak obecnie Enlightenment.

Nawet Fedorę można chyba  mieć z domyślnym Mate.
Minta domyślnie dostaniesz z Cinnamonem (ten wymaga PA), także coraz mniej Noobów ma przed nosem Gnome-3.

Podejrzewam z resztą, że PA  i Systemd to takie same "zbawienie",
jak kiedyś HAL.
Podejrzewam też, że kiedy Wayland zastąpi Xorga, to w następnej kolejności pod nóż pójdzie PA.
Czy w stabilnym  Debianie 9 Systemd będzie odpowiadał domyślnie za start systemu, na to też ani grosza nie postawię.

Krotko pisząc, Linux jest i będzie stabilniejszy, bezpieczniejszy i czasami szybszy od Windows, zazwyczaj lżejszy, ale też nie jest i nie będzie systemem idealnym.

PA i NM to ścieżka zdrowia dla Noobów?
Pamiętam inne ścieżki zdrowia z Windowsów, które mogły człowieka doprowadzić do szału.

Także tutaj też, jak dzieciak nie umie skonfigurować Linuxa, a Windowsa konfigurował Tatuś, to owszem, Linuxa wywali po 5 minutach.
Jeśli ktoś samodzielnie stawia pierwszego Linuxa, a ma obok Windę na partycji, to nawet niezbyt rozgarnięty człowiek poszuka chwilkę w necie,
i trafi na jakiś podręcznik czy forum.

Ja np w ciągu 45 minut po pierwszej w życiu instalacji Ubuntu 7.04,
wpisałem w Google:

ubuntu firewall
ubuntu antywirus
ubuntu instrukcja
ubuntu podręcznik
ubuntu sterowniki

Pierwsze dwa sznurki, jakie znalazłem:
http://ubuntuguide.org/wiki/Ubuntu:Feisty_pl
http://jakilinux.org/linux/ubuntu/13-rzeczy-do-zrob … lacji-ubuntu/

Forum było później, wytrzymałem na Linuxie do dzisiaj. :D

Linux dla masowego odbiorcy?
Android pokazał, jak to się robi.

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.

Kernel, Wayland, QT,  KDE i LXQT  idą w dobrą stronę.
Gnome - biblioteka Gtk w dobrą, środowisko wręcz przeciwnie.
PA - zaczął kiepsko, był krokiem w złą stronę, czy wyjdzie na prostą, nie wiem, na razie kierunek jest zły, ale może się to kiedyś zmieni.
NM jak wyżej.
Systemd tworzy największy w historii Linuxa SPOF, to się raczej skończy ciężką czkawką.
Błędy w nim są łatane tak samo, jak w PA.

Resumując, jak zwykle coś idzie do góry, coś w dół, ale wypadkowa tych wszystkich ruchów jest przeważnie dodatnia.
W związku z tym, myślę, że nie ma się czym martwić, zaletą tego systemu jest to, że zawsze masz wyjścia awaryjne, do tego  baza softu się stale powiększa, wiele wskazuje na to, że niedługo w Crysis pograsz na Linuxie, w związku z przygotowaniem na Linuxa silnika CryEngine.

Cóż dodać?
Cytując najbardziej znienawidzonego w WSI24 klasyka,
"Alleluja i do przodu". :D

Pozdro
;-)

Ostatnio edytowany przez Jacekalex (2014-05-09 22:19:48)


W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem  para bellum  ;)       |       Pozdrawiam :)

Offline

 

Stopka forum

Powered by PunBB
© Copyright 2002–2005 Rickard Andersson
To nie jest tylko forum, to nasza mała ojczyzna ;-)