Komentowana treść: A-EON i Hyperion - niewygodne wycieki
16.08.2018 15:50
[#62]
Re: A-EON i Hyperion - niewygodne wycieki
@mschulz, post #57
Przytoczę korespondencję Franka Mariaka (cyfm) z użytkownikiem Yasu na MorphZone, październik 2015:
cyfm:
Zgadzam się, że [support dla SAM 460] nie ma większego sensu jeśli mowa o jakimś znaczącym przyroście sprzedaży licencji, czy poszerzaniu bazy użytkowników.
Prawdopodobnie jednyne powody dla których poświęciliśmy energię na przeportowanie MorphOSa na ten sprzęt to te, że niektórzy zawsze mówili "MorphOS obsługuje albo stary, albo używany sprzęt" oraz to, że potrafiliśmy to zrobić... :)
Yasu:
Zatem [w przypadku Tabora] zostaje praktycznie tylko "bo potrafimy". Ale czy nie działałby zbyt wolno, bez obsługiwanego FPU?
cyfm:
Jesteśmy świadomi istnienia tej płyty już od jakiegoś czasu.
Ze względu na jej oczywiste ograniczenia nie ma jednak większego sensu portowanie na nią aktualnej wersji MorphOSa.
Brak kompatybilnego FPU to spora przeszkoda, żeby korzystać na niej z obecnego MorphOSa.
Podsumowując - argument "bo potrafimy" wypada w tym przypadku raczej słabo.
Oryginał dyskusji (w języku angielskim) - tutaj.
cyfm:
Zgadzam się, że [support dla SAM 460] nie ma większego sensu jeśli mowa o jakimś znaczącym przyroście sprzedaży licencji, czy poszerzaniu bazy użytkowników.
Prawdopodobnie jednyne powody dla których poświęciliśmy energię na przeportowanie MorphOSa na ten sprzęt to te, że niektórzy zawsze mówili "MorphOS obsługuje albo stary, albo używany sprzęt" oraz to, że potrafiliśmy to zrobić... :)
Yasu:
Zatem [w przypadku Tabora] zostaje praktycznie tylko "bo potrafimy". Ale czy nie działałby zbyt wolno, bez obsługiwanego FPU?
cyfm:
Jesteśmy świadomi istnienia tej płyty już od jakiegoś czasu.
Ze względu na jej oczywiste ograniczenia nie ma jednak większego sensu portowanie na nią aktualnej wersji MorphOSa.
Brak kompatybilnego FPU to spora przeszkoda, żeby korzystać na niej z obecnego MorphOSa.
Podsumowując - argument "bo potrafimy" wypada w tym przypadku raczej słabo.
Oryginał dyskusji (w języku angielskim) - tutaj.
16.08.2018 17:05
[#67]
Re: A-EON i Hyperion - niewygodne wycieki
@Sventevith, post #65
Nie ma też oficjalnego stanowiska IdSoftware że najnowszy Quake nie wyjdzie na OS4.
No ale ponoć było w sprawie Dooma i OS3
A tak poza tym to chyba nikt z dyskutantów PPA, nie odczytał chyba mojej wypowiedzi dosłownie że ktoś fizycznie wystawił białą flagę z napisem
Przecież to była przenośnia. 16.08.2018 17:28
[#68]
Re: A-EON i Hyperion - niewygodne wycieki
@MUFA-amigaone-pl, post #67
A tak poza tym to chyba nikt z dyskutantów PPA, nie odczytał chyba mojej wypowiedzi dosłownie że ktoś fizycznie wystawił białą flagę z napisemszeroki uśmiech Przecież to była przenośnia.
Oczywiscie ze to byla przenosnia i oczywistym jest ze nikt z dyskutantow nie odczytal tego doslownie. Ale to tylko polowa twojego zdania. Druga polowa nie byla przenosnia (tylko twoja interpretacja) i inaczej niz doslownie sie jej odczytac nie dalo.
Ale skoro juz wywolujesz wilka z lasu (czesc Twojego zdania o bialej fladze) to podyskutujmy. Wywieszenie bialej flagi jest ogolnie rozumianym symbolem zaprzestania walki i poddania sie, tudziesz poddania sie przed jakimkolwiek podjeciem walki. Czyzbys sugerowal ze MOSTeam podjal sie wyzwania przeportowania MOS-a na owa plyte glowna? A moze sugerujesz ze Hyperion/A-EON zasugerowal tego rodzaju pojedynek a MOS-Team wycofal sie wrecz bez walki?
Czy A-EON wystosowal oficjalny LoI (letter of intent) do teamu MOS z propozycja przeportowania MorphOSa na rzeczona plyte glowna? Czy taka propozycja (uwaga, nie ze strony osob trzecich tylko bezposrednio od A-EON) byla wystosowana i nie spotkala sie z zadna ofijalna odpowiedzia ze strony MOS-Teamu? Jezeli A-EON prosil a MOS-Team prosbe zignorowal to faktycznie nieladnie. Jezeli jednak A-EON oficjalnie o port systemu poprosil a MOS-Team oficjalnie odmowil (nie wazne jaka przyczyna), albo jesli A-EON nawet pytania nie postawil, to sytuacja jest jak najbardziej OK i nawet pierwsza czesc Twojego zdania o bialej fladze jest nad wyraz niestosowna.
Wyjasnie Ci to na przykladzie AROSa. Pojawila sie potrzeba przeportowania systemu AROS na maszyne Sam440ep. Producent (ACube) zglosil sie calkiem oficjalnie i wyrazil stosowna potrzebe i spotkal sie z odpowiedzia. Producent zalozyl nawet bounty, ktos sypnal kasa i port AROSa powstal. Chwile pozniej Genesi zglosilo sie z podobna prosba (port AROSa na Efike PPC) i znowu port zostal wykonany. Z trzeciej strony, Trevor wspomnial kiedys ze fajnie by bylo miec AROS-a na X1000, ale nie bylo oficjalnego zapytania to i oficjalnej odpowiedzi nie bylo. Port nie powstal, nie dlatego ze "nie da sie", tylko dlatego ze ani nie bylo oficjalnej potrzeby ani zaden z AROSowych developerow nie byl zainteresowany czyms takim. Co wiecej, nikt nie musial nic oglaszac oficjalnie (w stylu, "AROS Team nie przeportuje systemu na X1000") bo po co?
16.08.2018 17:53
[#69]
Re: A-EON i Hyperion - niewygodne wycieki
@Hexmage960, post #31
Podstawową biblioteką Amiga OS jest exec.library, która jest jedynym elementem bezwzględnym w hierarchii systemowej, tzn. dostęp do niego jest od razu (biblioteka ta jest zawsze otwarta).
Pozostałe biblioteki otwiera exec.library za pomocą funkcji OpenLibrary(). Po otrzymaniu dostępu, można używać sporej bazy funkcji bibliotecznych do grafiki, okien, schowka, lokalizacji, funkcji matematycznych, animacji, muzyki itp.
Jak widać architektura Amiga OS, którą opracował jeszcze zespół Commodore-Amiga był bardzo dalekowzroczny. Architektura w takim rozumieniu jest w pełni do przeniesienia na inne architektury, czy procesory.
Tak przy okazji - jak w takim systemie (tzn. wskaźnik na exec.library przechowywany w stałym miejscu w pamięci) zaimplementować ASLR? Od kilku lat to już standard...
16.08.2018 18:17
[#71]
Re: A-EON i Hyperion - niewygodne wycieki
@mschulz, post #68
Myślę że A-EON zgłosił się do nich z prośbą bo pod pierwszym newsem o Taborze Rzookol dawał do zrozumienia że MOSTeam wiedzial o tym projekcie wcześniej.
Tak z innej beczki gdybyś Ty zgłosił się do mnie w temacie współpracy nad wspólnym portem nad jakiegoś programu. Cóż programować nie umiem ale jak twierdzi wspomniany Rzookol w informatyce nie ma rzeczy niemożliwych i może w te trzy lata bym się czegoś nauczył. Gdybym ja odpowiedział "wiem że pewnie za trzy lata dałbym radę to zrobić, lecz nie chce mi się już uczyć na starość, poza tym mam ciekawsze rzeczy do roboty, więc wybacz ale zrezygnuję" to moim zdaniem miałbyś pełne prawo powiedzieć że Mufa wywiesił w tym temacie białą flagę, a ja nie miałbym żadnego powodu by się na to obrażać.
Tak z innej beczki gdybyś Ty zgłosił się do mnie w temacie współpracy nad wspólnym portem nad jakiegoś programu. Cóż programować nie umiem ale jak twierdzi wspomniany Rzookol w informatyce nie ma rzeczy niemożliwych i może w te trzy lata bym się czegoś nauczył. Gdybym ja odpowiedział "wiem że pewnie za trzy lata dałbym radę to zrobić, lecz nie chce mi się już uczyć na starość, poza tym mam ciekawsze rzeczy do roboty, więc wybacz ale zrezygnuję" to moim zdaniem miałbyś pełne prawo powiedzieć że Mufa wywiesił w tym temacie białą flagę, a ja nie miałbym żadnego powodu by się na to obrażać.
16.08.2018 18:52
[#72]
Re: A-EON i Hyperion - niewygodne wycieki
@mschulz, post #42
Taki przyklad jeszcze: w wersji SMP AROS-a trzeba bylo dodac nowe mechanizmy blokujace (spinlock) ktore sa wbudowane np. w strukture MessagePort (bo musza, inaczej nie dalo by sie uzywac MsgPort do przesyłania wiadomości miedzy procesorami). Jaki jest tego skutek? Nawet stare AROSowe programy skompilowane pod x86_64 musza byc przekompilowane na nowo pod wersje SMP, bo rozmiar struktury sie zmienil. Co gorsza, trzeba koniecznie uzyc funkcji systemowej CreateMsgPort. Stary sposob uzywany przez niektore programy (np. stworzenie MsgPort na stosie czy w pamieci i zainicjalizowanie "na piechote") nie zadziala bo stary kod nie ma wiedzy jak zainicjalizowac spinlocka.
I tak dochodzimy do wniosku, że najnowocześniejszym amigowym systemem jest Aros. Pozostałe dwa same skazały się na powolną wegetację, dobrowolnie przykuwając się do archaicznych ograniczeń z 1985 roku. Konsekwencją tych wyborów jest stan dzisiejszy, czyli brak szans na jakikolwiek ruch w stronę nowoczesności.
I nie pomogą tu już żadne Radeony RX itp. bo nic to zasadniczo nie zmienia. To jakby do hulajnogi przyspawać sobie koło od Stara i udawać, że przez to jedzie się szybciej. To nadal jest hulajnoga, tylko teraz z dodatkowym balastem. I para która poszła na oprogramowanie tego balastu mogła pójść np. na unowocześnienie architektury samego systemu. Ale nie poszła, dlatego pozostaje tylko nadal nakładać szminkę na stare truchło i udawać, że to oznacza że idziemy w nowoczesność. Niestety spod szminki zawsze będzie wystawać ten 1985 rok i wybory które wtedy były dobre dziś mogą tylko zadziwiać swoją archaicznością. Zadziwiał będzie też fakt, że ktoś ciągnął je aż do 2018 roku nic z tym przez dziesięciolecia nie robiąc.
Reasumując jeśli jakiś user OS4 chce zachować jakiekolwiek pozory rozwoju i patrzenia w przyszłość to powinien lobbować za tym, aby przestać reanimować te zwłoki i zapakować w stanie jakim są do emulatora w stylu QEMU i obudować czymś bardziej nowoczesnym, np. Arosem.
16.08.2018 19:31
[#73]
Re: A-EON i Hyperion - niewygodne wycieki
@mschulz, post #68
A czy możesz podać jakies widełki ile kosztuje taki port? W sumie gdyby powstał na nowy sprzet ze sklepu np. AMD wypuściło ostatnio AMD SOC Ryzen z Vegą, ciekawe ile musiałoby wynieść bounty na taki port?
1 przykład
2 przykład
3 przykład
Ostatnia aktualizacja: 16.08.2018 19:43:52 przez KM
Ostatnia aktualizacja: 16.08.2018 19:47:33 przez KM
1 przykład
2 przykład
3 przykład
Ostatnia aktualizacja: 16.08.2018 19:43:52 przez KM
Ostatnia aktualizacja: 16.08.2018 19:47:33 przez KM
16.08.2018 20:55
[#74]
Re: A-EON i Hyperion - niewygodne wycieki
@KM, post #73
A czy możesz podać jakies widełki ile kosztuje taki port? W sumie gdyby powstał na nowy sprzet ze sklepu np. AMD wypuściło ostatnio AMD SOC Ryzen z Vegą, ciekawe ile musiałoby wynieść bounty na taki port?
Nie ma zadnych widelek. Mogloby sie zdazyc ze ktos z developerow nabedzie taki sprzet i sam zrobi port dla frajdy. Moze sie zdazyc ze port kosztowalby tyle ile sprzet (ktory trzeba nabyc zeby ktorys z developerow sie tym zajal). Rownie dobrze cena protu moglaby pojsc w tysiace EUR gdyby jacys zyczliwcy chcieli sypnac groszem.
A taki SOC sam z siebie to nie problem od strony CPU, gorzej by bylo z GPU...
17.08.2018 18:17
[#79]
Re: A-EON i Hyperion - niewygodne wycieki
@jubi, post #72
Wydaje mi się, że ten problem to jest paradoksalnie wynik wysokich wymagań środowiska amigowego co do "koszerności" produktu. Próby odejścia od klasycznej Amigi były zawsze krytykowane i zawsze była dyskusja typu "czy to na pewno jeszcze Amiga?".
PS.
A co do Arosa, to tutaj mogli (i musieli z powodu architektury x86) pójść inną drogą. I fajnie w nim rozwiązano problem kompatybilności programów 68K właśnie przez zintegrowany emulator (Ami Bridge). Czyli to jest chyba to o czym piszesz.
A co do OS4 to nie wiem czy warto by go było opakowywać jeszcze w kolejny emulator. Dużo programów jest na OS4 których utrata po przesiadce na Arosa by bolała?
PS.
A co do Arosa, to tutaj mogli (i musieli z powodu architektury x86) pójść inną drogą. I fajnie w nim rozwiązano problem kompatybilności programów 68K właśnie przez zintegrowany emulator (Ami Bridge). Czyli to jest chyba to o czym piszesz.
A co do OS4 to nie wiem czy warto by go było opakowywać jeszcze w kolejny emulator. Dużo programów jest na OS4 których utrata po przesiadce na Arosa by bolała?
17.08.2018 19:37
[#80]
Re: A-EON i Hyperion - niewygodne wycieki
@jubi, post #72
I tak dochodzimy do wniosku, że najnowocześniejszym amigowym systemem jest Aros.
ozostałe dwa same skazały się na powolną wegetację, dobrowolnie przykuwając się do archaicznych ograniczeń z 1985 roku.
To jakby do hulajnogi przyspawać sobie koło od Stara i udawać, że przez to jedzie się szybciej. To nadal jest hulajnoga, tylko teraz z dodatkowym balastem. (...) Niestety spod szminki zawsze będzie wystawać ten 1985 rok i wybory które wtedy były dobre dziś mogą tylko zadziwiać swoją archaicznością.
Reasumując jeśli jakiś user OS4 chce zachować jakiekolwiek pozory rozwoju i patrzenia w przyszłość to powinien lobbować za tym, aby przestać reanimować te zwłoki i zapakować w stanie jakim są do emulatora w stylu QEMU i obudować czymś bardziej nowoczesnym, np. Arosem.
mądrego to miło poczytać. Reasumując AROS rulatorz, ewentualnie pięćsetka z wąpierzem
17.08.2018 19:44
[#81]
Re: A-EON i Hyperion - niewygodne wycieki
@snajper, post #80
Nie wiem, czy odpalanie W95 na Vampirze przysporzy mu fanów? Argument, że się da jest z czapy, tak samo jak odpalanie na Vampirze z Amigą emulatora ST/STE. Ok. rozumiem, że Vampir może być też atrakcyjny jako turbo dla Atari (tak to mam chyba rozumieć, innego powodu nie widzę i to miała być reklama). Atari to fajny sprzęt, ale robienie z Vampira multiodpalacza to błąd moim zdaniem.
17.08.2018 20:15
[#82]
Re: A-EON i Hyperion - niewygodne wycieki
@KM, post #81
po pierwsze primo nie 95, tylko 98 - różnica dość istotna w świecie PC. Po drugie primo moim zamierzeniem nie było absolutnie prezentowanie możliwości Vampira - jakby ktoś chciał je poznać (są tu tacy, którzy jeszcze nie znają?), to są ku temu rzetelniejsze źródła - tym bardziej, że - jak sam mówisz - emulowanie (o tyle o ile) innej platformy raczej nie nakłoni nikogo do wyboru okreśłonego sprzętu retro. Filmik wkleiłem, bo jest dość świeży - tyle.
P.S. Zapomniałem dodać do @jubi - :piwox:
Ostatnia aktualizacja: 17.08.2018 20:19:36 przez snajper
P.S. Zapomniałem dodać do @jubi - :piwox:
Ostatnia aktualizacja: 17.08.2018 20:19:36 przez snajper
17.08.2018 20:25
[#83]
Re: A-EON i Hyperion - niewygodne wycieki
@jubi, post #72
Nie wiem co kolega określa jakie "archaiczne ograniczenia z 1985 roku". Pisałem przecież o architekturze Amiga OS nakreślonej w ROM Kernel Reference Manual 3rd Edition. Wielokrotnie podkreślałem, że ta koncepcja jest uniezależniona od architektury sprzętowej.
Zgodzę się, że taki Workbench z AmigaOS4 to jest archaizm. Miałem okazję jego poużywać i rzeczywiście, wymaga on dużej rozbudowy. Przy czym Workbench to nie jest Amiga OS, tylko aplikacja pod Amiga OS, która pozwala manipulować zasobami dyskowymi. Dzisiaj jednak najlepiej robić to za pomocą menadżerów plikowych.
Ale takie fantastyczne idee Amiga OS jak Commodities, WBStartup, DOSDrivers, Datatypes, Locale są naprawdę fajne i warto korzystać z możliwości, na jakie pozwalają. Większość idei Amiga OS nie pochodzi z 1985 roku, ale z początku lat 90. A już na starcie mieliśmy wielozadaniowość.
AROS jest być może (nie próbowałem) najnowocześniejszym rozwiązaniem, ale podobno nie jest kompatybilny, a i ilością oprogramowania nie grzeszy.
Innymi słowy należy wybierać między mnogością oprogramowania przy zachowaniu ograniczeń, a brakami w tym oprogramowaniu, ale pozwalając sobie na najnowsze rozwiązania sprzętowe.
Ja wybieram mnogość oprogramowania.
Może niech kolega spróbuje poużywać promowanego przez siebie AROSa przez dłuższy czas jako jedynego systemu. Bo ja wątpię, by był to pełnoprawny zamiennik, choć oczywiście cieszyłbym się, gdyby było inaczej.
Na koniec napiszę, że ja nie akceptuję systemu Amiga OS lub jego klonu odpalanego na jakimś obcym hoście. To musi być Amiga z wszelkimi jej wadami i zaletami.
Tak, jestem fanem procesorów M680x0, wbudowanego chipsetu AGA, stacji dyskietek. Jednak jak komuś pasuje klon bądź emulacja Amiga OS na ulubionej platformie to nie mam nic naprzeciwko. Sam przecież piszę, że nie jest to sprzeczne z założeniami systemu.
Brakuje jednak mi w takich rozwiązaniach jakiegoś "ducha", czy "klimatu", bądź "kultury" Amigi. Te rzeczy są bardzo dla mnie istotne.
Zgodzę się, że taki Workbench z AmigaOS4 to jest archaizm. Miałem okazję jego poużywać i rzeczywiście, wymaga on dużej rozbudowy. Przy czym Workbench to nie jest Amiga OS, tylko aplikacja pod Amiga OS, która pozwala manipulować zasobami dyskowymi. Dzisiaj jednak najlepiej robić to za pomocą menadżerów plikowych.
Ale takie fantastyczne idee Amiga OS jak Commodities, WBStartup, DOSDrivers, Datatypes, Locale są naprawdę fajne i warto korzystać z możliwości, na jakie pozwalają. Większość idei Amiga OS nie pochodzi z 1985 roku, ale z początku lat 90. A już na starcie mieliśmy wielozadaniowość.
AROS jest być może (nie próbowałem) najnowocześniejszym rozwiązaniem, ale podobno nie jest kompatybilny, a i ilością oprogramowania nie grzeszy.
Innymi słowy należy wybierać między mnogością oprogramowania przy zachowaniu ograniczeń, a brakami w tym oprogramowaniu, ale pozwalając sobie na najnowsze rozwiązania sprzętowe.
Ja wybieram mnogość oprogramowania.
Może niech kolega spróbuje poużywać promowanego przez siebie AROSa przez dłuższy czas jako jedynego systemu. Bo ja wątpię, by był to pełnoprawny zamiennik, choć oczywiście cieszyłbym się, gdyby było inaczej.
Na koniec napiszę, że ja nie akceptuję systemu Amiga OS lub jego klonu odpalanego na jakimś obcym hoście. To musi być Amiga z wszelkimi jej wadami i zaletami.
Tak, jestem fanem procesorów M680x0, wbudowanego chipsetu AGA, stacji dyskietek. Jednak jak komuś pasuje klon bądź emulacja Amiga OS na ulubionej platformie to nie mam nic naprzeciwko. Sam przecież piszę, że nie jest to sprzeczne z założeniami systemu.
Brakuje jednak mi w takich rozwiązaniach jakiegoś "ducha", czy "klimatu", bądź "kultury" Amigi. Te rzeczy są bardzo dla mnie istotne.
17.08.2018 23:33
[#84]
Re: A-EON i Hyperion - niewygodne wycieki
@Hexmage960, post #83
Idee ideami, ale nie mówimy tu o brakach ideowych w konstrukcji AmigaOS, tylko o ograniczeniach w architekturze systemu. Wspomniane Commodities, Locale, DosDrivers, czy sam multitasking wywłaszczeniowy są OK, zawsze się z tego cieszyliśmy, ale ich implementacja nie jest idealna. A pewne szczegóły uniemożliwiają/bardzo utrudniają dalszy rozwój (ograniczenia w ilości pamięci, wrażliwość na model endian, nieograniczony dostęp do struktur systemu wynikający z braku ochrony pamięci... i wiele innych). To co w połowie lat 80 było rewelacyjne, to już 30 lat później razi archaicznością.
To normalne, nie ma co dyskutować z rzeczywistością. Całkiem sensowne rozwiązanie proponowali swego czasu twórcy Morphosa - stare programy zamknięte w ABoxie (czyli tym, czym jest dzisiejszy MOS), będącym zadaniem w nowoczesnym QBoxie korzystającym w pełni z kernelu Quark (sam kernel powstał, ale jedynym zadaniem w nim odpalonym jest ABox). Szkoda, że raczej to nie powstanie. Chyba nikt o zdrowych zmysłach nie oczekuje, że systemy kompatybilne z AmigaOS czeka jakiś sukces rynkowy poza obszarem retrocomputingu, więc kasa na rozwój jest ograniczona.
To normalne, nie ma co dyskutować z rzeczywistością. Całkiem sensowne rozwiązanie proponowali swego czasu twórcy Morphosa - stare programy zamknięte w ABoxie (czyli tym, czym jest dzisiejszy MOS), będącym zadaniem w nowoczesnym QBoxie korzystającym w pełni z kernelu Quark (sam kernel powstał, ale jedynym zadaniem w nim odpalonym jest ABox). Szkoda, że raczej to nie powstanie. Chyba nikt o zdrowych zmysłach nie oczekuje, że systemy kompatybilne z AmigaOS czeka jakiś sukces rynkowy poza obszarem retrocomputingu, więc kasa na rozwój jest ograniczona.
18.08.2018 10:27
[#86]
Re: A-EON i Hyperion - niewygodne wycieki
@KM, post #85
Na to pytanie może odpowiedzieć tylko ktoś z Teamu (o ile nie jest to póki co wewnętrzną tajemnicą). Ale na Twoim miejscu - jako użytkownika - zamiast myśleć o przyszłości, skupiłbym się raczej na teraźniejszości. Przyszłość zostaw MorphOS Teamowi, póki co wydają sobie całkiem dobrze radzić z wyznaczonymi celami.
18.08.2018 13:19
[#88]
Re: A-EON i Hyperion - niewygodne wycieki
@wali7, post #84
Słyszę z jednej strony, że "architektura Amigi i jej systemu jest archaiczna".
Gdyby tego było mało - słyszę, że "w 1992 było już za późno" (bo wtedy Commodore wydało system Amiga OS 3.0 oraz wytyczne).
Dlaczego nie cofnąć się wcześniej?
Jeżeli ktoś chce ciągnąć coś, co ma związek z Amigą, może odrzucić historię, historyczne zaszłości, cały bagaż.
Jednakowoż są ludzie, dla których cała ta historia to jest coś nierozerwalnie z Amigą złączone. To jest część samej "Amigi".
Ciekawe dlaczego w 1992 miałoby być za późno. Commodore zbankrutował dopiero w 1994, zaś technologię Amigi starano się później w pewien sposób rozwijać. Jak widać w 1995 roku Amiga i jej technologia były nadal postrzegane jako maszyny zaprojektowane w Commodore.
Niech każdy bawi się Amigą, bądź systemami Amigowymi (lub nawet systemami, których związek z Amigą znają tylko oni) jak chce.
Zamiast jednak cofać się w czasie do roku 1985 lub nawet wcześniej (do lat 50.) celem zmiany biegu wydarzeń, które - teoretycznie - miały pewien wpływ na dzisiejszą sytuację na polu Amigi, lepiej na podstawie doświadczeń, wyciągnąć wnioski.
Ciekawe, że ludzie uważają, że w 1992 losy były już przesądzone. Może wtedy posiadali wehikuł czasu i przenieśli się w przyszłość?
Myślę, że na tym polu jest jeszcze wiele rzeczy do przedyskutowania. Szczególnie kierunek rozwoju systemów Amigowych.
Ludzie przecież nadal dyskutują o ruchu piłeczki w Pinballach na Amigę, czy o swoich ulubionych grach.
To dlaczego takie Commodities w Amidze nie podlegałoby dyskusji?
Ja sam jestem zaangażowany w Amigę klasyczną i powoli staram się rozwijać oprogramowanie.
--
P.S. Należy zadać sobie pytanie, czy Amiga to tylko system operacyjny. Bo tak się składa, że Microsoft stworzył MS-DOS i Windows, ale sprzętem wówczas zajmował się m.in. IBM. W przypadku Amigi również byli ludzie odpowiedzialni za sprzęt oraz za oprogramowanie. Ale wszyscy oni stanowili jeden zespół. Commodore zatem projektowało zarówno sprzęt jak i system operacyjny.
Dlatego też Amiga jest pewną całością. No ale niestety model działania IBM i Microsoftu okazał się najskuteczniejszy.
Teraz odpowiednikiem jest A-EON od sprzętu i Hyperion od systemu po stronie AmigaOS4, który pewnie stara się jak może, ale nie zawsze wychodzi.
A teraz zasadnicze pytanie: czy przejście na nowe platformy jest w ogóle konieczne? Czy ograniczenie 2GB RAM, taktowania procesorów, czy jednego rdzenia staje się już uciążliwe?
Do czego używacie swoich AmigaOS4/MorphOS? Z jakiego oprogramowania korzystacie?
Czy zdajecie sobie sprawę, że przy przejściu na nowoczesny sprzęt utracicie cały dorobek programistów, który możecie odratować częściowo tylko przy użyciu emulacji?
Ciekawym ile osób używa takiego MorphOSa do pracy, zabawy, bądź "MorphOSowania".
Ostatnia aktualizacja: 18.08.2018 13:20:51 przez Hexmage960
Gdyby tego było mało - słyszę, że "w 1992 było już za późno" (bo wtedy Commodore wydało system Amiga OS 3.0 oraz wytyczne).
Dlaczego nie cofnąć się wcześniej?
Jeżeli ktoś chce ciągnąć coś, co ma związek z Amigą, może odrzucić historię, historyczne zaszłości, cały bagaż.
Jednakowoż są ludzie, dla których cała ta historia to jest coś nierozerwalnie z Amigą złączone. To jest część samej "Amigi".
Ciekawe dlaczego w 1992 miałoby być za późno. Commodore zbankrutował dopiero w 1994, zaś technologię Amigi starano się później w pewien sposób rozwijać. Jak widać w 1995 roku Amiga i jej technologia były nadal postrzegane jako maszyny zaprojektowane w Commodore.
Niech każdy bawi się Amigą, bądź systemami Amigowymi (lub nawet systemami, których związek z Amigą znają tylko oni) jak chce.
Zamiast jednak cofać się w czasie do roku 1985 lub nawet wcześniej (do lat 50.) celem zmiany biegu wydarzeń, które - teoretycznie - miały pewien wpływ na dzisiejszą sytuację na polu Amigi, lepiej na podstawie doświadczeń, wyciągnąć wnioski.
Ciekawe, że ludzie uważają, że w 1992 losy były już przesądzone. Może wtedy posiadali wehikuł czasu i przenieśli się w przyszłość?
To normalne, nie ma co dyskutować z rzeczywistością.
Myślę, że na tym polu jest jeszcze wiele rzeczy do przedyskutowania. Szczególnie kierunek rozwoju systemów Amigowych.
Ludzie przecież nadal dyskutują o ruchu piłeczki w Pinballach na Amigę, czy o swoich ulubionych grach.
To dlaczego takie Commodities w Amidze nie podlegałoby dyskusji?
Ja sam jestem zaangażowany w Amigę klasyczną i powoli staram się rozwijać oprogramowanie.
--
P.S. Należy zadać sobie pytanie, czy Amiga to tylko system operacyjny. Bo tak się składa, że Microsoft stworzył MS-DOS i Windows, ale sprzętem wówczas zajmował się m.in. IBM. W przypadku Amigi również byli ludzie odpowiedzialni za sprzęt oraz za oprogramowanie. Ale wszyscy oni stanowili jeden zespół. Commodore zatem projektowało zarówno sprzęt jak i system operacyjny.
Dlatego też Amiga jest pewną całością. No ale niestety model działania IBM i Microsoftu okazał się najskuteczniejszy.
Teraz odpowiednikiem jest A-EON od sprzętu i Hyperion od systemu po stronie AmigaOS4, który pewnie stara się jak może, ale nie zawsze wychodzi.
A teraz zasadnicze pytanie: czy przejście na nowe platformy jest w ogóle konieczne? Czy ograniczenie 2GB RAM, taktowania procesorów, czy jednego rdzenia staje się już uciążliwe?
Do czego używacie swoich AmigaOS4/MorphOS? Z jakiego oprogramowania korzystacie?
Czy zdajecie sobie sprawę, że przy przejściu na nowoczesny sprzęt utracicie cały dorobek programistów, który możecie odratować częściowo tylko przy użyciu emulacji?
Ciekawym ile osób używa takiego MorphOSa do pracy, zabawy, bądź "MorphOSowania".
Ostatnia aktualizacja: 18.08.2018 13:20:51 przez Hexmage960
18.08.2018 15:31
[#89]
Re: A-EON i Hyperion - niewygodne wycieki
@KM, post #87
W roku 2013 na Alchimie niejaki Fab twierdził, że:
1. Będą obsługiwane nowsze karty od ATI (już są), również w PowerMakach z PCIe (jeszcze nie i nie wiadomo czy w ogóle)
2. Nowa wersja MorphOSa jest "w trakcie powstawania" i że zajmie dużo czasu. (zważywszy, że były to czasy 3.4 to możemy stwierdzić, że trochę nowych wersji od tego czasu powstało. Chyba że Fab miał na myśli "MorphOSa 4.0")
3. Prowadzone są prace nad maszyną wirtualną (Qemu?) - (póki co nic o tym nie wiadomo).
4. Celem jest w 100% 64 bitowy system, z obsługą wieloprocesorowości, ochroną pamięci, obsługą pamięci wirtualnej. Wiele wysiłku będzie wymagać przystosowanie obecnych komponentów do nowego systemu. Abox zostanie definitywnie zamknięty, gdyż nie ma sensu wprowadzanie do niego rzeczonych elementów (póki co - ani śladu).
5. PowerMaki nie otrzymają supportu dla SMP (możliwe jest w pewnym stopniu ASMP, ale będzie wymagać rekompilacji programów - jako przykład możliwości wykorzystania Fab wymienił MPlayera, czy Blendera). Nie potwierdził jednak, że ASMP będzie na 100%. (póki co nie ma SMP ani ASMP)
6. Kolejna architektura sprzętowa nie została wybrana, choć jest pewne wskazanie na x64 (pod Qemu). Fab stwierdził, że zależeć to będzie od dostępnych opcji sprzętowych.
Jak widać, wiele z tych punktów nie straciło na aktualności (stracił natomiast trochę sam Fab, który w teamie ma status AWOL).
Kłopot z teamem jest taki, że nie mają jakiegoś jednego PR-owca, który ogarnia wszystko i decyduje co zakomunikować ludziom, a co nie. Z jednej strony to dobrze, że nikt z programistów nie zajmuje się tą niewdzięczną robotą, a z drugiej - szkoda, bo pewnie ludzie trochę by się uspokoili (chociaż to zależy od zdolności PR-owca
).
1. Będą obsługiwane nowsze karty od ATI (już są), również w PowerMakach z PCIe (jeszcze nie i nie wiadomo czy w ogóle)
2. Nowa wersja MorphOSa jest "w trakcie powstawania" i że zajmie dużo czasu. (zważywszy, że były to czasy 3.4 to możemy stwierdzić, że trochę nowych wersji od tego czasu powstało. Chyba że Fab miał na myśli "MorphOSa 4.0")
3. Prowadzone są prace nad maszyną wirtualną (Qemu?) - (póki co nic o tym nie wiadomo).
4. Celem jest w 100% 64 bitowy system, z obsługą wieloprocesorowości, ochroną pamięci, obsługą pamięci wirtualnej. Wiele wysiłku będzie wymagać przystosowanie obecnych komponentów do nowego systemu. Abox zostanie definitywnie zamknięty, gdyż nie ma sensu wprowadzanie do niego rzeczonych elementów (póki co - ani śladu).
5. PowerMaki nie otrzymają supportu dla SMP (możliwe jest w pewnym stopniu ASMP, ale będzie wymagać rekompilacji programów - jako przykład możliwości wykorzystania Fab wymienił MPlayera, czy Blendera). Nie potwierdził jednak, że ASMP będzie na 100%. (póki co nie ma SMP ani ASMP)
6. Kolejna architektura sprzętowa nie została wybrana, choć jest pewne wskazanie na x64 (pod Qemu). Fab stwierdził, że zależeć to będzie od dostępnych opcji sprzętowych.
Jak widać, wiele z tych punktów nie straciło na aktualności (stracił natomiast trochę sam Fab, który w teamie ma status AWOL).
Kłopot z teamem jest taki, że nie mają jakiegoś jednego PR-owca, który ogarnia wszystko i decyduje co zakomunikować ludziom, a co nie. Z jednej strony to dobrze, że nikt z programistów nie zajmuje się tą niewdzięczną robotą, a z drugiej - szkoda, bo pewnie ludzie trochę by się uspokoili (chociaż to zależy od zdolności PR-owca
).