29.03.2011 20:58
[#1]
zolty i jego brak wiedzy
Format Hunk to format systemu TRIPOS, co powinieneś doczytać.
Format hunk tak. Biblioteki nie. Najważniejsze biblioteki AmigaOS są w kickstarcie, i nie są w formacie hunk, bo dotyczy on wyłącznie binarek ładowanych z dysku.
Tylko czy to był ten Exec który obecnie znamy. Bo ten w 1.3 jest praktycznie ściągnięty z systemu TRIPOS.
Tak, to ten, który obecnie znamy. Exec w systemie 1.3 (ani żadnej innej wersji AmigaOS) nie pochodzi z Triposa, o czym świadczy cytowane przeze mnie źródło, nie jedyne zresztą.
Powinienem jeszcze dodać "bez bezsensownego przerabiania kodu
Jeżeli biblioteka otwarta przez 10 programów może zajmować w pamięci 1 MB zamiast 10 MB, to bynajmniej przerabianie kodu nie jest bezsensowne. Do tego dochodzi czas uruchamiania programów używających shared objects - linkowanie w czasie ładowania jest czasochłonne, różnica jest łatwo zauważalna.
Gdybyś pomyśłał doszedłbyś do wniosku że lepiej że lepiej jak biblioteka jest poza exe. Np można wtedy podmienić bibliotekę bez zmian exe.
Tak właśnie działają amigowe *.library, przy czym nie pochłaniają niepotrzebnie pamięci i szybciej się ładują. Implementacja *.so jest bez sensu.
>> A tak przy okazji - jaki format stratnej kompresji obrazu korzysta z kontenera RIFF?
Dokumentacja dostępna w sieci.
Rozumiem, że podanie linka Cię przerasta. To może chociaż nazwę formatu podasz.
Format hunk tak. Biblioteki nie. Najważniejsze biblioteki AmigaOS są w kickstarcie, i nie są w formacie hunk, bo dotyczy on wyłącznie binarek ładowanych z dysku.
Tylko czy to był ten Exec który obecnie znamy. Bo ten w 1.3 jest praktycznie ściągnięty z systemu TRIPOS.
Tak, to ten, który obecnie znamy. Exec w systemie 1.3 (ani żadnej innej wersji AmigaOS) nie pochodzi z Triposa, o czym świadczy cytowane przeze mnie źródło, nie jedyne zresztą.
Powinienem jeszcze dodać "bez bezsensownego przerabiania kodu
Jeżeli biblioteka otwarta przez 10 programów może zajmować w pamięci 1 MB zamiast 10 MB, to bynajmniej przerabianie kodu nie jest bezsensowne. Do tego dochodzi czas uruchamiania programów używających shared objects - linkowanie w czasie ładowania jest czasochłonne, różnica jest łatwo zauważalna.
Gdybyś pomyśłał doszedłbyś do wniosku że lepiej że lepiej jak biblioteka jest poza exe. Np można wtedy podmienić bibliotekę bez zmian exe.
Tak właśnie działają amigowe *.library, przy czym nie pochłaniają niepotrzebnie pamięci i szybciej się ładują. Implementacja *.so jest bez sensu.
>> A tak przy okazji - jaki format stratnej kompresji obrazu korzysta z kontenera RIFF?
Dokumentacja dostępna w sieci.
Rozumiem, że podanie linka Cię przerasta. To może chociaż nazwę formatu podasz.
29.03.2011 23:58
[#2]
Re: zolty i jego brak wiedzy
@G. Kraszewski, post #1
Pozwole sobie włączyć się do tego arcyciekawego wątku.
Fascynujące dla mnie jest to, jak ten szczegół cały czas się przewija w dyskusjach.
Implementacja obiektów współdzielonych mogłaby w AmigaOS 4 być lepsza. Tylko, że to nie ma żadnego znaczenia. Jeśli ktoś nie ma ochoty, to nie musi tej technologii używać. W końcu "stare dobre" Amigowe library są dalej obsługiwane. Nic nie stoi na przeszkodzie, aby podczas portowania oprogramowania pod AmigaOS 4 odwalić kawał dobrej roboty i przenieść biblioteki na true-Amigowy sposób. Skoro .so nie zastępuje .library to w czym problem? Niektóre systemy operacyjne pozwalają na ładowanie bibliotek w różnych formatach binarnych.
Jeszcze nie tak dawno niektórzy twierdzil, że "ELF is a monster". Padały setki argumentów z obu stron barykady EHF vs. ELF. Podstawowym argumentem na rzecz EHF było to, że był bardziej "Amigowy" (cokolwiek to znaczy). Jakie faktyczne znaczenie to miało dla użytkownika końcowego? Żadne*. Chodziło tylko o to, że "moja racja jest najmojsza". Teraz wszyscy neoAmigowcy używają ELFa z zapałem (i niech ktoś złe słowo śmie rzec).
Poza tym, sam format .so jest wg. mnie bardzo dobry. Poprawna jego implementacja jest pozbawiona problemów, które ciągle są wyszydzane przez osoby nielubiące OS4...
* - Pomijając fakt że cała sprawa PowerUP vs. WarpOS wyrządziła tylko szkodę użytkownikom i przyczyniła się do fiaska Amigi klasycznej z PPC. Ale różnica techniczna była tutaj pomijalna, bo format EHF nie miał żadnej przewagi na ELF.
Implementacja *.so jest bez sensu.
Fascynujące dla mnie jest to, jak ten szczegół cały czas się przewija w dyskusjach.
Implementacja obiektów współdzielonych mogłaby w AmigaOS 4 być lepsza. Tylko, że to nie ma żadnego znaczenia. Jeśli ktoś nie ma ochoty, to nie musi tej technologii używać. W końcu "stare dobre" Amigowe library są dalej obsługiwane. Nic nie stoi na przeszkodzie, aby podczas portowania oprogramowania pod AmigaOS 4 odwalić kawał dobrej roboty i przenieść biblioteki na true-Amigowy sposób. Skoro .so nie zastępuje .library to w czym problem? Niektóre systemy operacyjne pozwalają na ładowanie bibliotek w różnych formatach binarnych.
Jeszcze nie tak dawno niektórzy twierdzil, że "ELF is a monster". Padały setki argumentów z obu stron barykady EHF vs. ELF. Podstawowym argumentem na rzecz EHF było to, że był bardziej "Amigowy" (cokolwiek to znaczy). Jakie faktyczne znaczenie to miało dla użytkownika końcowego? Żadne*. Chodziło tylko o to, że "moja racja jest najmojsza". Teraz wszyscy neoAmigowcy używają ELFa z zapałem (i niech ktoś złe słowo śmie rzec).
Poza tym, sam format .so jest wg. mnie bardzo dobry. Poprawna jego implementacja jest pozbawiona problemów, które ciągle są wyszydzane przez osoby nielubiące OS4...
* - Pomijając fakt że cała sprawa PowerUP vs. WarpOS wyrządziła tylko szkodę użytkownikom i przyczyniła się do fiaska Amigi klasycznej z PPC. Ale różnica techniczna była tutaj pomijalna, bo format EHF nie miał żadnej przewagi na ELF.
30.03.2011 08:20
[#5]
Re: zolty i jego brak wiedzy
@G. Kraszewski, post #1
[quote]Amigowe .library nijak maja sie do Triposa.
Musisz się douczyć. Dokumentacja do BCPL i TRIPOS jest bez problemu dostępna.
[/quote]
Nie musze sie douczac, AmigaOS znam od strony bebechow. Sek w tym, ze nalecialosci z BCPL (typy BPTR, BSTR, wskazniki i struktury) ograniczaja sie do dos.library. Ani struct Library ani same biblioteki nie pasuja ani do BCPL ani do TRIPOS-a.
[quote]
Innymi slowy implementacja .so jest bez sensu.
Gdybyś pomyśłał doszedłbyś do wniosku że lepiej że lepiej jak biblioteka jest poza exe.
Np można wtedy podmienić bibliotekę bez zmian exe.
Również zajmuje to mniej miejsca na dysku.
[/quote]
Owszem, na dysku zajmuje to w zasadzie mniej miejsca. Pomijajac sytujacje, w ktorych z wersji na wersje zmienia sie API biblioteki i uzytkownik jest zmuszony trzymac kilka niekompatybilnych miedzy soba bibliotek. Problemy z niekompatybilnoscia bibliotek byly juz poruszane m.in. na amigans.net.
30.03.2011 08:24
[#6]
Re: zolty i jego brak wiedzy
@strim, post #2
Poza tym, sam format .so jest wg. mnie bardzo dobry. Poprawna jego implementacja jest pozbawiona problemów, które ciągle są wyszydzane przez osoby nielubiące OS4...
No to teraz przeczytaj jeszcze raz to, co napisalem. Zacytuje:
Implementacja *.so jest bez sensu.
Sposob, w jaki *.so sa zaimplementowane na OS4 jest bez sensu.
30.03.2011 08:49
[#7]
Re: zolty i jego brak wiedzy
@strim, post #2
Tylko, że to nie ma żadnego znaczenia. Jeśli ktoś nie ma ochoty, to nie musi tej technologii używać.
Mylisz się niestety. "Jeśli ktoś nie ma ochoty" to spojrzenie od strony programisty. Użytkownik już w tej chwili nie ma wyboru i musi tej technologii używać. Sposób jej implementacji w AmigaOS 4 jest taki, że pozostawia wszystkie wady, dodaje nowe i usuwa większość zalet. Wypunktujmy:
1. Shared objects zwiększają czas ładowania się programów, dlatego, że w czasie ładowania następuje linkowanie kodu programu z wszystkimi używanymi *.so.
2. Shared objects nie wymuszają wstecznej kompatybilności, efektem jest kilka wzajemnie niezgodnych wersji leżących na dysku i bałagan jaki to tworzy. Co prawda na razie dotyczy to głównie Linuksa, ale ten problem wystąpił już w AmigaOS 4.
3. W AmigaOS 4 shared objects nie są tak naprawdę współdzielone, bo każdy otwierający proces dostaje oddzielną kopię.
4. Nawet gdyby implementacja *.so w AmigaOS 4 była poprawna, istnienie wielokrotnych kopii w pamięci nadal jest możliwe z powodu 2.
To są argumenty techniczne. Co ciekawe to użytkownicy AmigaOS 4 rzucają tekstami typu "zło wcielone". Prawdopodobnie nie mają lepszego wytłumaczenia na lenistwo programistów swojego systemu, a tam gdzie kończy się rozsądek, zaczyna się propaganda.
Mylisz się niestety. "Jeśli ktoś nie ma ochoty" to spojrzenie od strony programisty. Użytkownik już w tej chwili nie ma wyboru i musi tej technologii używać. Sposób jej implementacji w AmigaOS 4 jest taki, że pozostawia wszystkie wady, dodaje nowe i usuwa większość zalet. Wypunktujmy:
1. Shared objects zwiększają czas ładowania się programów, dlatego, że w czasie ładowania następuje linkowanie kodu programu z wszystkimi używanymi *.so.
2. Shared objects nie wymuszają wstecznej kompatybilności, efektem jest kilka wzajemnie niezgodnych wersji leżących na dysku i bałagan jaki to tworzy. Co prawda na razie dotyczy to głównie Linuksa, ale ten problem wystąpił już w AmigaOS 4.
3. W AmigaOS 4 shared objects nie są tak naprawdę współdzielone, bo każdy otwierający proces dostaje oddzielną kopię.
4. Nawet gdyby implementacja *.so w AmigaOS 4 była poprawna, istnienie wielokrotnych kopii w pamięci nadal jest możliwe z powodu 2.
To są argumenty techniczne. Co ciekawe to użytkownicy AmigaOS 4 rzucają tekstami typu "zło wcielone". Prawdopodobnie nie mają lepszego wytłumaczenia na lenistwo programistów swojego systemu, a tam gdzie kończy się rozsądek, zaczyna się propaganda.
30.03.2011 10:19
[#8]
Re: zolty i jego brak wiedzy
@G. Kraszewski, post #7
Grzesiek,
O ile wiem, argumentów technicznych jest więcej i dotyczą także "library".
Czy możesz mi potwierdzić, że bez sztuczek nie możliwe łatwy import oraz eksport - symboli oraz kodu z bibliotek współdzielonych w architekturze AmigaOSu?
Objawia się to problemami przy porcie Qt oraz Galium. I wymaga zastosowania... "obejść".
Jeśli rzeczywiście tak jest - uważasz, że powinienem (nawiązując do Twojej postawy) punktować za to MOS w każdym możliwym wątku? Przecież byłby to techniczny argument, a to że nie zostało to jeszcze poprawione jest ewidentnym przykładem lenistwa programistów!
Mógłbym też poruszyć temat sterowników i mitycznego "pełnego wsparcia 3D" dla Radeonów:D To też jest poważny argument techniczny.
Tylko po co? Tyle, że jest to niepotrzebne, żal mi czasu na taką propagandę i źle wpłynie na nasze środowisko. Możesz mi odpowiedzieć co takiego Tobą kieruje, że uważasz, że każdy użytkownik AOS 4 powinien wiedzieć, jak bardzo źle zaimplementowane są wewnętrznie biblioteki .so?
Może jest jakiś konkurs na czystość kodu i liczysz na większą ilość głosów?
Jak chcesz - mogę Ci przyznać nagrodę pod postacią "złotych kalesonów"
PS. Poza tym .so chyba nie ma obecnie w publicznej wersji MOS, co nie? Więc Twoje argumenty bardziej przypominają: "Ale w AOS 4.1 jest kiepska implementacja .so. My zrobilibyśmy lepszą gdyby nam się chciało. Ale się nam nie chce bo nie są potrzebne". To z kolei nie jest rozsądek - tylko racjonalizacja. Niekoniecznie pozytywny zabieg psychologiczny
___uaktualnienie___
Bo tak mi się przypomniało:D
1. Jesteś w stanie podać mi przykład programów działających pod AmigaOS, które wykorzystują bibliotekę .so o rozmiarze ponad 1MB, a które chciałbym uruchomić w jednoczesnej liczbie 10 sztuk?
2. Czy jesteś w stanie podać mi O ILE zostanie spowolnione włączenie programu przez wczytanie biblioteki .so o rozmiarze 1MB
3. Czy problem niezgodnych wersji bibliotek nie dotyczy także innych bibliotek w AmigaOS?
Szczególnie istotne jest dla mnie 1&2, bo może te "bardzo ważne problemy implementacji .so w AOS 4" po prostu się nie objawiają przy normalnym (aktualnie) użytkowaniu systemu i nie mają wymiernego wpływu na działania użytkownika?
Ostatnia modyfikacja: 30.03.2011 10:56:04
O ile wiem, argumentów technicznych jest więcej i dotyczą także "library".
Czy możesz mi potwierdzić, że bez sztuczek nie możliwe łatwy import oraz eksport - symboli oraz kodu z bibliotek współdzielonych w architekturze AmigaOSu?
Objawia się to problemami przy porcie Qt oraz Galium. I wymaga zastosowania... "obejść".
Jeśli rzeczywiście tak jest - uważasz, że powinienem (nawiązując do Twojej postawy) punktować za to MOS w każdym możliwym wątku? Przecież byłby to techniczny argument, a to że nie zostało to jeszcze poprawione jest ewidentnym przykładem lenistwa programistów!
Mógłbym też poruszyć temat sterowników i mitycznego "pełnego wsparcia 3D" dla Radeonów:D To też jest poważny argument techniczny.
Tylko po co? Tyle, że jest to niepotrzebne, żal mi czasu na taką propagandę i źle wpłynie na nasze środowisko. Możesz mi odpowiedzieć co takiego Tobą kieruje, że uważasz, że każdy użytkownik AOS 4 powinien wiedzieć, jak bardzo źle zaimplementowane są wewnętrznie biblioteki .so?
Może jest jakiś konkurs na czystość kodu i liczysz na większą ilość głosów?
Jak chcesz - mogę Ci przyznać nagrodę pod postacią "złotych kalesonów"
PS. Poza tym .so chyba nie ma obecnie w publicznej wersji MOS, co nie? Więc Twoje argumenty bardziej przypominają: "Ale w AOS 4.1 jest kiepska implementacja .so. My zrobilibyśmy lepszą gdyby nam się chciało. Ale się nam nie chce bo nie są potrzebne". To z kolei nie jest rozsądek - tylko racjonalizacja. Niekoniecznie pozytywny zabieg psychologiczny
___uaktualnienie___
Bo tak mi się przypomniało:D
1. Jesteś w stanie podać mi przykład programów działających pod AmigaOS, które wykorzystują bibliotekę .so o rozmiarze ponad 1MB, a które chciałbym uruchomić w jednoczesnej liczbie 10 sztuk?
2. Czy jesteś w stanie podać mi O ILE zostanie spowolnione włączenie programu przez wczytanie biblioteki .so o rozmiarze 1MB
3. Czy problem niezgodnych wersji bibliotek nie dotyczy także innych bibliotek w AmigaOS?
Szczególnie istotne jest dla mnie 1&2, bo może te "bardzo ważne problemy implementacji .so w AOS 4" po prostu się nie objawiają przy normalnym (aktualnie) użytkowaniu systemu i nie mają wymiernego wpływu na działania użytkownika?
Ostatnia modyfikacja: 30.03.2011 10:56:04
30.03.2011 11:06
[#9]
Re: zolty i jego brak wiedzy
@Radov, post #8
Czy możesz mi potwierdzić, że bez sztuczek nie możliwe łatwy import oraz eksport - symboli oraz kodu z bibliotek współdzielonych w architekturze AmigaOSu? Objawia się to problemami przy porcie Qt oraz Galium. I wymaga zastosowania... "obejść".
W architekturze AmigaOS import symboli i kodu z bibliotek współdzielonych nie jest potrzebny. Dopiero wprowadzenie do systemu obcych rozwiązań takich jak Qt czy Gallium takowy import wymusza. Tu dotykamy sprawy fundamentalnej, a więc strategii rozwoju systemu AmigaOS 4 i strategii rozwoju MorphOS-a. Podany przez Ciebie przykład dobitnie pokazuje różnice między tymi strategiami. Uważam, że po podjęciu decyzji o zastosowaniu jakiejś "obcej" technologii w tych systemach, programiści AmigaOS 4 dostosowują system do tej technologii, programiści MorphOS-a natomiast dostosowują technologię do systemu.
Dodatkowo w MorphOS-ie dana technologia pojawia się wtedy, jeżeli naprawdę wnosi coś wartościowego i zwiększa możliwości systemu, a nie tylko zastępuje coś, co w AmigaOS istniało od dawna, wymagało może jedynie aktualizacji. Taki przyjęto paradygmat, "AmigaOS nie stać na własne rozwiązania". Taki kierunek rozwoju AmigaOS 4 mi nie odpowiada, dlatego go krytykuję, pokazując jakie to za sobą pociąga skutki. Nie chodzi mi tu o żadne punktowanie w rodzaju wytykania czego brak w MorphOS-ie a czego w AmigaOS-ie. Chodzi o generalną strategię rozwoju i stawiane sobie cele. Uważam, że AmigaOS 4 zmierza w złym kierunku i daję temu wyraz. Swoje poglądy uzasadniam rzeczowymi argumentami, a nie pisaniem o wcielonym źle i czerwonej zarazie.
Moim zdaniem ta pogoń za peletonem, jakiej próbują programiści AmigaOS 4, jest skazana na porażkę. Największych systemów operacyjnych i tak nie dogonią, bo do tego potrzeba dużych pieniędzy. Bezkrytycznie ładując do systemu nie zawsze wysokich lotów linuksowe rozwiązania i naginając do nich system powodują utratę tożsamości tego ostatniego i robią z niego składnicę mniej lub bardziej losowo dobranych komponentów. MorphOS nie stawia sobie za cel równania do Windowsa czy Linuksa, chce być odrębnym systemem z wyrazistą tożsamością. Systemem hobbystyczno-niszowym, budowanym w sposób przemyślany i spójnym. Bez uciekania się do retoryki klasy "system, na który nie ma portu Firefoxa jest nic nie wart". Poczekajmy aż Timberwolf dorówna funkcjonalnością i szybkością działania morphosowemu OWB...
Możesz mi odpowiedzieć co takiego Tobą kieruje, że uważasz, że każdy użytkownik AOS 4 powinien wiedzieć, jak bardzo źle zaimplementowane są wewnętrznie biblioteki .so? Może jest jakiś konkurs na czystość kodu i liczysz na większą ilość głosów?
A dlaczego sądzisz, że lepiej, żeby nie wiedział? Mam nadzieję, że ci użytkownicy, którzy system oceniają nieco głębiej niż poprzez wygląd ikonek i ramki okien, zauważą postępującą od wewnątrz dezintegrację AmigaOS 4. Wtedy być może docenią MorphOS-a i pracę weń wkładaną przez programistów, dla których wyznacznikiem jakości systemu nie jest ilość przeportowanych gier pod SDL. Systemu, który stać na własne rozwiązania. Amigowa tradycja liczy się nie tylko po stronie użytkownika, ale również po stronie programisty. Bo jeżeli to odrzucimy to co nam pozostanie? Chyba tylko słynne "żerowanie na marce"...
Mam nadzieję, że ten, być może przydługawy, post wyjaśni Ci i innym czytelnikom moją postawę wobec AmigaOS 4. Nie interesują mnie personalne rozgrywki, docinanie użytkownikom tego systemu, ani punktowanie w rodzaju "u was nie działa to, a u was nie działa tamto". Pan "zolty" postanowił się popisać swoją niewiedzą, stąd być może nieco ostrzejsza w tonie moja wypowiedź, ale na wciskanie kitu jestem uczulony.
Po prostu moja definicja "amigowania" wypływa z moich 17 lat programowania pod AmigaOS i poznawania fascynującej budowy tego systemu, a później twórczego jego rozwijania. Jeżeli teraz ktoś pod maską AmigaOS chce mi sprzedać X-Window, shared objects, Gallium i Qt, to sorry, ale ja tego nie kupuję. Bardzo cienka granica dzieli taką propozycję od wynalazków pana Altmana z Commodore USA. Co więcej, obawiam się, że programiści AmigaOS 4 nie będą mieli większych skrupułów, żeby granicę tę przekroczyć. W tym momencie nasze drogi się rozejdą zupełnie.
W architekturze AmigaOS import symboli i kodu z bibliotek współdzielonych nie jest potrzebny. Dopiero wprowadzenie do systemu obcych rozwiązań takich jak Qt czy Gallium takowy import wymusza. Tu dotykamy sprawy fundamentalnej, a więc strategii rozwoju systemu AmigaOS 4 i strategii rozwoju MorphOS-a. Podany przez Ciebie przykład dobitnie pokazuje różnice między tymi strategiami. Uważam, że po podjęciu decyzji o zastosowaniu jakiejś "obcej" technologii w tych systemach, programiści AmigaOS 4 dostosowują system do tej technologii, programiści MorphOS-a natomiast dostosowują technologię do systemu.
Dodatkowo w MorphOS-ie dana technologia pojawia się wtedy, jeżeli naprawdę wnosi coś wartościowego i zwiększa możliwości systemu, a nie tylko zastępuje coś, co w AmigaOS istniało od dawna, wymagało może jedynie aktualizacji. Taki przyjęto paradygmat, "AmigaOS nie stać na własne rozwiązania". Taki kierunek rozwoju AmigaOS 4 mi nie odpowiada, dlatego go krytykuję, pokazując jakie to za sobą pociąga skutki. Nie chodzi mi tu o żadne punktowanie w rodzaju wytykania czego brak w MorphOS-ie a czego w AmigaOS-ie. Chodzi o generalną strategię rozwoju i stawiane sobie cele. Uważam, że AmigaOS 4 zmierza w złym kierunku i daję temu wyraz. Swoje poglądy uzasadniam rzeczowymi argumentami, a nie pisaniem o wcielonym źle i czerwonej zarazie.
Moim zdaniem ta pogoń za peletonem, jakiej próbują programiści AmigaOS 4, jest skazana na porażkę. Największych systemów operacyjnych i tak nie dogonią, bo do tego potrzeba dużych pieniędzy. Bezkrytycznie ładując do systemu nie zawsze wysokich lotów linuksowe rozwiązania i naginając do nich system powodują utratę tożsamości tego ostatniego i robią z niego składnicę mniej lub bardziej losowo dobranych komponentów. MorphOS nie stawia sobie za cel równania do Windowsa czy Linuksa, chce być odrębnym systemem z wyrazistą tożsamością. Systemem hobbystyczno-niszowym, budowanym w sposób przemyślany i spójnym. Bez uciekania się do retoryki klasy "system, na który nie ma portu Firefoxa jest nic nie wart". Poczekajmy aż Timberwolf dorówna funkcjonalnością i szybkością działania morphosowemu OWB...
Możesz mi odpowiedzieć co takiego Tobą kieruje, że uważasz, że każdy użytkownik AOS 4 powinien wiedzieć, jak bardzo źle zaimplementowane są wewnętrznie biblioteki .so? Może jest jakiś konkurs na czystość kodu i liczysz na większą ilość głosów?
A dlaczego sądzisz, że lepiej, żeby nie wiedział? Mam nadzieję, że ci użytkownicy, którzy system oceniają nieco głębiej niż poprzez wygląd ikonek i ramki okien, zauważą postępującą od wewnątrz dezintegrację AmigaOS 4. Wtedy być może docenią MorphOS-a i pracę weń wkładaną przez programistów, dla których wyznacznikiem jakości systemu nie jest ilość przeportowanych gier pod SDL. Systemu, który stać na własne rozwiązania. Amigowa tradycja liczy się nie tylko po stronie użytkownika, ale również po stronie programisty. Bo jeżeli to odrzucimy to co nam pozostanie? Chyba tylko słynne "żerowanie na marce"...
Mam nadzieję, że ten, być może przydługawy, post wyjaśni Ci i innym czytelnikom moją postawę wobec AmigaOS 4. Nie interesują mnie personalne rozgrywki, docinanie użytkownikom tego systemu, ani punktowanie w rodzaju "u was nie działa to, a u was nie działa tamto". Pan "zolty" postanowił się popisać swoją niewiedzą, stąd być może nieco ostrzejsza w tonie moja wypowiedź, ale na wciskanie kitu jestem uczulony.
Po prostu moja definicja "amigowania" wypływa z moich 17 lat programowania pod AmigaOS i poznawania fascynującej budowy tego systemu, a później twórczego jego rozwijania. Jeżeli teraz ktoś pod maską AmigaOS chce mi sprzedać X-Window, shared objects, Gallium i Qt, to sorry, ale ja tego nie kupuję. Bardzo cienka granica dzieli taką propozycję od wynalazków pana Altmana z Commodore USA. Co więcej, obawiam się, że programiści AmigaOS 4 nie będą mieli większych skrupułów, żeby granicę tę przekroczyć. W tym momencie nasze drogi się rozejdą zupełnie.
30.03.2011 11:24
[#10]
Re: zolty i jego brak wiedzy
@G. Kraszewski, post #7
@szuler
Toteż hmm... ja nie próbuje bronić obecnej implementacji, bo też uważam że jest nieoptymalna. Jednak nie uważam, żeby ogólnie pomysł dodania obsługi shared objects był zły. Może w przyszłości ktoś go poprawi? ;)
@Krashan
Ad 1. To prawda, że linkowanie w czasie uruchamiania programu jest wolniejsze od klasycznego Amigowego podejścia. Tylko nikt tak naprawdę nie zmierzył o ile. Poza tym wymyślono masę technik, które redukują czas uruchamiania (niestety żadna z nich nie jest dostępna w OS4). Np. prelinking, "leniwe" ładowanie bibliotek dopiero gdy są faktycznie potrzebne, redukowanie liczby relokacji etc.
Ad 2. Nie wymuszają, to prawda. Jednak w przypadku systemów Unixowych jest on rzadko zauważalny, gdyż prawie wszyscy tam korzystają z paczek. Czy AmigaOS z narzędziem AmiUpdate nie idzie w tym kierunku? Poza tym, przecież dodanie kilku nowych funkcji do biblioteki nie powoduje automatycznie jej niekomatybilności. Problem dopiero jest gdy zmienia się istniejące funkcje w bibliotece lub jakieś usuwa. A to nie jest tak bardzo powszechne.
Ad 3. Tak jest.
Ad 4. Gdyby implementacja była poprawna, a oprogramowanie korzystało zawsze z bibliotek zainstalowanych w systemie (a nie rozprowadzanych wraz z aplikacją) i było np. auktualizowane AmiUpdate'em to nie byłoby to zauważalne. W ogóle to ja bym ten punkt traktował jako plus. Dlatego, że w razie potrzebny można to zrobić. Tzn. uruchomić program X z wersją 1 biblioteki, a program Y z wersją 2. Oczywiście najlepiej by było, gdyby taka sytuacja nie była konieczna. Ale nie uważam, żeby to była wada.
Poza tym z bibliotekami so można robić masę fajnych rzeczy. Np. pominąć run time linker używając mechanizmu dlopen. Jest to podobne do sposobu w jaki otwiera się typowe biblioteki AmigaOS. Albo można np. preload'ować je i podmieniać w ten sposób pewne funkcje systemu operacyjnego (a właściwie innych bibliotek, z których program korzysta).
Jeszcze taka ciekawostka ;)
Nie dawno wymyślono coś co zwie się WebP. Jak się okazuje, jest właśnie formatem stratnej kompresji obrazu w RIFF.
Ostatnia modyfikacja: 30.03.2011 11:25:20
Sposob, w jaki *.so sa zaimplementowane na OS4 jest bez sensu.
Toteż hmm... ja nie próbuje bronić obecnej implementacji, bo też uważam że jest nieoptymalna. Jednak nie uważam, żeby ogólnie pomysł dodania obsługi shared objects był zły. Może w przyszłości ktoś go poprawi? ;)
@Krashan
Ad 1. To prawda, że linkowanie w czasie uruchamiania programu jest wolniejsze od klasycznego Amigowego podejścia. Tylko nikt tak naprawdę nie zmierzył o ile. Poza tym wymyślono masę technik, które redukują czas uruchamiania (niestety żadna z nich nie jest dostępna w OS4). Np. prelinking, "leniwe" ładowanie bibliotek dopiero gdy są faktycznie potrzebne, redukowanie liczby relokacji etc.
Ad 2. Nie wymuszają, to prawda. Jednak w przypadku systemów Unixowych jest on rzadko zauważalny, gdyż prawie wszyscy tam korzystają z paczek. Czy AmigaOS z narzędziem AmiUpdate nie idzie w tym kierunku? Poza tym, przecież dodanie kilku nowych funkcji do biblioteki nie powoduje automatycznie jej niekomatybilności. Problem dopiero jest gdy zmienia się istniejące funkcje w bibliotece lub jakieś usuwa. A to nie jest tak bardzo powszechne.
Ad 3. Tak jest.
Ad 4. Gdyby implementacja była poprawna, a oprogramowanie korzystało zawsze z bibliotek zainstalowanych w systemie (a nie rozprowadzanych wraz z aplikacją) i było np. auktualizowane AmiUpdate'em to nie byłoby to zauważalne. W ogóle to ja bym ten punkt traktował jako plus. Dlatego, że w razie potrzebny można to zrobić. Tzn. uruchomić program X z wersją 1 biblioteki, a program Y z wersją 2. Oczywiście najlepiej by było, gdyby taka sytuacja nie była konieczna. Ale nie uważam, żeby to była wada.
Poza tym z bibliotekami so można robić masę fajnych rzeczy. Np. pominąć run time linker używając mechanizmu dlopen. Jest to podobne do sposobu w jaki otwiera się typowe biblioteki AmigaOS. Albo można np. preload'ować je i podmieniać w ten sposób pewne funkcje systemu operacyjnego (a właściwie innych bibliotek, z których program korzysta).
Jeszcze taka ciekawostka ;)
A tak przy okazji - jaki format stratnej kompresji obrazu korzysta z kontenera RIFF?
Nie dawno wymyślono coś co zwie się WebP. Jak się okazuje, jest właśnie formatem stratnej kompresji obrazu w RIFF.
Ostatnia modyfikacja: 30.03.2011 11:25:20
30.03.2011 11:25
[#11]
Re: zolty i jego brak wiedzy
@Radov, post #8
1. Jesteś w stanie podać mi przykład programów działających pod AmigaOS, które wykorzystują bibliotekę .so o rozmiarze ponad 1MB, a które chciałbym uruchomić w jednoczesnej liczbie 10 sztuk?
2. Czy jesteś w stanie podać mi O ILE zostanie spowolnione włączenie programu przez wczytanie biblioteki .so o rozmiarze 1MB
3. Czy problem niezgodnych wersji bibliotek nie dotyczy także innych bibliotek w AmigaOS?
Problem tworzenia wielokrotnych kopii tej samej biblioteki nie znika automagicznie, jeżeli biblioteka ma mniej niż megabajt. Nie znika też, jeżeli kopie są dwie a nie dziesięć. To jest problem jakościowy, nie ilościowy. Po prostu twórcy systemu poszli po najmniejszej linii oporu. Skutki ich niedbalstwa mogą być odczuwalne mniej lub bardziej, w zależności od zestawu używanego oprogramowania. Pamiętaj o tym, że system operacyjny projektuje się na lata, a skutki błędnych decyzji projektowych odbijają się czkawką również przez lata.
Jeżeli chodzi o zwolnienie wczytywania, w mniejszym stopniu zależy to od wielkości linkowanych obiektów, w większym od ilości ładowanych *.so, ilości symboli do zlinkowania, oraz wzajemnych zależności między *.so. Prosty przykład, wyobraźmy sobie projekt używający pnglib i zlib, przy czym, jak wiadomo, pnglib również korzysta ze zlib. Jeżeli sama aplikacja jest zlinkowana dynamicznie i pnglib jest również zlinkowana dynamicznie, to rozwiązywanie symboli z zlib odbędzie się dwukrotnie - raz dla aplikacji, raz dla pnglib. Gdyby obie biblioteki były w formacie *.library, to każde kolejne otwarcie z.library – oprócz pierwszego – jest momentalne i nie wiąże się nawet z wczytaniem czegokolwiek z dysku. Dotyczy to również sytuacji, gdy z.library otworzy inna aplikacja (czy to bezpośrednio, czy przez inną bibliotekę jej używającą), w tym przypadku AmigaOS 4 utworzy drugą kopię w pamięci.
Jeżeli chodzi o problem niezgodnych bibliotek - nie dotyczy on amigowych *.library dlatego, że z definicji każda nowa wersja biblioteki o danej nazwie musi być kompatybilna wstecz. Jeżeli nie - taka biblioteka będzie po prostu wieszać aplikacje i nastąpi brutalna selekcja negatywna. Rozwiązanie proste i skuteczne.
Oczywiście możesz to wszystko skwitować krótkim "a co to użytkownika obchodzi". Może nic. Mnie obchodzi. W sytuacji kiedy przestrzeń adresowa systemu jest ograniczona do 2 GB, nie jest to bez znaczenia. Zakładam, że jeżeli ktoś w 2011 roku interesuje się amisystemami, to obchodzi go coś więcej niż tylko "żeby jutube i fejsbuk działały".
2. Czy jesteś w stanie podać mi O ILE zostanie spowolnione włączenie programu przez wczytanie biblioteki .so o rozmiarze 1MB
3. Czy problem niezgodnych wersji bibliotek nie dotyczy także innych bibliotek w AmigaOS?
Problem tworzenia wielokrotnych kopii tej samej biblioteki nie znika automagicznie, jeżeli biblioteka ma mniej niż megabajt. Nie znika też, jeżeli kopie są dwie a nie dziesięć. To jest problem jakościowy, nie ilościowy. Po prostu twórcy systemu poszli po najmniejszej linii oporu. Skutki ich niedbalstwa mogą być odczuwalne mniej lub bardziej, w zależności od zestawu używanego oprogramowania. Pamiętaj o tym, że system operacyjny projektuje się na lata, a skutki błędnych decyzji projektowych odbijają się czkawką również przez lata.
Jeżeli chodzi o zwolnienie wczytywania, w mniejszym stopniu zależy to od wielkości linkowanych obiektów, w większym od ilości ładowanych *.so, ilości symboli do zlinkowania, oraz wzajemnych zależności między *.so. Prosty przykład, wyobraźmy sobie projekt używający pnglib i zlib, przy czym, jak wiadomo, pnglib również korzysta ze zlib. Jeżeli sama aplikacja jest zlinkowana dynamicznie i pnglib jest również zlinkowana dynamicznie, to rozwiązywanie symboli z zlib odbędzie się dwukrotnie - raz dla aplikacji, raz dla pnglib. Gdyby obie biblioteki były w formacie *.library, to każde kolejne otwarcie z.library – oprócz pierwszego – jest momentalne i nie wiąże się nawet z wczytaniem czegokolwiek z dysku. Dotyczy to również sytuacji, gdy z.library otworzy inna aplikacja (czy to bezpośrednio, czy przez inną bibliotekę jej używającą), w tym przypadku AmigaOS 4 utworzy drugą kopię w pamięci.
Jeżeli chodzi o problem niezgodnych bibliotek - nie dotyczy on amigowych *.library dlatego, że z definicji każda nowa wersja biblioteki o danej nazwie musi być kompatybilna wstecz. Jeżeli nie - taka biblioteka będzie po prostu wieszać aplikacje i nastąpi brutalna selekcja negatywna. Rozwiązanie proste i skuteczne.
Oczywiście możesz to wszystko skwitować krótkim "a co to użytkownika obchodzi". Może nic. Mnie obchodzi. W sytuacji kiedy przestrzeń adresowa systemu jest ograniczona do 2 GB, nie jest to bez znaczenia. Zakładam, że jeżeli ktoś w 2011 roku interesuje się amisystemami, to obchodzi go coś więcej niż tylko "żeby jutube i fejsbuk działały".
30.03.2011 11:40
[#12]
Re: zolty i jego brak wiedzy
@strim, post #10
To prawda, że linkowanie w czasie uruchamiania programu jest wolniejsze od klasycznego Amigowego podejścia. Tylko nikt tak naprawdę nie zmierzył o ile. Poza tym wymyślono masę technik, które redukują czas uruchamiania (niestety żadna z nich nie jest dostępna w OS4). Np. prelinking, "leniwe" ładowanie bibliotek dopiero gdy są faktycznie potrzebne, redukowanie liczby relokacji etc.
Żeby to dokładnie zmierzyć, trzebaby napisać jedną aplikację na dwa sposoby. I uruchomić na tym samym sprzęcie. Co do technik wymienionych przez Ciebie - wszystko fajnie, ale jak sam zauważyłeś, nie są one dostępne w AmigaOS 4, to po pierwsze. Po drugie techniki te komplikują główną technologię i powodują, że kernel obrasta różnymi dziwnymi sztuczkami. Zarządzanie bardziej złożonym kodem jest trudniejsze i coraz mniej osób jest w stanie ten kod ogarnąć. Siłą amisystemów jest prostota wewnętrznych rozwiązań.
Jednak w przypadku systemów Unixowych jest on rzadko zauważalny, gdyż prawie wszyscy tam korzystają z paczek. Czy AmigaOS z narzędziem AmiUpdate nie idzie w tym kierunku?
W kierunku Uniksa? Zgadza się, idzie...
W ogóle to ja bym ten punkt traktował jako plus. Dlatego, że w razie potrzebny można to zrobić. Tzn. uruchomić program X z wersją 1 biblioteki, a program Y z wersją 2
Dla mnie to raczej zwiększanie bałaganu niż zaleta. Typowe leczenie skutków zamiast przyczyny. Bo nikt sobie nie zadaje pytania co za idiota stworzył wzajemnie niekompatybilne wersje tej samej biblioteki.
Poza tym z bibliotekami so można robić masę fajnych rzeczy. Np. pominąć run time linker używając mechanizmu dlopen. Jest to podobne do sposobu w jaki otwiera się typowe biblioteki AmigaOS. Albo można np. preload'ować je i podmieniać w ten sposób pewne funkcje systemu operacyjnego (a właściwie innych bibliotek, z których program korzysta).
Czyli najpierw wyrzucamy dobre i proste rozwiązanie, które potrafi zarówno nie używać runtime linkera jak i umożliwia podmianę funkcji systemu. Potem ładujemy rozwiązanie z innego systemu mające sporo wad, kiepską implementacją dodajemy kolejne. A potem się zachwycamy że można robić takie same rzeczy jak w tym pierwszym rozwiązaniu. Logika++;
Nie dawno wymyślono coś co zwie się WebP. Jak się okazuje, jest właśnie formatem stratnej kompresji obrazu w RIFF.
Ale nie zrobił tego Microsoft, jak mi kolega "zolty" sugerował...
Żeby to dokładnie zmierzyć, trzebaby napisać jedną aplikację na dwa sposoby. I uruchomić na tym samym sprzęcie. Co do technik wymienionych przez Ciebie - wszystko fajnie, ale jak sam zauważyłeś, nie są one dostępne w AmigaOS 4, to po pierwsze. Po drugie techniki te komplikują główną technologię i powodują, że kernel obrasta różnymi dziwnymi sztuczkami. Zarządzanie bardziej złożonym kodem jest trudniejsze i coraz mniej osób jest w stanie ten kod ogarnąć. Siłą amisystemów jest prostota wewnętrznych rozwiązań.
Jednak w przypadku systemów Unixowych jest on rzadko zauważalny, gdyż prawie wszyscy tam korzystają z paczek. Czy AmigaOS z narzędziem AmiUpdate nie idzie w tym kierunku?
W kierunku Uniksa? Zgadza się, idzie...
W ogóle to ja bym ten punkt traktował jako plus. Dlatego, że w razie potrzebny można to zrobić. Tzn. uruchomić program X z wersją 1 biblioteki, a program Y z wersją 2
Dla mnie to raczej zwiększanie bałaganu niż zaleta. Typowe leczenie skutków zamiast przyczyny. Bo nikt sobie nie zadaje pytania co za idiota stworzył wzajemnie niekompatybilne wersje tej samej biblioteki.
Poza tym z bibliotekami so można robić masę fajnych rzeczy. Np. pominąć run time linker używając mechanizmu dlopen. Jest to podobne do sposobu w jaki otwiera się typowe biblioteki AmigaOS. Albo można np. preload'ować je i podmieniać w ten sposób pewne funkcje systemu operacyjnego (a właściwie innych bibliotek, z których program korzysta).
Czyli najpierw wyrzucamy dobre i proste rozwiązanie, które potrafi zarówno nie używać runtime linkera jak i umożliwia podmianę funkcji systemu. Potem ładujemy rozwiązanie z innego systemu mające sporo wad, kiepską implementacją dodajemy kolejne. A potem się zachwycamy że można robić takie same rzeczy jak w tym pierwszym rozwiązaniu. Logika++;
Nie dawno wymyślono coś co zwie się WebP. Jak się okazuje, jest właśnie formatem stratnej kompresji obrazu w RIFF.
Ale nie zrobił tego Microsoft, jak mi kolega "zolty" sugerował...
30.03.2011 11:58
[#13]
Re: zolty i jego brak wiedzy
@G. Kraszewski, post #12
W kierunku Uniksa? Zgadza się, idzie...
Akurat chodziło mi o to, że idzie w stronę zarządzania paczkami jak w Unixie. Tylko chyba programiści piszący pod OS4 jeszcze tego nie ogarniają, stąd wspomniane problemy z różnymi wersjami bibliotek.
Czyli najpierw wyrzucamy dobre i proste rozwiązanie...
Cała rzecz w tym, że nikt go nie wywalił i (raczej?) nie planuje tego zrobić.
Jak w AmigaOS, korzystając z klasycznego podejścia można osiągnąć to samo co w Unixie przez LD_PRELOAD? Nie szydzę, tylko faktycznie nie wiem.
Ja się nie zachwycam. Tylko nie uważam żeby sama technologia shared objects była zła.
30.03.2011 12:11
[#14]
Re: zolty i jego brak wiedzy
@strim, post #13
Ja się nie zachwycam. Tylko nie uważam żeby sama technologia shared objects była zła.
Sama technologia nie jest zła, niech sobie w uniksach będzie... Wepchanie jej na siłę do AmigaOS 4 w sposób, w jaki to zrobiono jest dla mnie wadą tego systemu. A propos tego, że nikt nie wywalił - zgoda, jako programista nie muszę jej używać, jako użytkownik nie mam wyboru...
Sama technologia nie jest zła, niech sobie w uniksach będzie... Wepchanie jej na siłę do AmigaOS 4 w sposób, w jaki to zrobiono jest dla mnie wadą tego systemu. A propos tego, że nikt nie wywalił - zgoda, jako programista nie muszę jej używać, jako użytkownik nie mam wyboru...
30.03.2011 12:47
[#15]
Re: zolty i jego brak wiedzy
@strim, post #13
Jak w AmigaOS, korzystając z klasycznego podejścia można osiągnąć to samo co w Unixie przez LD_PRELOAD?
Na ile dobrze zrozumiałem opisy, przy pomocy LD_PRELOAD osiąga się efekt "przejęcia" określonych funkcji danej biblioteki. Taki efekt w AmigaOS i pochodnych uzyskuje się pisząc programik otwierający daną bibliotekę a następnie zmieniający wektory funkcji z jej API za pomocą SetFunction(). Różnica jest taka, że LD_PRELOAD działa tylko na jeden program, a SetFunction() globalnie, chyba że w przekierowanym kodzie sprawdzimy nazwę procesu i wywołamy zmieniony kod tylko dla określonego, pozostałe procesy wykonają kod oryginalny.
Na ile dobrze zrozumiałem opisy, przy pomocy LD_PRELOAD osiąga się efekt "przejęcia" określonych funkcji danej biblioteki. Taki efekt w AmigaOS i pochodnych uzyskuje się pisząc programik otwierający daną bibliotekę a następnie zmieniający wektory funkcji z jej API za pomocą SetFunction(). Różnica jest taka, że LD_PRELOAD działa tylko na jeden program, a SetFunction() globalnie, chyba że w przekierowanym kodzie sprawdzimy nazwę procesu i wywołamy zmieniony kod tylko dla określonego, pozostałe procesy wykonają kod oryginalny.
30.03.2011 15:33
[#16]
Re: zolty i jego brak wiedzy
@G. Kraszewski, post #11
Problem tworzenia wielokrotnych kopii tej samej biblioteki nie znika automagicznie, jeżeli biblioteka ma mniej niż megabajt. Nie znika też, jeżeli kopie są dwie a nie dziesięć.
Ale nie występuje, z definicji, jeśli biblioteka kopii *nie ma* ;) Pytanie jest więc proste - czy te problemy mają znaczenie w praktyce?
Ile muszę uruchomić aplikacji, żeby stwierdzić, że problemy mają znaczący wpływ na działanie systemu w innych warunkach niż testowe?
Ja wiem, że mogę uruchomić 10 kopii Timberwolfa żeby taki efekt uzyskać. Tylko po co właściwe będę potrzebował uruchamiać 10 kopii Timberwolf (w celu innym niż potwierdzić niepełną implementację .so)?
Jedyna możliwość, to że 10 różnych programów będzie korzystać z tej samej biblioteki. Tak więc ponowię pytanie:
- Jakie 10 różnych aplikacji wykorzystuje takie biblioteki .so, że istnienie ich kopii powinno wymusić na Friedenach porzucenie jakichkolwiek innych prac i naprawienie tego właśnie problemu?
Wydaje mi się, że nie muszę tłumaczyć, że priorytetem naprawy błędów powinna być ich uciążliwość oraz częstotliwość występowania.:
- dla .so te wartości są w praktyce po prostu niskie
- dla podsystemu 3D z kolei wysokie.
Dlaczego więc, jak odnoszę wrażenie, z takim priorytetem sugerujesz naprawę .so (które w gruncie rzeczy działa), zamiast dokończenie portu Gallium (bo 3D w gruncie rzeczy działa niezbyt dobrze)? Może więc nie ma tu mowy o lenistwie Friedenów, tylko zwykłe (racjonalne) oszacowanie zagrożeń i ryzyka?
Problem nazewnictwa bibliotek:
Ale z tego co kojarzę z zamierzchłych czasów MA - to wcale nie jest skutecznym rozwiązaniem. Czyż nie ma setek programów, które wymagają obecności KONKRETNEJ wersji biblioteki? Użytkowników, którzy próbują różnych wersji bibliotek, aż do uzyskania pełnej stabilności? Moim zdaniem problem wciąż występuje - ale objawia się w inny sposób.
Co więcej - przy takim rozwiązaniu aplikacje powinny być dostarczane z tymi wersjami bibliotek, z którymi producent gwarantuje działanie:)
Czyli problem ze zgodnością w .so zamieniamy na... konieczność posiadania kilku kopii biblioteki oraz problem dystrybucji:)
Dodatkowo, jeśli będziesz mieć na dysku kilka niezgodnych kopii biblioteki oraz programy je wykorzystujące - to do pamięci zostanie wczytane kilka kopii funkcjonalnie zbieżnego kodu.
Mam rację, czy nie mam racji?
Bo mam wrażenie, że .library wcale nie ratuje sytuacji. Tylko nie skwituj tego stwerdzeniem: "a co użytkownika obchodzi ile musi mieć kopii tej samej biblioteki na dysku" :D
Ale nie występuje, z definicji, jeśli biblioteka kopii *nie ma* ;) Pytanie jest więc proste - czy te problemy mają znaczenie w praktyce?
Ile muszę uruchomić aplikacji, żeby stwierdzić, że problemy mają znaczący wpływ na działanie systemu w innych warunkach niż testowe?
Ja wiem, że mogę uruchomić 10 kopii Timberwolfa żeby taki efekt uzyskać. Tylko po co właściwe będę potrzebował uruchamiać 10 kopii Timberwolf (w celu innym niż potwierdzić niepełną implementację .so)?
Jedyna możliwość, to że 10 różnych programów będzie korzystać z tej samej biblioteki. Tak więc ponowię pytanie:
- Jakie 10 różnych aplikacji wykorzystuje takie biblioteki .so, że istnienie ich kopii powinno wymusić na Friedenach porzucenie jakichkolwiek innych prac i naprawienie tego właśnie problemu?
Wydaje mi się, że nie muszę tłumaczyć, że priorytetem naprawy błędów powinna być ich uciążliwość oraz częstotliwość występowania.:
- dla .so te wartości są w praktyce po prostu niskie
- dla podsystemu 3D z kolei wysokie.
Dlaczego więc, jak odnoszę wrażenie, z takim priorytetem sugerujesz naprawę .so (które w gruncie rzeczy działa), zamiast dokończenie portu Gallium (bo 3D w gruncie rzeczy działa niezbyt dobrze)? Może więc nie ma tu mowy o lenistwie Friedenów, tylko zwykłe (racjonalne) oszacowanie zagrożeń i ryzyka?
Problem nazewnictwa bibliotek:
Ale z tego co kojarzę z zamierzchłych czasów MA - to wcale nie jest skutecznym rozwiązaniem. Czyż nie ma setek programów, które wymagają obecności KONKRETNEJ wersji biblioteki? Użytkowników, którzy próbują różnych wersji bibliotek, aż do uzyskania pełnej stabilności? Moim zdaniem problem wciąż występuje - ale objawia się w inny sposób.
Co więcej - przy takim rozwiązaniu aplikacje powinny być dostarczane z tymi wersjami bibliotek, z którymi producent gwarantuje działanie:)
Czyli problem ze zgodnością w .so zamieniamy na... konieczność posiadania kilku kopii biblioteki oraz problem dystrybucji:)
Dodatkowo, jeśli będziesz mieć na dysku kilka niezgodnych kopii biblioteki oraz programy je wykorzystujące - to do pamięci zostanie wczytane kilka kopii funkcjonalnie zbieżnego kodu.
Mam rację, czy nie mam racji?
Bo mam wrażenie, że .library wcale nie ratuje sytuacji. Tylko nie skwituj tego stwerdzeniem: "a co użytkownika obchodzi ile musi mieć kopii tej samej biblioteki na dysku" :D
30.03.2011 18:49
[#17]
Re: zolty i jego brak wiedzy
@Radov, post #16
Ja wiem, że mogę uruchomić 10 kopii Timberwolfa żeby taki efekt uzyskać.
Ciekawe co zrobisz jak Firefox dorobi się uruchamiania każdej zakładki w osobnym procesie (projekt Electrolysis). Wtedy wystarczy uruchomić 10 zakładek...
Czyż nie ma setek programów, które wymagają obecności KONKRETNEJ wersji biblioteki?
Znasz jakieś przykłady? Ja znam jeden, YAM i klasy NList. Problem powstał, gdy za rozwój obu wzięli się dyletanci w rodzaju Jensa Langnera i wprowadzali nowe błędy w każdej wersji. Na to shared objects nic by nie pomogły...
Ciekawe co zrobisz jak Firefox dorobi się uruchamiania każdej zakładki w osobnym procesie (projekt Electrolysis). Wtedy wystarczy uruchomić 10 zakładek...
Czyż nie ma setek programów, które wymagają obecności KONKRETNEJ wersji biblioteki?
Znasz jakieś przykłady? Ja znam jeden, YAM i klasy NList. Problem powstał, gdy za rozwój obu wzięli się dyletanci w rodzaju Jensa Langnera i wprowadzali nowe błędy w każdej wersji. Na to shared objects nic by nie pomogły...
31.03.2011 02:56
[#18]
Re: zolty i jego brak wiedzy
@G. Kraszewski, post #4
Hmm a gdzie Ty widzisz jakieś argumenty w mojej wypowiedzi? Niepotrzebnie się unosisz, fakt mogłem napisać tylko "szkoda dyskutować bo Grzesiek i tak nie zmieni swoich poglądów". Czy nie miałem racji? Znowu te same argumenty z Twojej strony i z drugiej Radova i co? Zmieniłeś poglądy zgodziłeś się z czymś? Po co od lat klepać w kólko to samo jak to nic nie zmienia? Wiele argumentów Radova jest trafionych jak chodźby problem z wersjami library.
Myślisz że nie rozumiem Twoich argumentów z posta siódmego? Tylko ja uważam że lepszy wróbel w garści niż gołąb na dachu. Że więcej pamięci? Dołożę. Że wolniej trudno kiedyś zmienię sprzęt (akurat to że A1200 wytrzymała tak długo to porażka a nie sukces Amigi) Powiedz mi, kiedy ktoś przepisze FF na Mosa? Ile lat pochłonie przepisanie bibliotek a potem samego programu? Kto to zrobi? Oczywiście to jest tylko przykład bo równie dobrze może chodzić o OO. Jak dobrze Cię rozumiem to Ty mówisz "nie da się czegoś zrobić na Amidze (słowo Amiga użyte jako symbol w Twoim wypadku to MOS) włącz stojącego obok PCeta po co się męczyć" ja wolę nawet źle zaimplemetowane technologie ale jednak dające mi możliwość zrobienia tego na Amidze. Moja Amiga jest moim podstawowym kompem chodzącym nawet i kilka godzin dziennie a nie tylko hobby odgrzewanym w niedzielę po obiedzie.
Coraz bardziej odnoszę wrażenie że MosTeam pisze system dla samego pisania nie oglądając się na potrzeby użytkowników końcowych a przecież to oni są najważniejsi. Dobrze to widać na .so Hyperion stworzył tylko furtkę (powiedz mi czy DigiBoster będzie wykorzystywał .so? Znam odpowiedź więc od razu drugie pytanie. Da sie napisać program na OS4 bez .so?) którą fakt, może jakiś domorosły programista wykorzystać do napisania kiepsko działającej aplikacji bo jest łatwiej (łatwiej napisać czy raczej skompilować .so niż napisać library). Ale z drugiej strony co mamy? Chcesz przenieść OO na Mosa? Najpierw przepisz .so na library. Ale czy to uchroni użytkownika końcowego przed kiepsko napisanym programem? Sam podałeś przykład kiepsko rozwijanych klas MUI.
Grzesiek właśnie zdechła mi trójka z przodu (chodzi o wiek) i naprawdę ja się chcę cieszyć FF i OO na amidze "dzisiaj" a nie "jutro" bo mogę tego po prostu nie dożyć (ech to takie smutne rozważania nie na ten portal).
A propo czasu tak sobie myslę czy nie fajna byłaby taka ankieta np. pod kątem Twojego programu. Co wolisz? Wydanie programu "dziś" ale z kiepską optymalizacją (szczególnie pod kątem klasyka) czy jutro (np za pół roku) ale działającego szybciej o 20% na klasyku. Ciekawe co ludzie by wybrali? Bo mój wybór chyba już znasz?
To taki głos szarego użytkownika ale niestety mam coraz większe wrażenie że zapominacie iż to on jest właśnie najważniejszy w tej zabawie.
Myślisz że nie rozumiem Twoich argumentów z posta siódmego? Tylko ja uważam że lepszy wróbel w garści niż gołąb na dachu. Że więcej pamięci? Dołożę. Że wolniej trudno kiedyś zmienię sprzęt (akurat to że A1200 wytrzymała tak długo to porażka a nie sukces Amigi) Powiedz mi, kiedy ktoś przepisze FF na Mosa? Ile lat pochłonie przepisanie bibliotek a potem samego programu? Kto to zrobi? Oczywiście to jest tylko przykład bo równie dobrze może chodzić o OO. Jak dobrze Cię rozumiem to Ty mówisz "nie da się czegoś zrobić na Amidze (słowo Amiga użyte jako symbol w Twoim wypadku to MOS) włącz stojącego obok PCeta po co się męczyć" ja wolę nawet źle zaimplemetowane technologie ale jednak dające mi możliwość zrobienia tego na Amidze. Moja Amiga jest moim podstawowym kompem chodzącym nawet i kilka godzin dziennie a nie tylko hobby odgrzewanym w niedzielę po obiedzie.
Coraz bardziej odnoszę wrażenie że MosTeam pisze system dla samego pisania nie oglądając się na potrzeby użytkowników końcowych a przecież to oni są najważniejsi. Dobrze to widać na .so Hyperion stworzył tylko furtkę (powiedz mi czy DigiBoster będzie wykorzystywał .so? Znam odpowiedź więc od razu drugie pytanie. Da sie napisać program na OS4 bez .so?) którą fakt, może jakiś domorosły programista wykorzystać do napisania kiepsko działającej aplikacji bo jest łatwiej (łatwiej napisać czy raczej skompilować .so niż napisać library). Ale z drugiej strony co mamy? Chcesz przenieść OO na Mosa? Najpierw przepisz .so na library. Ale czy to uchroni użytkownika końcowego przed kiepsko napisanym programem? Sam podałeś przykład kiepsko rozwijanych klas MUI.
Grzesiek właśnie zdechła mi trójka z przodu (chodzi o wiek) i naprawdę ja się chcę cieszyć FF i OO na amidze "dzisiaj" a nie "jutro" bo mogę tego po prostu nie dożyć (ech to takie smutne rozważania nie na ten portal).
A propo czasu tak sobie myslę czy nie fajna byłaby taka ankieta np. pod kątem Twojego programu. Co wolisz? Wydanie programu "dziś" ale z kiepską optymalizacją (szczególnie pod kątem klasyka) czy jutro (np za pół roku) ale działającego szybciej o 20% na klasyku. Ciekawe co ludzie by wybrali? Bo mój wybór chyba już znasz?
To taki głos szarego użytkownika ale niestety mam coraz większe wrażenie że zapominacie iż to on jest właśnie najważniejszy w tej zabawie.
31.03.2011 10:23
[#19]
Re: zolty i jego brak wiedzy
@TomK, post #18
Zgadzam się z przedmówcą i kolegą Radov w 100%.
Lepiej jest mieć dzisiaj jakiś ważny program użytkowy który jest może napisany trochę koślawo, zżera więcej zasobów systemowych niż powinien niż nie mieć dobrze napisanego programu.
Mówię to jako użytkownik. Na programowaniu się nie znam.
A że użytkowników jest zazwyczaj znacznie więcej niż programistów to użytkownicy powinni być zadowoleni z danej platformy; nie programiści.
Jako dobry programista masz Krashan na pewno rację twierdząc że sposób w jaki zaimplementowano obsługę .so w AOS jest zły.
Ja się nie znam więc w tym temacie milczę.
Ale jeżeli użytkownicy systemu AOS4.X akceptują to rozwiązanie (po części dlatego że nie mają innego wyjścia) i są z tego OS-u zadowoleni to nie widzę problemu.
Lepiej jest mieć dzisiaj jakiś ważny program użytkowy który jest może napisany trochę koślawo, zżera więcej zasobów systemowych niż powinien niż nie mieć dobrze napisanego programu.
Mówię to jako użytkownik. Na programowaniu się nie znam.
A że użytkowników jest zazwyczaj znacznie więcej niż programistów to użytkownicy powinni być zadowoleni z danej platformy; nie programiści.
Jako dobry programista masz Krashan na pewno rację twierdząc że sposób w jaki zaimplementowano obsługę .so w AOS jest zły.
Ja się nie znam więc w tym temacie milczę.
Ale jeżeli użytkownicy systemu AOS4.X akceptują to rozwiązanie (po części dlatego że nie mają innego wyjścia) i są z tego OS-u zadowoleni to nie widzę problemu.
31.03.2011 11:29
[#21]
Re: zolty i jego brak wiedzy
@radzik, post #20
1.
Skąd masz taką pewność ?
2.
.. i bardzo dobrze.
3.
Jakoś tego nie widzę. Jedynie to są zawsze wycieczki osobiste i to każdej ze stron. Tylko teraz pytanie - która bardziej.
4.
...patrz - punkt pierwszy.
*********
Nie mogłem się powstrzymać
:(
Powód jest bardzo prosty MOSTeamowi żal du... ściska
Skąd masz taką pewność ?
2.
że nie został oficjalnym AmigaOS
.. i bardzo dobrze.
3.
i teraz się mszczą na każdym kroku
Jakoś tego nie widzę. Jedynie to są zawsze wycieczki osobiste i to każdej ze stron. Tylko teraz pytanie - która bardziej.
4.
Dziecinada okrutna.
...patrz - punkt pierwszy.
*********
Nie mogłem się powstrzymać
:(
31.03.2011 11:54
[#22]
Re: zolty i jego brak wiedzy
@(V)(I)mothe(P), post #21
@radzik
@(V)(I)mothe(P)
no to trolling na całego...
@TomK
Chyba nie jesteś tu nowy? ;) Użytkownik już za czasów C= był złem koniecznym. A teraz ta tradycja jest kontynuowana przez wszystkich "spadkobierców". W końcu MOS Team, Hyperion, AROSa, twórcy NatAmi* i inni nawet nie ukrywają że robią to wszystko tylko dla zabawy. Nie mają tu zastosowania normalne prawa rynku, gdzie walczy się o użytkownika. Bo tu użytkownik walczy żeby mu cokolwiek dostarczyć. Czasem nawet jak jakiś użytkownik jest złośliwy to dostawca się obraża i oświadcza, że nie będzie już dostarczać. Wówczas użytkownik (często zupełnie inna jednostka) jest w ciemnej, a przykładów tego na naszym rynku było już sporo.
Ja nawet nie ubolewam, nie narzekam, tylko stwierdzam fakty :P. Jak się nad tym głębiej zastanowić, to jest to fenomen, ktoś powinien napisać o tym książkę!
* - nie mam nic przeciwko którymkolwiek z w/w, proszę nie insynuować
@(V)(I)mothe(P)
no to trolling na całego...
@TomK
To taki głos szarego użytkownika ale niestety mam coraz większe wrażenie że zapominacie iż to on jest właśnie najważniejszy w tej zabawie.
Chyba nie jesteś tu nowy? ;) Użytkownik już za czasów C= był złem koniecznym. A teraz ta tradycja jest kontynuowana przez wszystkich "spadkobierców". W końcu MOS Team, Hyperion, AROSa, twórcy NatAmi* i inni nawet nie ukrywają że robią to wszystko tylko dla zabawy. Nie mają tu zastosowania normalne prawa rynku, gdzie walczy się o użytkownika. Bo tu użytkownik walczy żeby mu cokolwiek dostarczyć. Czasem nawet jak jakiś użytkownik jest złośliwy to dostawca się obraża i oświadcza, że nie będzie już dostarczać. Wówczas użytkownik (często zupełnie inna jednostka) jest w ciemnej, a przykładów tego na naszym rynku było już sporo.
Ja nawet nie ubolewam, nie narzekam, tylko stwierdzam fakty :P. Jak się nad tym głębiej zastanowić, to jest to fenomen, ktoś powinien napisać o tym książkę!
* - nie mam nic przeciwko którymkolwiek z w/w, proszę nie insynuować
31.03.2011 12:09
[#24]
Re: zolty i jego brak wiedzy
@G. Kraszewski, post #1
na PC "mecza sie" z ichniejszymi .DLL, w odniesieniu do bibliotek (takze tych przeniesionych z Unix'a), to na Amidze wypada uzywac .library
choc tez, dlaczego elf, a nie pe, albo, czemu nie lepiej amigowy hunk ?:). w przypadku plikow wykonywalnych, to moze nie jest tak zauwazalne - bo w nazwie tego nie widac, ale amigowe formaty powinny byc.
z punktu widzenia uzytkownikow nie ma to znaczenia, choc ja osobiscie wole nazwe .library niz .so , wiec moze chociaz przemianowac .so na .library, zeby byly jakies pozory dla zwyklego uzytkownika, bo .so to jednak razi po oczach :)
w przypadku pozostalych plikow, lecz przynaleznych systemowi, to binarne iff (grafika, audio, itd.) i tekstowe txt asci/utf, guide ascii/utf (ktory chyba powinien byc zastepowany xml, moze lepiej tak ujac, dodany powinien byc xml...)
i obsluga pozostalych podstawowych multisystemowych formatow multimedialnych oraz innych: jpg,jpeg2000,png,gif,tiff,tga,openexr,aiff pcm,wav pcm,ogg,ogm,mp4,avi,xm,mod,html.... wiadomo, niektore z tych formatow to tylko kontenery. osobscie nie widze problemow zeby tymi formatami multisystemowymi zajmowaly sie specjalistyczne programy poza systemem, choc systemowa infrastruktura wszelkich datatypow powinna byc dostepna i bywa uzyteczna...
parfrazujac pewne powiedzenie, amigowy system powinien byc tak prosta jak to mozliwe i ani troche prosciej, to powinien byc wyroznik, lepiej nie obrastac tak jak windows, bo potem jeszcze kilka kalkulatorow zabierze caly RAM i power
tak w skrocie ja to widze :)
Ostatnia modyfikacja: 31.03.2011 12:34:33
choc tez, dlaczego elf, a nie pe, albo, czemu nie lepiej amigowy hunk ?:). w przypadku plikow wykonywalnych, to moze nie jest tak zauwazalne - bo w nazwie tego nie widac, ale amigowe formaty powinny byc.
z punktu widzenia uzytkownikow nie ma to znaczenia, choc ja osobiscie wole nazwe .library niz .so , wiec moze chociaz przemianowac .so na .library, zeby byly jakies pozory dla zwyklego uzytkownika, bo .so to jednak razi po oczach :)
w przypadku pozostalych plikow, lecz przynaleznych systemowi, to binarne iff (grafika, audio, itd.) i tekstowe txt asci/utf, guide ascii/utf (ktory chyba powinien byc zastepowany xml, moze lepiej tak ujac, dodany powinien byc xml...)
i obsluga pozostalych podstawowych multisystemowych formatow multimedialnych oraz innych: jpg,jpeg2000,png,gif,tiff,tga,openexr,aiff pcm,wav pcm,ogg,ogm,mp4,avi,xm,mod,html.... wiadomo, niektore z tych formatow to tylko kontenery. osobscie nie widze problemow zeby tymi formatami multisystemowymi zajmowaly sie specjalistyczne programy poza systemem, choc systemowa infrastruktura wszelkich datatypow powinna byc dostepna i bywa uzyteczna...
parfrazujac pewne powiedzenie, amigowy system powinien byc tak prosta jak to mozliwe i ani troche prosciej, to powinien byc wyroznik, lepiej nie obrastac tak jak windows, bo potem jeszcze kilka kalkulatorow zabierze caly RAM i power
tak w skrocie ja to widze :)
Ostatnia modyfikacja: 31.03.2011 12:34:33
31.03.2011 12:33
[#25]
Re: zolty i jego brak wiedzy
@1989, post #24
Myślę, że nikt nie ma wątpliwości, że lepiej być "bogatym i zdrowym, niż biednym i chorym"
Na bogactwo jednak żaden z naszych systemów raczej nie cierpi - dlatego też zasobami należy racjonalnie dysponować.
Z tego co mi wiadomo, to i ".library" i ".so" w architekturze AmigaOSu cierpią na tę samą przypadłość - export symboli i kodu wymaga obejść, a o imporcie tych elementów to już w ogóle lepiej nie mówić. Niestety nie znam szczegółów, powtarzam tylko przeczytaną opinię. Jeśli jednak tak jest naprawdę - to i ten element architektury powinien być ostatecznie przerobiony. A to kosztuje. A koszt dwukrotnej naprawy - najpierw to co omawiamy w tym wątku, a potem jeszcze raz w celu dostosowania do nowego sposobu obsługi - kosztuje jeszcze więcej.
Więc podstawowe pytanie to wciąż:
"Czy bolączki amigowej implementacji .so są AŻ TAK POWAŻNE, że trzeba je naprawić już teraz?"
Moim zdaniem nie:) Niestety mam listę innych rzeczy, które wolałbym zobaczyć poprawione przed tym elementem.
Na bogactwo jednak żaden z naszych systemów raczej nie cierpi - dlatego też zasobami należy racjonalnie dysponować.
Z tego co mi wiadomo, to i ".library" i ".so" w architekturze AmigaOSu cierpią na tę samą przypadłość - export symboli i kodu wymaga obejść, a o imporcie tych elementów to już w ogóle lepiej nie mówić. Niestety nie znam szczegółów, powtarzam tylko przeczytaną opinię. Jeśli jednak tak jest naprawdę - to i ten element architektury powinien być ostatecznie przerobiony. A to kosztuje. A koszt dwukrotnej naprawy - najpierw to co omawiamy w tym wątku, a potem jeszcze raz w celu dostosowania do nowego sposobu obsługi - kosztuje jeszcze więcej.
Więc podstawowe pytanie to wciąż:
"Czy bolączki amigowej implementacji .so są AŻ TAK POWAŻNE, że trzeba je naprawić już teraz?"
Moim zdaniem nie:) Niestety mam listę innych rzeczy, które wolałbym zobaczyć poprawione przed tym elementem.
31.03.2011 13:04
[#27]
Re: zolty i jego brak wiedzy
@1989, post #26
@ Chylę czoła przed ludźmi wypowiadającymi się w tym wątku. Macie tak ogromną wiedzę, że "szczena opada", ale mimo tego nie zauważyliście, że do przetrwania LEGENDY AMIGI (cokolwiek przez to rozumiecie) potrzeba współpracy. Za max 20 lat ilu z Was będzie jeszcze coś dłubało przy "legendzie"? Ponieważ wszelkie znaczki budzą z natury jakieś skojarzenia lepsi, gorsi, bagatsi, biedniejsi itd., które prowokują do swarów dajcie spokój z wytykaniem sobie, co kto robi źle. Nie możecie, nie chcecie się dogadać, nie opłaca się to WAM, mnie (zwykłego usera) to nie interesuje. Wszystkie te rozwiązania zginą za kilkanaście/kilkadziesiąt lat właśnie z powodu kłótni. Ilu z nas intersuje co gadają politycy, którzy non stop się kłócą? No to usiądźcie (potajemnie) gdzieś przy piwie i pomyślcie nad tym w jaki sposób współpracując razem, moglibyście najlepiej wyciągnąć od nas kasę za swoją pracę. Skończcie bajki o profesjonalnym sprzęcie a zainteresujcie się "Kowalkimi", którzy szukaja sprzętu do DOMU. Postawcie na wspomnienia, rozrywkę, bezstresową pracę z systemem, proste niezbędne użytki. KOCHAM WAS, CHOĆ I TAK SIĘ MYLICIE, OSOBNO WCALE NIE ZAJEDZIECIE DALEJ. NOWY SYSTEM, NOWA JAKOŚĆ, NOWA NAZWA, BEZ ZNACZKÓW. 
Ostatnia modyfikacja: 31.03.2011 13:07:55
Ostatnia modyfikacja: 31.03.2011 13:07:55
31.03.2011 20:49
[#28]
Re: zolty i jego brak wiedzy
@Ender, post #27
No to usiądźcie (potajemnie) gdzieś przy piwie i pomyślcie nad tym w jaki sposób współpracując razem, moglibyście najlepiej wyciągnąć od nas kasę za swoją pracę.
Nie da się od amigowców wyciągnąć kasy, która by równoważyła realną wartość wkładanej w oprogramowanie pracy. Kiepsko opłacany programista zarabia w Polsce 36 tysięcy złotych rocznie na rękę. Spróbuj wyciągnąć taką kasę, a ZUS i podatek też trzeba zapłacić.
Nie da się od amigowców wyciągnąć kasy, która by równoważyła realną wartość wkładanej w oprogramowanie pracy. Kiepsko opłacany programista zarabia w Polsce 36 tysięcy złotych rocznie na rękę. Spróbuj wyciągnąć taką kasę, a ZUS i podatek też trzeba zapłacić.
31.03.2011 22:29
[#29]
Re: zolty i jego brak wiedzy
@G. Kraszewski, post #28
Nie da się od amigowców wyciągnąć kasy, która by równoważyła realną wartość wkładanej w oprogramowanie pracy.
Trzeba spróbować. Programiści z naszego środowiska odwalają kawałek świetnej pracy kosztem swojego wolnego czasu i nie widzę powodu, żeby nie płacić za oprogramowanie cen podobnych do tych z rynku PC. "Za darmo umarło" jak to mówią. Ja kupuję oryginalne oprogramowanie, a jeśli mi odpowiada to wybieram również OpenSource.
Kiepsko opłacany programista zarabia w Polsce 36 tysięcy złotych rocznie na rękę. Spróbuj wyciągnąć taką kasę, a ZUS i podatek też trzeba zapłacić.
Ja nie mam takich możliwości, takiej wiedzy. Poza tym czym się różni amigowy/mosowy/arosowy programista od PeCetowego? Często mają umiejętności i wiedzę większą niż inni. Niech zarobią na swoim hobby, inaczej ciągle będziemy narzekać na brak oprogramowania. Dlatego uwtażam, że stworzenie czegoś na styl Appstore w naszym światku (była o tym mowa na forum) mogłoby być jakimś rozwiązaniem, a gdyby jeszcze nie tracic czasu na kilka wersji dla różnych systemów, które często posiadamy, bo byłby jeden system oszalałbym wprost z radości ;) .
Ostatnia modyfikacja: 31.03.2011 22:34:44
Trzeba spróbować. Programiści z naszego środowiska odwalają kawałek świetnej pracy kosztem swojego wolnego czasu i nie widzę powodu, żeby nie płacić za oprogramowanie cen podobnych do tych z rynku PC. "Za darmo umarło" jak to mówią. Ja kupuję oryginalne oprogramowanie, a jeśli mi odpowiada to wybieram również OpenSource.
Kiepsko opłacany programista zarabia w Polsce 36 tysięcy złotych rocznie na rękę. Spróbuj wyciągnąć taką kasę, a ZUS i podatek też trzeba zapłacić.
Ja nie mam takich możliwości, takiej wiedzy. Poza tym czym się różni amigowy/mosowy/arosowy programista od PeCetowego? Często mają umiejętności i wiedzę większą niż inni. Niech zarobią na swoim hobby, inaczej ciągle będziemy narzekać na brak oprogramowania. Dlatego uwtażam, że stworzenie czegoś na styl Appstore w naszym światku (była o tym mowa na forum) mogłoby być jakimś rozwiązaniem, a gdyby jeszcze nie tracic czasu na kilka wersji dla różnych systemów, które często posiadamy, bo byłby jeden system oszalałbym wprost z radości ;) .
Ostatnia modyfikacja: 31.03.2011 22:34:44
31.03.2011 23:32
[#30]
Re: zolty i jego brak wiedzy
@Ender, post #29
Ender,
Systemy MOS, AOS4.X i AROS idą w zupełnie innych kierunkach. Czy to źle czy dobrze to oceni historia. Ja tylko stwierdzam fakt.
Do czasu przejęcia marki "Amiga" (cokolwiek by to miało znaczyć) przez firmę dysponującą kwotą ok. 500m$ na promocję marki "Amiga" nic się w tej sytuacji nie zmieni. Ale to NIC.
Programistów piszących pod MOS, AOS4.X i AROS jest mało i piszą najczęściej pod swoją ulubioną platformę. Są nieliczne wyjątki rzecz jasna.
A inni programiści czy tez firmy wydające jakiś soft na inne wiodące systemy nie będą tracić czasu i pieniędzy na niszowe systemy. Bo i po co? Dla idei? W kapitaliźmie panuje tylko idea pieniądza i zysku.
Systemy MOS, AOS4.X i AROS idą w zupełnie innych kierunkach. Czy to źle czy dobrze to oceni historia. Ja tylko stwierdzam fakt.
Do czasu przejęcia marki "Amiga" (cokolwiek by to miało znaczyć) przez firmę dysponującą kwotą ok. 500m$ na promocję marki "Amiga" nic się w tej sytuacji nie zmieni. Ale to NIC.
Programistów piszących pod MOS, AOS4.X i AROS jest mało i piszą najczęściej pod swoją ulubioną platformę. Są nieliczne wyjątki rzecz jasna.
A inni programiści czy tez firmy wydające jakiś soft na inne wiodące systemy nie będą tracić czasu i pieniędzy na niszowe systemy. Bo i po co? Dla idei? W kapitaliźmie panuje tylko idea pieniądza i zysku.