16.07.2019 00:53
[#181]
Re: MorphOS na ARM - czemu nie?
@Slepaq, post #179
Raspbian ściągnięty podczas premiery, wgrany firmware zmniejszający podobno temperaturę kontrolera usb oraz zrobiony update przez rpi-update.
Prędkość przed rpi-update można było ustawić maks 1750 a po już na 2000
Średnio widzę sens używania tego komputera jako desktop bez OC. Znaczy i tak jest wydajny ale tak to zawsze jest jeszcze wydajniejszy
Prędkość przed rpi-update można było ustawić maks 1750 a po już na 2000
Średnio widzę sens używania tego komputera jako desktop bez OC. Znaczy i tak jest wydajny ale tak to zawsze jest jeszcze wydajniejszy
16.07.2019 06:41
[#182]
Re: MorphOS na ARM - czemu nie?
@XoR, post #181
XoR - dziękuję za odpowiedzi, patrząc na cenę tego maleństwa i Twoją wypowiedź, jestem w ciężkim szoku.
. Co raz bardziej się zastanawiam, czy nie kupić Malinki do celów desktopowo - przeglądarkowych. Wygląda to bardziej niż zachęcająco. Niziutkie zużycie energii, maleństwo, które wraz z obudową można schować za monitorem, podpiąć do huba przy wyświetlaczu i spokojnie korzystać do w/w celów...
To pokazuje jeszcze jedno - jak bardzo w MOS / AOS 4.1 / Arosie brakuje nowoczesnej przeglądarki. Wiem, że jest Odyssey ale trudno ją nazwać "nowoczesną".
. Co raz bardziej się zastanawiam, czy nie kupić Malinki do celów desktopowo - przeglądarkowych. Wygląda to bardziej niż zachęcająco. Niziutkie zużycie energii, maleństwo, które wraz z obudową można schować za monitorem, podpiąć do huba przy wyświetlaczu i spokojnie korzystać do w/w celów... To pokazuje jeszcze jedno - jak bardzo w MOS / AOS 4.1 / Arosie brakuje nowoczesnej przeglądarki. Wiem, że jest Odyssey ale trudno ją nazwać "nowoczesną".
16.07.2019 08:25
[#183]
Re: MorphOS na ARM - czemu nie?
@Slepaq, post #182
Jako główny PC to nie ale jako always-on dodatkowy komputerek na którym można jeszcze zrobić jakieś serwery i inne cuda jak blokowanie reklam to jak najbardziej. Szczególnie niezłe do nauki Linuxa, zdecydowanie bardziej angażuje niż instalacja Linuxa na głównym PC
Z przeglądarką na pewno po przejściu na architekturę ARM tudzież tfu tfu X86 powinno być lepiej dzięki JIT... chociaż oczywiście raz że ktoś musiałby i tak wykonać pracę portując źródła z innej wersji np. Linuxowej a dwa że jeśli by użyć Big Endian aby było 'po staremu' to wydaje mi się że JIT już nie zadziała. Z Litte Endian natomiast potrzebne byłoby inne podejście do emulacji starszych programów.
W każdym bądź razie... ściągam AROSa dla ARM w wersji na linuxa. Przetestuję jak to działa bo aż jestem ciekawy. Przeglądarka w AROSie uruchomionym na VM miała niemal identyczną wydajność jak Chrome uruchomiony natywnie i w sumie działała dość dobrze
Z przeglądarką na pewno po przejściu na architekturę ARM tudzież tfu tfu X86 powinno być lepiej dzięki JIT... chociaż oczywiście raz że ktoś musiałby i tak wykonać pracę portując źródła z innej wersji np. Linuxowej a dwa że jeśli by użyć Big Endian aby było 'po staremu' to wydaje mi się że JIT już nie zadziała. Z Litte Endian natomiast potrzebne byłoby inne podejście do emulacji starszych programów.
W każdym bądź razie... ściągam AROSa dla ARM w wersji na linuxa. Przetestuję jak to działa bo aż jestem ciekawy. Przeglądarka w AROSie uruchomionym na VM miała niemal identyczną wydajność jak Chrome uruchomiony natywnie i w sumie działała dość dobrze
16.07.2019 08:54
[#184]
Re: MorphOS na ARM - czemu nie?
@XoR, post #183
Wracając do MOS'a - patrząc na Twój opis użytkowania i po obejrzeniu kilku prezentacji pracy na YT mam wrażenie, że jako tanie, względnie nowoczesne rozwiązanie sprzętowe, dla tak lekkiego systemu, RPi 4 mogłoby być naprawdę ciekawe. Trudno mi sobie obecnie wyobrazić MOSa w jakichś poważniejszych zastosowaniach ale... jeżeli dodać do siebie:
RPi + kreatywność ludzi, którzy z tej platformy korzystają + GCC efekty mogą być zaskakujące.
Orientujesz się może, czy były wysyłane do MorphOS Teamu jakieś oficjalne zapytania w sprawie przejścia na ARM? Coś mi się "po głowie kołacze", że 2 lub 3 lata temu padały takie pytania i odpowiedź była wówczas negatywna. Obecnie jednak ta architektura wydaje się być naprawdę obiecująca...
Ostatnia aktualizacja: 16.07.2019 08:55:16 przez Slepaq
Ostatnia aktualizacja: 16.07.2019 08:55:34 przez Slepaq
RPi + kreatywność ludzi, którzy z tej platformy korzystają + GCC efekty mogą być zaskakujące.
Orientujesz się może, czy były wysyłane do MorphOS Teamu jakieś oficjalne zapytania w sprawie przejścia na ARM? Coś mi się "po głowie kołacze", że 2 lub 3 lata temu padały takie pytania i odpowiedź była wówczas negatywna. Obecnie jednak ta architektura wydaje się być naprawdę obiecująca...
Ostatnia aktualizacja: 16.07.2019 08:55:16 przez Slepaq
Ostatnia aktualizacja: 16.07.2019 08:55:34 przez Slepaq
16.07.2019 10:46
[#186]
Re: MorphOS na ARM - czemu nie?
@Slepaq, post #184
Orientujesz się może, czy były wysyłane do MorphOS Teamu jakieś oficjalne zapytania w sprawie przejścia na ARM? Coś mi się "po głowie kołacze", że 2 lub 3 lata temu padały takie pytania i odpowiedź była wówczas negatywna. Obecnie jednak ta architektura wydaje się być naprawdę obiecująca...
Przeczytaj post #153. Nie jest to może oficjalne stanowisko MorphOS-Teamu ale daje jakiś pogląd.
Przeczytaj post #153. Nie jest to może oficjalne stanowisko MorphOS-Teamu ale daje jakiś pogląd.
16.07.2019 12:08
[#187]
Re: MorphOS na ARM - czemu nie?
@Slepaq, post #184
Zadaj sobie pytanie, co taki płatny, rozwijany przez garstkę osób, ciągle próbujacy dogonić technicznie teraźniejszość MorphOS oferuje, a czego nie oferują darmowe, rozwijane przez tysiące i technologicznie aktualne dystrubucje linuksa dla typowego elektronicznego majsterkowcza. System, który sięga korzeniami do czasów kultowej Amigi, to raczej słaby magnes na potencjalnych klientów. W obliczu przytłaczającej darmowej konkurencji, praca związana z upowszechnieniem MorphOSa w taki kontekście jakim przedstawiono, wykracza dużo, dużo dalej poza ramy zwykłego przeportowania systemu i wymaga dużo więcej nakładu pracy, w stworzeniu środowiska czyniącego ten system konkurencyjnie użytecznym, aby chociaż zgarnąć okruszki z tortu linuksa.
Ostatnia aktualizacja: 16.07.2019 12:11:39 przez sanjyuubi
Ostatnia aktualizacja: 16.07.2019 12:11:39 przez sanjyuubi
16.07.2019 12:14
[#188]
Re: MorphOS na ARM - czemu nie?
@waldiamiga, post #186
Nawiązując do wypowiedzi z #153: jak się nie da, jak się da?
A tak poważniejąc - czy nie przypomina Wam to trochę pozytywnie zakręconych "amigowców", którzy od lat tworzą cuda z urządzeniami teoretycznie do tego nie przeznaczonymi :)?
Dlatego jeszcze raz podkreślę, społeczność RPi naprawdę jest bliska - z braku lepszego określenia - "duchowo" społeczności amigowej.
Co do złącza M2 to sądzę, że na razie, na potrzeby MOSa / AOS 4.1 w zupełności wystarczą dyski SSD SATA po USB 3.0 No, chyba, że mamy w planach zintensyfikowany "atak" na niszę obróbki obrazu :D W rzeczywistości - przy codziennym użytkowaniu różnice SSD SATA vs. M2 w 8/10 przypadków są niedostrzegalne.
Co do złącz PCI-E to tu jestem w stanie zrozumieć: faktycznie dobrze oprogramowane zewnętrzne karty graficzne mogą być przydatne, tym bardziej, że Broadcom, który jest producentem grafiki w RPi, jedynie częściowo udostępnił dokumentację, choć z drugiej strony do wcześniejszej wersji VideoCore IV została udostępniona w pełni na 3 rewersji licencji BSD, więc zakładam, że byłoby na czym się oprzeć :) )
Tak, wiem, to nadal nie jest desktop.... Heh i pomyśleć, że A500, A500+, A600 czy A1200 też trudno było nazwać desktopami :D
A tak poważniejąc - czy nie przypomina Wam to trochę pozytywnie zakręconych "amigowców", którzy od lat tworzą cuda z urządzeniami teoretycznie do tego nie przeznaczonymi :)?
Dlatego jeszcze raz podkreślę, społeczność RPi naprawdę jest bliska - z braku lepszego określenia - "duchowo" społeczności amigowej.
Co do złącza M2 to sądzę, że na razie, na potrzeby MOSa / AOS 4.1 w zupełności wystarczą dyski SSD SATA po USB 3.0 No, chyba, że mamy w planach zintensyfikowany "atak" na niszę obróbki obrazu :D W rzeczywistości - przy codziennym użytkowaniu różnice SSD SATA vs. M2 w 8/10 przypadków są niedostrzegalne.
Co do złącz PCI-E to tu jestem w stanie zrozumieć: faktycznie dobrze oprogramowane zewnętrzne karty graficzne mogą być przydatne, tym bardziej, że Broadcom, który jest producentem grafiki w RPi, jedynie częściowo udostępnił dokumentację, choć z drugiej strony do wcześniejszej wersji VideoCore IV została udostępniona w pełni na 3 rewersji licencji BSD, więc zakładam, że byłoby na czym się oprzeć :) )
Tak, wiem, to nadal nie jest desktop.... Heh i pomyśleć, że A500, A500+, A600 czy A1200 też trudno było nazwać desktopami :D
16.07.2019 12:36
[#189]
Re: MorphOS na ARM - czemu nie?
@sanjyuubi, post #187
W obliczu przytłaczającej darmowej konkurencji, praca związana z upowszechnieniem MorphOSa w taki kontekście jakim przedstawiono, wykracza dużo, dużo dalej poza ramy zwykłego przeportowania systemu i wymaga dużo więcej nakładu pracy...
Zgoda - ale sam port otwiera możliwość dalszej pracy i popularyzacji.
Po pierwsze: wersję demo może ściągnąć każdy - skoro mam płytkę to co mi szkodzi spróbować?
Po drugie: ci ludzie naprawdę nie boją się wyzwań - tak jak napisałem, ja nie spodziewam się, że wszyscy porzucą linuxa, bo to niemożliwe i nierealne, jednak nawet 1/10 000 tego środowiska zainteresowana projektem MOS to już bardzo cenny nabytek, bo to są ludzie, którzy rzadko oglądają się na innych, a często sami zakasują rękawy
Po trzecie: pojawia się istotna różnica w progu wejścia - koszt płytki z obudową i zasilaczem zamyka się w kwocie 550 zł, można ją praktycznie przechowywać w szufladzie, czy nawet podpiętą z tyłu monitora - to raczej zasadnicza różnica w stosunku do tego co w tym zakresie oferuje nawet Mac Mini?
Po czwarte: przykłady zastosowań podał kolega XoR - czy w przypadku działającego portu przeglądarki jakieś z tych zastosowań przekracza możliwości MOS'a? Co więcej - spora grupa projektów dostępnych na RPi posiada udostępnione ogólnie źródła, które... wymagają kompilatora GCC oraz edytora tekstów - czy te narzędzia są po za zasięgiem użytkownika?
Ja wiem - najlepiej gdyby MOS można było uruchomić na IBM Power9... niestety PPC w wersji "konsumenckiej" się skończył i nic nie wskazuje na to aby coś w tej kwestii się zmieniło.
Obecnie możliwości są 2: ARM lub x86. O ile w przypadku ARM jakaś tam szansa zainteresowania grupy użytkowników istnieje (bo to nadal architektura raczej dla pasjonatów), to w przypadku x86 uważam, że system zginie w tłumie.
Oczywiście - można to tak zostawić jak jest i po prostu wesoło bawić się w retro, bez oglądania na całą resztę... ale wówczas obawiam się, że środowisko zacznie się po prostu zmniejszać, a aktywność zamierać ale to tylko moje zdanie.
Zgoda - ale sam port otwiera możliwość dalszej pracy i popularyzacji.
Po pierwsze: wersję demo może ściągnąć każdy - skoro mam płytkę to co mi szkodzi spróbować?
Po drugie: ci ludzie naprawdę nie boją się wyzwań - tak jak napisałem, ja nie spodziewam się, że wszyscy porzucą linuxa, bo to niemożliwe i nierealne, jednak nawet 1/10 000 tego środowiska zainteresowana projektem MOS to już bardzo cenny nabytek, bo to są ludzie, którzy rzadko oglądają się na innych, a często sami zakasują rękawy
Po trzecie: pojawia się istotna różnica w progu wejścia - koszt płytki z obudową i zasilaczem zamyka się w kwocie 550 zł, można ją praktycznie przechowywać w szufladzie, czy nawet podpiętą z tyłu monitora - to raczej zasadnicza różnica w stosunku do tego co w tym zakresie oferuje nawet Mac Mini?
Po czwarte: przykłady zastosowań podał kolega XoR - czy w przypadku działającego portu przeglądarki jakieś z tych zastosowań przekracza możliwości MOS'a? Co więcej - spora grupa projektów dostępnych na RPi posiada udostępnione ogólnie źródła, które... wymagają kompilatora GCC oraz edytora tekstów - czy te narzędzia są po za zasięgiem użytkownika?
Ja wiem - najlepiej gdyby MOS można było uruchomić na IBM Power9... niestety PPC w wersji "konsumenckiej" się skończył i nic nie wskazuje na to aby coś w tej kwestii się zmieniło.
Obecnie możliwości są 2: ARM lub x86. O ile w przypadku ARM jakaś tam szansa zainteresowania grupy użytkowników istnieje (bo to nadal architektura raczej dla pasjonatów), to w przypadku x86 uważam, że system zginie w tłumie.
Oczywiście - można to tak zostawić jak jest i po prostu wesoło bawić się w retro, bez oglądania na całą resztę... ale wówczas obawiam się, że środowisko zacznie się po prostu zmniejszać, a aktywność zamierać ale to tylko moje zdanie.
16.07.2019 12:49
[#191]
Re: MorphOS na ARM - czemu nie?
@Slepaq, post #189
pojawia się istotna różnica w progu wejścia - koszt płytki z obudową i zasilaczem zamyka się w kwocie 550 zł, można ją praktycznie przechowywać w szufladzie, czy nawet podpiętą z tyłu monitora - to raczej zasadnicza różnica w stosunku do tego co w tym zakresie oferuje nawet Mac Mini?
Mac Mini z zasilaczem i obudową za 550 zł? Zero problemów. Możesz kupić od ręki - i to mocniejszą wersję - 1,5 GHz, 64 MB VRAM. W szufladę się zmieści, z tyłu monitora przytroczysz (chyba że masz wyjątkowo mały monitor).
16.07.2019 13:31
[#194]
Re: MorphOS na ARM - czemu nie?
@Slepaq, post #189
Kolega XoR wypowiedział się w kontekście używania samego Raspberry PI jako takiego względem PC (jak ma konfigurację, która powoduje, że transformator w pobliskiej rozdzielni podskakuje przy włączaniu, to się nie dziwię 
), nie ma tu jakiegoś argumentu przechylającego szalę na stronę MorphOSa.
Wygląda mi na to, że MOST(eam) nie jest po prostu zainteresowany prowizorycznym komputerem z pamięcią EMMC/flash jako dysk i bez PCI-E na pokładzie, nie wzbudza wystarczających emocji.
Trochę to opisałeś, jakby MOS na RPI miał być systemem dla prawdziwych zapaleńców albo masochistów. Kierujesz swoje słowa do garstki developerów nastawionych sceptycznie na twoją koncepcję, tu musiałbyś udowodnić prawie namacalnie, że poświęcenie czasu na port przyniesie wymierne korzyści, Prędzej zapewne by przeportowała społeczność, gdyby były źrodła, ale jest przecież AROS... jako nakładka na OS i chyba nie wkrada się specjalnie w łaski użytkowników.
Rozumiem cię i twoje zapalenie, ale rozumiem też ludzi z MOST(eam). Gdyby byli zainteresowani portowaniem, to pewnie już dawno byłaby wersja na x86/x64.
), nie ma tu jakiegoś argumentu przechylającego szalę na stronę MorphOSa.Wygląda mi na to, że MOST(eam) nie jest po prostu zainteresowany prowizorycznym komputerem z pamięcią EMMC/flash jako dysk i bez PCI-E na pokładzie, nie wzbudza wystarczających emocji.
Trochę to opisałeś, jakby MOS na RPI miał być systemem dla prawdziwych zapaleńców albo masochistów. Kierujesz swoje słowa do garstki developerów nastawionych sceptycznie na twoją koncepcję, tu musiałbyś udowodnić prawie namacalnie, że poświęcenie czasu na port przyniesie wymierne korzyści, Prędzej zapewne by przeportowała społeczność, gdyby były źrodła, ale jest przecież AROS... jako nakładka na OS i chyba nie wkrada się specjalnie w łaski użytkowników.
Rozumiem cię i twoje zapalenie, ale rozumiem też ludzi z MOST(eam). Gdyby byli zainteresowani portowaniem, to pewnie już dawno byłaby wersja na x86/x64.
16.07.2019 14:51
[#195]
Re: MorphOS na ARM - czemu nie?
@sanjyuubi, post #194
No dobra, ale co mamy na amisi ng? caymany i inne cuda (gpu dx11) gdzie procesor i tak jest z czasów radeona 9550, a funkcjonalności owych kart i tak za dużej nie ma, a nawet jeśli jest jako taka to trzeba sobie za nią dopłacić. Co zmieniłaby w tym momencie jakakolwiek platforma z pcie? No nic. Absolutnie nic. A do tego quake 3 to video core vi wystarczy w zupełności.
16.07.2019 15:00
[#196]
Re: MorphOS na ARM - czemu nie?
@abcdef, post #195
funkcjonalności owych kart i tak za dużej nie ma, a nawet jeśli jest jako taka to trzeba sobie za nią dopłacić
Chyba pomyliłeś MorphOSa z OS4. W przypadku MorphOSa nikt nie kasuje Cię za dodatkowe sterowniki do kart graficznych.
Co do Q3 - to jaki wynik daje benchmark owej gry w 1920x1200 na Raspberry? Bo znalazłem gdzieś w internetach że ktoś osiągnął 71 FPS na "trójce" w dość marnej rozdzielczości 1280x1024.
Ostatnia aktualizacja: 16.07.2019 15:02:21 przez recedent
16.07.2019 15:31
[#198]
Re: MorphOS na ARM - czemu nie?
@abcdef, post #197
W przypadku MorphOSa nie mamy póki co ciśnienia, żeby obsługiwać jak najnowsze karty graficzne, bo raczej mało kto kupuje dla tego systemu sprzęt "nowy, z półki, z gwarancją". To raczej ewolucja (czytaj: pełniejsza obsługa kolejnych modeli wraz z kolejnymi wersjami). Taki model obrał sobie Bigfoot - jego prawo. Może jeśli/kiedy system będzie obsługiwał więcej komputerów ze slotami PCIe (a nie tylko X5000) coś się w tej materii zmieni, kto wie? Póki co ciekaw jestem porównania wydajności starego X1950 pod MorphOSem z jakimś R9 w OS4. Rok temu Spectre pisał na MorphZone, że X5000 wyciąga 99.5 FPS w rozdzielczości 640x400 na karcie R9-270X. X1950 Pro na AGP (MorphOS) robi 150 w 1600x1200.
Ostatnia aktualizacja: 16.07.2019 15:37:54 przez recedent
Ostatnia aktualizacja: 16.07.2019 15:37:54 przez recedent
16.07.2019 16:09
[#199]
Re: MorphOS na ARM - czemu nie?
@sanjyuubi, post #194
...AROS... jako nakładka na OS i chyba nie wkrada się specjalnie w łaski użytkowników.
nie wiem, czy wkrada się czy nie, czytając jednak co się dzieje ostatnio na wszystkich 4 systemach (uwzględniając klasyka jako osobny podsystem) to klasyk i Aros dostarczają największych "rewelacji": Vampire SA i port Arosa na architekturę 64-bitową to w moim odczuciu największe sprawy w tym roku, ciekawy jestem co szykują chłopaki z MOS Team, bo coś cicho - albo nad czymś dłubią i pod koniec roku czeka nas niespodzianka albo... projekt przechodzi okres wakacyjnej hibernacji :)
Na marginesie - w moim odczuciu obydwa projekty rozwijane niejako bez statusu "oficjalnego" (celowy cudzysłów): AROS i MOS mają się obecnie lepiej niż konkurent. Ogólnie odnoszę wrażenie, że z systemów NG obecnie najszybciej rozwija się AROS, choć mam też świadomość, że jego rozwój w znacznej mierze ma charakter "systemu - gościa" na hoście zewnętrznym, choć czy w czasach mody na wszelkiej maści wirtualizacje to znów taki "grzech"?
--------------------------------
Co do sprzętu - gdybym był na miejscu koderów dowolnego systemu operacyjnego to starałbym się znaleźć platformę z jak najlepszą dokumentacją ogólnodostępną, przy zachowaniu minimum wersji konfiguracji sprzętowych. Pod tym kątem sprzęt Apple znakomicie wpisuje się w 2 z warunków, choć pierwszy zdecydowanie nie wygląda tutaj za dobrze.
Dla odmiany RPi spełnia obydwa: jest dokumentacja, jest ograniczona liczba wariantów. Brak PCI-E czy M.2 dla takiego systemu jak MOS jest raczej mało adekwatne do realnych wymagań oprogramowania (chyba, że chodzi o sterowniki grafiki, możliwe, że team boi się o problemy z opracowaniem względnie wydajnych sterowników, podczas gdy dla starych kart AMD takie sterowniki jednak są już gotowe).
Cóż - jak widać każda opcja ma swoje wady i swoje zalety. MorphOS obecnie jeszcze nie jest w tak złej sytuacji jak AOS 4.1 więc... w sumie dyskusja jest i tak czysto akademicka.
nie wiem, czy wkrada się czy nie, czytając jednak co się dzieje ostatnio na wszystkich 4 systemach (uwzględniając klasyka jako osobny podsystem) to klasyk i Aros dostarczają największych "rewelacji": Vampire SA i port Arosa na architekturę 64-bitową to w moim odczuciu największe sprawy w tym roku, ciekawy jestem co szykują chłopaki z MOS Team, bo coś cicho - albo nad czymś dłubią i pod koniec roku czeka nas niespodzianka albo... projekt przechodzi okres wakacyjnej hibernacji :)
Na marginesie - w moim odczuciu obydwa projekty rozwijane niejako bez statusu "oficjalnego" (celowy cudzysłów): AROS i MOS mają się obecnie lepiej niż konkurent. Ogólnie odnoszę wrażenie, że z systemów NG obecnie najszybciej rozwija się AROS, choć mam też świadomość, że jego rozwój w znacznej mierze ma charakter "systemu - gościa" na hoście zewnętrznym, choć czy w czasach mody na wszelkiej maści wirtualizacje to znów taki "grzech"?
--------------------------------
Co do sprzętu - gdybym był na miejscu koderów dowolnego systemu operacyjnego to starałbym się znaleźć platformę z jak najlepszą dokumentacją ogólnodostępną, przy zachowaniu minimum wersji konfiguracji sprzętowych. Pod tym kątem sprzęt Apple znakomicie wpisuje się w 2 z warunków, choć pierwszy zdecydowanie nie wygląda tutaj za dobrze.
Dla odmiany RPi spełnia obydwa: jest dokumentacja, jest ograniczona liczba wariantów. Brak PCI-E czy M.2 dla takiego systemu jak MOS jest raczej mało adekwatne do realnych wymagań oprogramowania (chyba, że chodzi o sterowniki grafiki, możliwe, że team boi się o problemy z opracowaniem względnie wydajnych sterowników, podczas gdy dla starych kart AMD takie sterowniki jednak są już gotowe).
Cóż - jak widać każda opcja ma swoje wady i swoje zalety. MorphOS obecnie jeszcze nie jest w tak złej sytuacji jak AOS 4.1 więc... w sumie dyskusja jest i tak czysto akademicka.
16.07.2019 16:26
[#201]
Re: MorphOS na ARM - czemu nie?
@Slepaq, post #199
port Arosa na architekturę 64-bitową
Pozwole sobie sprostowac: port AROSa na architekture 64-bitowa (x86_64) powstal juz ponad 10 lat temu. Od 29. listopada 2007 jest dostepny w postaci nightly-build dla kazdego. To co powstaje w tej chwili to dystrybucja AROSa, czyli system + skorki + dodatki + porty programow.
Ostatnia aktualizacja: 16.07.2019 16:40:13 przez mschulz
16.07.2019 20:28
[#202]
Re: MorphOS na ARM - czemu nie?
@Slepaq, post #199
pozwole sobie tutaj to ogłosić, że planuje przygotować skrypt lub całą meta dystrybucje debiana/ubuntu która będzie miała arosa jako menager okien dla xwindow system. jednak to projekt najszybciej na wrzesień bo wcześniej planuje zrobić meta dystrybucje raspbiana dla fanów retrokomputerów
16.07.2019 21:31
[#203]
Re: MorphOS na ARM - czemu nie?
@XoR, post #139
Cześć wszystkim!
Nie znam się zbytnio na Amidze (mam za mało lat), ale lubię to forum, bo pozwala uzupełniać wiedzę i klimat tego komputera. Jest tu dużo kreatywnych ludzi, których podziwiam.
Zobacz dokumentację UEFI (następcy BIOS). Masz tam API do obsługi wielu rdzeni procesora, tworzenia połączeń sieciowych, grafiki (od robienia bitmap i bitblit, poprzez rysowania kształtów po obsługę okien) i prawie wszystkiego co jest potrzebne prostemu systemowi operacyjnemu do funkcjonowania.
Zabawa jest jeszcze łatwiejsza niż w tradycyjnym BIOS. Masz partycję EFI którą tak na serio jest FAT32 lub NTFS ze zmienionym ID. Wrzucasz tam pliki w formacie PE (Windowsowe EXE), UEFI je wczytuje do pamięci i startuje przy uruchomieniu komputera jako bootloadery. Nawet masz od razu przygotowany tryb procesora 32 lub 64 bitowy.
Powstała mała scena w której ludzie tworzą porty oprogramowania tak, by uruchamiały się na UEFI zamiast w systemie operacyjnym, bo to fajne wyzwanie.
---
W wątku pojawia się problem wiecznego braku sterowników i trudności w obsłudze różnorodnej konfiguracji. Zwykle robi się to za pomocą HAL (warstwa abstrakcji urządzeń). Jest to mechanizm programowy, który sprawia, ze różnorodne rodzaje urządzeń, system operacyjny obsługuje w jeden sposób.
Chcę zaproponować by takim mechanizmem w waszych rozważaniach został kernel Linux.
Jego zalety to:
- Obsługuje dużo sprzętu i różnorodnych architektur x86, ARM, PPC;
- obsługuje wiele rdzeni i ma ochronę pamięci;
- ma stabilne API w warstwie komunikacji z nim od strony użytkownika (stabilne syscalle i namespace);
- uruchamia się około 2s na współczesnym sprzęcie (u mnie: 2.166s (kernel));
- ma bardzo wydajne mechanizmy zarządzania komputerem (wydajniejsze od Windows);
- karty graficzne oprócz Nvidii mają jednolite API z akceleracją (nie trzeba używać X, by używać 3d);
- dużo narzędzi dla programistów;
- obsługuje wiele systemów plików, nawet te z Amigi i Atari;
- jest wciąż dynamicznie rozwijany przez wiele osób i firm.
Żeby ktoś mnie źle nie zrozumiał. Chodzi o samo jądro Linux bez systemu GNU i X.
Można je wykorzystać jako jednolitą warstwę do komunikacji z różnorodnym sprzętem, zarządzaniem procesami, pamięcią, klawiaturą, myszą, dyskami, grafiką, dźwiękiem i siecią. Jest nawet mechanizm który umożliwia wczytywanie dowolnych formatów programów, więc nie musicie rezygnować ze swoich przyzwyczajeń.
Fajnie gdyby system amigowy powstał na czymś takim (jak ChromeOS lub Android) i się upowszechnił. Mógłby wtedy działać i na PPC i na Raspberry Pi i na prawie dowolnym PC. Zniknęłyby problemy, które ma zespół twórców NG, a przeglądarki wymagałyby już tylko dopasowania podsystemu wyświetlania i pobierania zdarzeń z systemu.
Gdybyście dodali do tego standardowy terminal z narzędziami GNU (jak MacOS z narzędziami BSD), system stałby się jeszcze bardziej atrakcyjny dla potencjalnych użytkowników.
Mam za mało lat, żeby rozumieć czy takie podejście wywoła u was antagonistyczne reakcje. Ale takie są obecnie realia, żeby zaistnieć. Wystarczy zobaczyć ile jest małych systemów operacyjnych tworzonych przez entuzjastów (np. RedoxOS) i jak mozolnie to idzie, nawet z dużym budżetem (ReactOS). Mały zespół już nie może stworzyć całego systemu operacyjnego bo to jest skomplikowane zadanie. To było możliwe 30 lat temu, pod warunkiem, że się mocno ograniczyło ambicję.
Jeśli ktoś się jednak czuje na siłach to jest w sieci dużo poradników o tym jak stworzyć system operacyjny na Raspberry PI np. https://jsandler18.github.io/
Ponadto na uczelniach w USA jednym z zadań na zaliczenie, jest często stworzenie prostego systemu na tę platformę i są o tym nagrania wykładów. Wiele osób próbuje też programować tę płytkę bez systemu operacyjnego i nie mają z tym kłopotów dzięki dostępnej dokumentacji. Jednak gdyby powstanie rozbudowanego systemu operacyjnego od podstaw było łatwe, to już by takich systemów powstało wiele.
Nie znam się zbytnio na Amidze (mam za mało lat), ale lubię to forum, bo pozwala uzupełniać wiedzę i klimat tego komputera. Jest tu dużo kreatywnych ludzi, których podziwiam.
Akurat na X86 najłatwiej napisać OS aby działał na prawie dowolnym komputerze.
Potrzebujemy obsługę[...]
Zobacz dokumentację UEFI (następcy BIOS). Masz tam API do obsługi wielu rdzeni procesora, tworzenia połączeń sieciowych, grafiki (od robienia bitmap i bitblit, poprzez rysowania kształtów po obsługę okien) i prawie wszystkiego co jest potrzebne prostemu systemowi operacyjnemu do funkcjonowania.
Zabawa jest jeszcze łatwiejsza niż w tradycyjnym BIOS. Masz partycję EFI którą tak na serio jest FAT32 lub NTFS ze zmienionym ID. Wrzucasz tam pliki w formacie PE (Windowsowe EXE), UEFI je wczytuje do pamięci i startuje przy uruchomieniu komputera jako bootloadery. Nawet masz od razu przygotowany tryb procesora 32 lub 64 bitowy.
Powstała mała scena w której ludzie tworzą porty oprogramowania tak, by uruchamiały się na UEFI zamiast w systemie operacyjnym, bo to fajne wyzwanie.
---
W wątku pojawia się problem wiecznego braku sterowników i trudności w obsłudze różnorodnej konfiguracji. Zwykle robi się to za pomocą HAL (warstwa abstrakcji urządzeń). Jest to mechanizm programowy, który sprawia, ze różnorodne rodzaje urządzeń, system operacyjny obsługuje w jeden sposób.
Chcę zaproponować by takim mechanizmem w waszych rozważaniach został kernel Linux.
Jego zalety to:
- Obsługuje dużo sprzętu i różnorodnych architektur x86, ARM, PPC;
- obsługuje wiele rdzeni i ma ochronę pamięci;
- ma stabilne API w warstwie komunikacji z nim od strony użytkownika (stabilne syscalle i namespace);
- uruchamia się około 2s na współczesnym sprzęcie (u mnie: 2.166s (kernel));
- ma bardzo wydajne mechanizmy zarządzania komputerem (wydajniejsze od Windows);
- karty graficzne oprócz Nvidii mają jednolite API z akceleracją (nie trzeba używać X, by używać 3d);
- dużo narzędzi dla programistów;
- obsługuje wiele systemów plików, nawet te z Amigi i Atari;
- jest wciąż dynamicznie rozwijany przez wiele osób i firm.
Żeby ktoś mnie źle nie zrozumiał. Chodzi o samo jądro Linux bez systemu GNU i X.
Można je wykorzystać jako jednolitą warstwę do komunikacji z różnorodnym sprzętem, zarządzaniem procesami, pamięcią, klawiaturą, myszą, dyskami, grafiką, dźwiękiem i siecią. Jest nawet mechanizm który umożliwia wczytywanie dowolnych formatów programów, więc nie musicie rezygnować ze swoich przyzwyczajeń.
Fajnie gdyby system amigowy powstał na czymś takim (jak ChromeOS lub Android) i się upowszechnił. Mógłby wtedy działać i na PPC i na Raspberry Pi i na prawie dowolnym PC. Zniknęłyby problemy, które ma zespół twórców NG, a przeglądarki wymagałyby już tylko dopasowania podsystemu wyświetlania i pobierania zdarzeń z systemu.
Gdybyście dodali do tego standardowy terminal z narzędziami GNU (jak MacOS z narzędziami BSD), system stałby się jeszcze bardziej atrakcyjny dla potencjalnych użytkowników.
Mam za mało lat, żeby rozumieć czy takie podejście wywoła u was antagonistyczne reakcje. Ale takie są obecnie realia, żeby zaistnieć. Wystarczy zobaczyć ile jest małych systemów operacyjnych tworzonych przez entuzjastów (np. RedoxOS) i jak mozolnie to idzie, nawet z dużym budżetem (ReactOS). Mały zespół już nie może stworzyć całego systemu operacyjnego bo to jest skomplikowane zadanie. To było możliwe 30 lat temu, pod warunkiem, że się mocno ograniczyło ambicję.
Jeśli ktoś się jednak czuje na siłach to jest w sieci dużo poradników o tym jak stworzyć system operacyjny na Raspberry PI np. https://jsandler18.github.io/
Ponadto na uczelniach w USA jednym z zadań na zaliczenie, jest często stworzenie prostego systemu na tę platformę i są o tym nagrania wykładów. Wiele osób próbuje też programować tę płytkę bez systemu operacyjnego i nie mają z tym kłopotów dzięki dostępnej dokumentacji. Jednak gdyby powstanie rozbudowanego systemu operacyjnego od podstaw było łatwe, to już by takich systemów powstało wiele.
16.07.2019 22:15
[#204]
Re: MorphOS na ARM - czemu nie?
@074, post #203
Zobacz dokumentację UEFI (następcy BIOS). Masz tam API do obsługi wielu rdzeni procesora, tworzenia połączeń sieciowych, grafiki (od robienia bitmap i bitblit, poprzez rysowania kształtów po obsługę okien) i prawie wszystkiego co jest potrzebne prostemu systemowi operacyjnemu do funkcjonowania.
Tak, jednak praktycznie wszystkie systemy operacyjne wykorzystuja UEFI prawie tak samo jak BIOS - to zaladowania systemu i wstepnej konfiguracji, reszte robia same.
W wątku pojawia się problem wiecznego braku sterowników i trudności w obsłudze różnorodnej konfiguracji. Zwykle robi się to za pomocą HAL (warstwa abstrakcji urządzeń). Jest to mechanizm programowy, który sprawia, ze różnorodne rodzaje urządzeń, system operacyjny obsługuje w jeden sposób.
Tak, tez to mamy w kazdym z amisystemow. O ile HAL ulatwia tworzenie oprogramowania korzystajacego ze sprzetu, to same sterowniki stoja po drugiej stronie tej warstwy abstrakcji i trzeba je napisac.
Chcę zaproponować by takim mechanizmem w waszych rozważaniach został kernel Linux.
...
Żeby ktoś mnie źle nie zrozumiał. Chodzi o samo jądro Linux bez systemu GNU i X.
Tak, dokladnie tak. I nad czyms takim pracuje w wolnych chwilach, nazwalem to ARIX. Jak dojde do momentu w ktorym wystartuje shell (chocby w trybie tekstowym, bez grafiki) to naglosnie projekt i bede szukal wsparcia.
16.07.2019 22:40
[#205]
Re: MorphOS na ARM - czemu nie?
@abcdef, post #195
Z twojego punktu widzenia zapewne nic, z punktu widzenia drużyny developerskiej elastyczność, choć biorąc pod uwagę małą moc przerobową, dość ograniczoną. Jeśli argumenty słowne są słabo przekonywujące, droga pieniądza być może będzie mniej wyboista.
Ostatnia aktualizacja: 16.07.2019 22:42:26 przez sanjyuubi
Ostatnia aktualizacja: 16.07.2019 22:42:26 przez sanjyuubi
17.07.2019 14:27
[#210]
Re: MorphOS na ARM - czemu nie?
@Jacek Piszczek, post #208
Cóż... Nie powiem, miałem wielką chrapkę na nową wersję przeglądarki z 3.12, ale jeśli miałaby się opóźnić z tego powodu...
Powodzenia przy pracach nad nowym portem. Jeśli potrzebujesz jakiejś pomocy (na przykład - wziąć sobie wolne od pracy na koszt mosowiec) to daj znać.
Powodzenia przy pracach nad nowym portem. Jeśli potrzebujesz jakiejś pomocy (na przykład - wziąć sobie wolne od pracy na koszt mosowiec) to daj znać.