nowy framework do obliczeń rozproszonych - ujęcie ogólnie

[Tobas]

Zgadzam się z przedmówcą. Nie ma mowy o dobrej aplikacji, która będzie wymagała GUI.
Bez urazy, ale musisz się trochę ogarnąć w konsoli. To naprawdę nie jest żadna magia i wbrew pozorom jest dużo łatwiej / szybciej.
Nie wyobrażam sobie serwera wymagającego GUI. Bo po co?

[mariotti]

Zgadzam się z przedmówcą. Nie ma mowy o dobrej aplikacji, która będzie wymagała GUI.

Jakie jest uzasadnienie tego, że aplikacja GUI, oznacza kiepską aplikację? Przeciwne
twierdzenie uzasadniam inaczej: Billi Gates zarobił znaaaacznie więcej na windowsie 95
niż na dosie, bo windows był aplikacją GUI. W zasadzie windows 95 był kiepski, ale
pomimo tego odniósł sukces, ponieważ miał GUI, a ludzie chcieli używać aplikacji GUI.

Samo GUI w sobie nie decyduje o tym czy aplikacja jest dobra czy zła, ale może
decydować, że aplikacja będzie miała wzięcie i będzie łatwa obsługa - a to jest
celem nadrzędnym.

Niemniej można pomyśleć o takim napisaniu aplikacji (zarówno serwera jak i
klienta), żeby warstwę GUI mocno oddzielić od warstwy danych i obliczeń (MVC), a
takie oddzielenie z kolei umożliwi napisanie dwóch wersji: gui i konsolowej.

Bez urazy, ale musisz się trochę ogarnąć w konsoli.

Nie mam kompleksów w tym względzie. Po prostu to jest tak jak z
edycją plików w graficznym programie kate, albo w konsolowym sed.
W kate robi się to bardzo łatwo, intuicyjnie. Sed jest dobry jedynie gdy
pliki tekstowe są proste i jest ich wiele, bo wtedy można zrobić automatyzację.
Myślę że lepiej jest dla userów, jak dostaną narzędzie podobne do kate.

To naprawdę nie jest żadna magia i wbrew pozorom jest dużo łatwiej / szybciej.
Nie wyobrażam sobie serwera wymagającego GUI. Bo po co?

To dlaczego większość ludzi używa programów GUI, albo wręcz WYSIWYG?
Jaki procent użytkowników używa dziś postscripta, a jaki graficznych edytorów
tekstu?  Niemniej można zastanowić się nad dwiema wersjami UI, jedna graficzna,
druga tekstowa.

Czyli co? Do każdego projektu będzie osobna aplikacja do uruchomienia bez menadżera projektów? To ja wysiadam i nie biorę udziału... ;)

Dlaczego wysiadasz?

Rozbicie na klienta i menadżera wynika głównie z potrzeb osób odpalających BOINC na komputerach bez GUI (serwerach/urządzeniach embeded itd.)

Myślę że te potrzeby nadal będą zaspokojone.... być może lepiej.

Jeżeli framework będzie wymagał GUI do pracy to marnie widzę jego popularyzację wśród liczących a przynajmniej wyeliminowanie z gry wielu mocnych maszyn.

Na mocnej maszynie instalowanie GUI relatywnie mało zasobów zużywa. Ale rozumiem
że czasami ktoś nie będzie chciał instalować GUI. Teoretycznie można zrobić dwie wersje, w
praktyce oznacza to dodatkowy nakład pracy.

Pozdrawiam

[Karlik]

Jakie jest uzasadnienie tego, że aplikacja GUI, oznacza kiepską aplikację? Przeciwne
twierdzenie uzasadniam inaczej: Billi Gates zarobił znaaaacznie więcej na windowsie 95
niż na dosie, bo windows był aplikacją GUI. W zasadzie windows 95 był kiepski, ale
pomimo tego odniósł sukces, ponieważ miał GUI, a ludzie chcieli używać aplikacji GUI.

Samo GUI w sobie nie decyduje o tym czy aplikacja jest dobra czy zła, ale może
decydować, że aplikacja będzie miała wzięcie i będzie łatwa obsługa - a to jest
celem nadrzędnym.

Pisz w kontekście. Win95 miał GUI, ale nie był aplikacją serwerową a systemem operacyjnym, zresztą sam w sobie był nakładką na DOSa w pewnym sensie ;) Jeżeli chodzi o popularność to spójrz na aplikacje serwerowe: PostgreSQL, Apache, Postfix,... - ile z nich są aplikacjami okienkowymi a ile jest konsolowych (ewentualnie z graficznymi narzędziami konfiguracyjnymi)?

To dlaczego większość ludzi używa programów GUI, albo wręcz WYSIWYG?
Jaki procent użytkowników używa dziś postscripta, a jaki graficznych edytorów
tekstu?  Niemniej można zastanowić się nad dwiema wersjami UI, jedna graficzna,
druga tekstowa.

Bo większość userów nie administruje serwerami i/lub korzysta z tych aplikacji na domowych komputerkach. Wszystko zależy od zastosowań. O ile szybki wydruk/tekst łatwiej jest napisać w LibreOffice to pracy dyplomowej nie wyobrażam sobie pisać bez LaTeXa.

Dlaczego wysiadasz?

Zapewne dlatego, że jak będzie chciał wspierać 10 projektów, które mają sobie liczyć w tle i się sprawiedliwie dzielić zasobami to będzie trzeba instalować 10 aplikacji (do tego w Twojej koncepcji graficznych, które zaśmiecą tackę systemową), już nie mówiąc o komplikacjach dla użytkownika w skonfigurowaniu kto ma sobie ile liczyć w danym momencie.

Rozbicie na klienta i menadżera wynika głównie z potrzeb osób odpalających BOINC na komputerach bez GUI (serwerach/urządzeniach embeded itd.)

Myślę że te potrzeby nadal będą zaspokojone.... być może lepiej.

W sensie, że jednak będzie możliwość uruchomienia aplikacji na urządzeniach, które nie będą posiadały środowiska graficznego? Takie urządzenia najczęściej nie posiadają nawet karty graficznej, więc po co by im był zainstalowany serwer Xów?  :facepalm2:

Jeżeli framework będzie wymagał GUI do pracy to marnie widzę jego popularyzację wśród liczących a przynajmniej wyeliminowanie z gry wielu mocnych maszyn.

Na mocnej maszynie instalowanie GUI relatywnie mało zasobów zużywa.

Tak, ale wątpię, żeby administratorzy tych maszyn instalowali całe środowisko graficzne tylko po to, żeby woluntaryjnie wspierać jakiś projekt, który będzie wykorzystywał tylko niewykorzystane zasoby.

Mam wrażenie mariotti, że Ty myślisz o zupełnie innym typie zastosowania takich aplikacji. Taki framework jaki proponujesz może sprawdziłby się, ale tylko pod warunkiem, że byłby uruchamiany na DEDYKOWANYCH urządzeniach. W sensie, że dany komputer/serwer miałby działać tylko i wyłącznie na potrzeby danego projektu (i to tylko jednego). Wtedy jasne, wymaganie posiadania środowiska graficznego i innych dziwnych zależności nie jest problemem, jedynie, że marnowałoby trochę zasobów na wyświetlanie tego, ale to raczej nie problem w tym wypadku (np. z miesiąca obliczeń zrobiłby się dodatkowy dzień). No co najwyżej możnaby dorzucić jakiegoś apache'a cz inne oprogramowanie, ale to ono by było na gorszej pozycji :P

PS
Piszesz, że kod BOINCa jest trudny w połapaniu się. Wprawdzie nie znam go jakoś dobrze, ale na własne potrzeby byłem w stanie go poprawić na poziomie funkcji API (nie przewidzieli, że można mieć katalog slots i projects na różnych partycjach) i naprawdę zajęło mi to tylko chwilę (wyszukiwanie grepem w zasadzie i dopisanie może z dwóch/trzech linijek kodu) - najdłużej trwała rekompilacja  ;D

[krzyszp]

Dokładnie jak przedpiścy napisali:

1. Nie chcę mieć 10 ikonek w trayu, w dodatku każdy program z innym GUI...
2. Większość maszyn, które ja używam, nie mają wcale środowiska graficznego zainstalowanego. Wymagając go wywalasz z automatu 50% komputerów.
3. Trudności z regulacją obciążenia - bez managera klienckiego (jak BOINC Manager dzisiaj) kiepsko widzę podział zadań...

Ja naprawdę myślę, że mimo poziomu komplikacja BOINC, jest to jednak starannie przemyślany projekt...

[mariotti]

Pisz w kontekście. Win95 miał GUI, ale nie był aplikacją serwerową a systemem operacyjnym, zresztą sam w sobie był nakładką na DOSa w pewnym sensie ;) Jeżeli chodzi o popularność to spójrz na aplikacje serwerowe: PostgreSQL, Apache, Postfix,... - ile z nich są aplikacjami okienkowymi a ile jest konsolowych (ewentualnie z graficznymi narzędziami konfiguracyjnymi)?

Ależ piszę w kontekście. Kontekst jest taki, czy GUI pomaga czy nie. Napisałeś sam, że pisze się nakładki
graficzne, więc chyba nie po to, aby (tylko) utrudniały. Oczywiście rozwiązanie z zewnętrznym programem
GUI jest ogólnie lepsze. Jednak ta lepszość jest przypłacona nakładem pracy na samo wykonanie, jak i na
rozbudowę o nowe cechy w przypadku projektów niestandardowych. Generalnie szukam kompromisu
pomiędzy dużą funkcjonalnością a małym nakładem pracy.

Bo większość userów nie administruje serwerami i/lub korzysta z tych aplikacji na domowych komputerkach. Wszystko zależy od zastosowań. O ile szybki wydruk/tekst łatwiej jest napisać w LibreOffice to pracy dyplomowej nie wyobrażam sobie pisać bez LaTeXa.

Jak i GUI nie instaluje się tylko na domowych komputerkach. Xy działały już dawno temu, to z kolei
dowodzi, że X może działać na słabym komputerze - więc argument o zżeraniu zasobów też
wydaje się chybiony. Jest jeszcze kolejny argument na korzyść X. Ile najchudszy X wymaga pamięci
RAM? Dlaczego w ogóle kwestię Xów sprowadzać do GUI? Przecież to trochę różne sprawy. Gdy do
programu GUI podpinamy się ze zdalnego  komputera,  to wyświetlanie grafiki jest po stronie zdanego
komputera. Serwer musi wykonać tylko autoryzację, potem przesyła komunikaty IO, polecenia do wyświetlania
grafiki, itd. Nie wiem ile taki najchudszy X zajmuje zasobów - ta informacja będzie kluczowa.

Zapewne dlatego, że jak będzie chciał wspierać 10 projektów, które mają sobie liczyć w tle i się sprawiedliwie dzielić zasobami to będzie trzeba instalować 10 aplikacji (do tego w Twojej koncepcji graficznych, które zaśmiecą tackę systemową), już nie mówiąc o komplikacjach dla użytkownika w skonfigurowaniu kto ma sobie ile liczyć w danym momencie.

Czy to na pewno można nazwać śmieceniem? Tacka systemowa po to waśnie jest, aby był szybki i intuicyjny dostęp do wielu
programów przy małym śmieceniu na ekranie. O zarządzaniu wieloma projektami, bez względu czy są na jednym
komputerze, na wielu komputerach, czy są wręcz za maskaradą - już pisałem. Podam przykład w lokalnym kontekście:
1) user klika na dowolną aplikację liczącą w tacce
2) wyskakuje zunifikowany interfejs do ustawień
3) user wciska guzik "pokaż moje aplikacje liczące"
4) po czym z serwera napływa lista jego aplikacji
5) user zaznacza wybrane aplikacje i je konfiguruje, ma też szereg predefiniowanych
    konfiguracji, może ma też kilka kreatorów
6) potem wciska guzik "zastosuj"
7) ustawienia lecą do serwera
8) serwer odsyła każdej aplikacji liczącej ustawienia i każda aplikacja się dostosowuje, zatrzymuje,
    wznawia obliczenia, czy co tam jeszcze.

A jeśli 20 ikonek na tacce stanowi problem, to w sumie można zrobić prostą aplikację, która sama
się wyświetli na tacce i za jej pośrednictwem będzie dostęp do aplikacji liczących.

W sensie, że jednak będzie możliwość uruchomienia aplikacji na urządzeniach, które nie będą posiadały środowiska graficznego? Takie urządzenia najczęściej nie posiadają nawet karty graficznej, więc po co by im był zainstalowany serwer Xów?

Nie jestem specem od softu liuxowego, ale coś mi się zdaje, że X a wyświetlanie grafiki to
dwie różne sprawy. X chyba tylko dostarcza polecenia do wyświetlania grafiki? Grafikę
wyświetla coś innego i to na komputerze lokalnym. Na serwerze musi być tylko zestaw
oprogramowania z którego aplikacja GUI korzysta. Jest na forum ktoś kto na bieżąco
śledzi rozwój Xów i może się wypowiedzieć?

Tak, ale wątpię, żeby administratorzy tych maszyn instalowali całe środowisko graficzne tylko po to, żeby woluntaryjnie wspierać jakiś projekt, który będzie wykorzystywał tylko niewykorzystane zasoby.

No więc pomimo że tak bronię GUI, to od początku nie byłem przeciwnikiem alternatywnej
wersji konsolowej.

Mam wrażenie mariotti, że Ty myślisz o zupełnie innym typie zastosowania takich aplikacji. Taki framework jaki proponujesz może sprawdziłby się, ale tylko pod warunkiem, że byłby uruchamiany na DEDYKOWANYCH urządzeniach. W sensie, że dany komputer/serwer miałby działać tylko i wyłącznie na potrzeby danego projektu (i to tylko jednego). Wtedy jasne, wymaganie posiadania środowiska graficznego i innych dziwnych zależności nie jest problemem, jedynie, że marnowałoby trochę zasobów na wyświetlanie tego, ale to raczej nie problem w tym wypadku (np. z miesiąca obliczeń zrobiłby się dodatkowy dzień). No co najwyżej możnaby dorzucić jakiegoś apache'a cz inne oprogramowanie, ale to ono by było na gorszej pozycji

Chciałbym żeby na, jak to nazywasz, rozwiązania dedykowane, też pasowało.

Piszesz, że kod BOINCa jest trudny w połapaniu się. Wprawdzie nie znam go jakoś dobrze, ale na własne potrzeby byłem w stanie go poprawić na poziomie funkcji API (nie przewidzieli, że można mieć katalog slots i projects na różnych partycjach) i naprawdę zajęło mi to tylko chwilę (wyszukiwanie grepem w zasadzie i dopisanie może z dwóch/trzech linijek kodu) - najdłużej trwała rekompilacja

Bo były proste zależności. Jakby wiele innych część kodu spodziewało się tego co było przed Twoją zmianą, to
już tak prosto by nie poszło.


Pozdrawiam

[Karlik]

Może się nieprecyzyjnie wyraziłem. Teoretycznie można zdalnemu hostowi udostępnić swoje środowisko graficzne (-X dla ssh przykładowo), ale wtedy z tego co zrozumiałem musiałbym być cały czas podłączony do hosta, który prowadzi obliczenia - wg mnie bez sensu.
Nakładki faktycznie się pisze po to, żeby ułatwiały życie, ale nie jestem pewien statystyk ile z takowych korzysta. Poza tym weźmy dla przykładu phpMyAdmin - interfejs dla użytkowników MySQL, ale sam serwer potrafi się obyć bez tej nakładki (i tak części rzeczy nie jest się w stanie zrobić z niego korzystając), co więcej może być na zupełnie innym serwerze (a sama aplikacja może obsłużyć wiele serwerów o ile wiem). Nie ma chyba oprogramowanie serwerowego, którego nakladka/interfejs graficzny miałby takie same możliwości co konsola/pliki konfiguracyjne. Kwestia priorytetów - zazwyczaj najpierw (pomijając oczywistości typu bezpieczeństwo i stabilność) stawia się na funkcjonalność, dopiero potem na łatwość obsługi dla nie-administratora (bo ten zapewne i tak nie skorzysta z okienek albo w bardzo ograniczonym stopniu) i  w takiej też kolejności się to rozwija. Jeśli się zauważa, że jakaś funkcja jest często wykorzystywana (a nie zawsze jest prosta w obsłudze składniowo przykładowo) to się dorabia do niej jakieś okienka/skrypty - ogólnie gotowce na typowe zastosowania.
Ja nie mam nic przeciwko GUI, ale niech będzie opcją a nie koniecznością.
Serwer Xów w ogóle jest dość specyficznym oprogramowaniem, bo to od razu dostarcza cały interfejs do obsługi (teoretycznie) każdego rodzaju urządzeń. Obecnie chyba ogranicza się go do sterowania kartą graficzną, myszą i klawiaturą ;) Możliwe, że ktoś napisze coś innego/lepszego, ale jak na razie "konkurencja" jest w powijakach.

Już nawet nie chodzi o sam serwer Xów (bo to raptem kilka mega - chociaż po co skoro i tak nikt by nie używał), ale musiałbyś do tego doinstalować cokolwiek co utrzymywałoby sesję graficzną, bo jak by się zachował program po zamknięciu sesji? Żeby cokolwiek znieść do tacki systemowej najpierw takowa musiałaby być, więc na serwerze musiałbyś zainstalować KDE, GNOME czy cokolwiek innego. A to dodatkowe komplikacje dla administratora i obciążenie dla serwera.

Chciałbym żeby na, jak to nazywasz, rozwiązania dedykowane, też pasowało.

No właśnie problem w tym, że jak na razie opisujesz coś co jest bardziej dedykowanym rozwiązaniem a nie takim "pod strzechy" (tutaj naprawdę duży cudzysłów). Oczywiście jest duża szansa, że znalazłaby się nisza zainteresowanych, ale to zupełnie inny target niż przykładowo BOINC - siłą rzeczy nie robiłbyś mu konkurencji :D

[mariotti]

Może się nieprecyzyjnie wyraziłem. Teoretycznie można zdalnemu hostowi udostępnić swoje środowisko graficzne (-X dla ssh przykładowo)

Napiszę jeszcze raz jak ja to rozumiem, może coś mylę, jak coś, to niech mnie ktoś poprawi.
Na komputerze liczącym mamy aplikację liczącą. Aplikacja ma swoje integralne GUI. Na
komputerze liczącym musi być zainstalowany cały soft biblioteczny z którego aplikacja
korzysta, a więc także soft odpowiedzialny za obsługę GUI. Być może biblioteki GUI są
dość duże i ciężkie, ale na pewno nie muszą zawierać sterowników kart graficznych,
monitorów itd. Zapewne biblioteka wyższego poziomu komunikuje się z biblioteką niższego
poziomu, aż w końcu na najniższym poziomie trzeba informacje o grafice przesłać do
x-servera. Więc na komputerze liczącym teoretycznie muszą być tylko biblioteki wszystkich
poziomów plus biblioteka do komunikowania się z x-serverem. Teoretycznie x-servera nie
trzeba instalować. Czy w praktyce spotyka się takie rozwiązania to zupełnie nie wiem. Takie
jest moje wyobrażenie, niech ktoś skoryguje :)

, ale wtedy z tego co zrozumiałem musiałbym być cały czas podłączony do hosta, który prowadzi obliczenia - wg mnie bez sensu.

Nie wiem czy teraz ja rozumiem. Na kilku serwerach mam X (tyle że akurat bardzo duże i ciężkie), uruchamiam tam programy GUI,
rozłączam się, a po ponownym połączeniu programy GUI nadal pracują. Na pewno nie muszę być cały czas połączony.

Nakładki faktycznie się pisze po to, żeby ułatwiały życie, ale nie jestem pewien statystyk ile z takowych korzysta.

Też nie mam reprezentatywnych danych, ale z tego co widzę, to korzysta się często. W firmach np. wymagają
aby używać GUI, uzasadniają że to przyspiesza pracę.

Poza tym weźmy dla przykładu phpMyAdmin - interfejs dla użytkowników MySQL, ale sam serwer potrafi się obyć bez tej nakładki

Rozumiem (z kontekstu) że nie chodzi o to, że potrafi się obyć, ale o to, że nakładki, bez względu czy mówimy o nakładkach GUI, konsolowych,
www, czy jeszcze jakiś innych, nie są jego integralną częścią lecz są aplikacjami zewnętrznymi. Owszem, masz rację, tak jest i w MySQL i w
wielu innych serwerach, nigdy nie twierdziłem inaczej.

i tak części rzeczy nie jest się w stanie zrobić z niego korzystając , co więcej może być na zupełnie innym serwerze (a sama aplikacja może obsłużyć wiele serwerów o ile wiem). Nie ma chyba oprogramowanie serwerowego, którego nakladka/interfejs graficzny miałby takie same możliwości co konsola/pliki konfiguracyjne.

Jakiej części rzeczy nie da się zrobić? Ma okienko do wpisywania poleceń sql. Polecenia
sql trafiają prosto do serwera bazy danych, tak samo jak trafiają z nakładki konsolowej.
Abstrahując od przykładu phpMyAdmin, generalnie możliwości zależą od tego, ile
pracy włożono w GUI, bez względu na to, czy GUI jest integralną częścią serwera, czy
też jest aplikacją zewnętrzną. Natomiast niepodważalną zaletą aplikacji konsolowych (ale
to powinni podać moi oponenci), jest prosta możliwość używaniach tychże aplikacji w
skryptach powłoki. Aplikacja GUI, aby dorównała i w tym względzie aplikacjom konsolowym,
musi oferować coś w zamian.

Kwestia priorytetów - zazwyczaj najpierw (pomijając oczywistości typu bezpieczeństwo i stabilność) stawia się na funkcjonalność, dopiero potem na łatwość obsługi dla nie-administratora (bo ten zapewne i tak nie skorzysta z okienek albo w bardzo ograniczonym stopniu) i  w takiej też kolejności się to rozwija. Jeśli się zauważa, że jakaś funkcja jest często wykorzystywana (a nie zawsze jest prosta w obsłudze składniowo przykładowo) to się dorabia do niej jakieś okienka/skrypty - ogólnie gotowce na typowe zastosowania.

No tak, ale jest BOINC, który uchybień funkcjonalnych ma całkiem mało. Natomiast ma trochę uchybień
w dokumentacji, spójności, ma kilka męczących wymagań (np. te nieszczęsne znaki \r). Gdy początkujący
na któryś z tych braków się natknie, to z kolei z powodu rozległości BOINC, nie wie, ani gdzie szukać
problemów, ani jak się doszkolić. Stąd właśnie moja eksplozja w kierunku wygody.

Co do priorytetów. Niestety priorytetem jest także w miarę mały nakład pracy. Rozbudowany projekt
nie doczeka swoich narodzin.

Ja nie mam nic przeciwko GUI, ale niech będzie opcją a nie koniecznością.

Jest kilka możliwości:
1) Program kompiluje się tylko GUI
2) Program kompiluje się tylko na konsolę
3) Kompilacja warunkowa na GUI albo konsolę
4) Kompilacja tylko na konsolę i zewnętrzna nakładka GUI na konsolę
5) Kompilacja tylko na konsolę i zewnętrzna nakładka TCP-IP.

Osobiście widzę najwięcej zalet w punkcie 3:
1) Są dwie aplikacje do wyboru
2) Mniej pracy niż przy punktach 4 i 5.
3) Zdecydowanie mniej pracy (niż w 4 i 5) dla innych programistów,
    którzy będą chcieli napisać niestandardową aplikację.
Wadą rozwiązania 3 (a także 4) jest to, że nie będzie można bezpośrednio-zdalnie
administrować serwerem. Będzie trzeba najpierw zalogować się przez ssh lub Xa.

Rodzi się niepokojące pytanie: ile czasu potrzeba na napisanie wg punktu 3?
Dwa lata dla jednego programisty?

Serwer Xów w ogóle jest dość specyficznym oprogramowaniem, bo to od razu dostarcza cały interfejs do obsługi (teoretycznie) każdego rodzaju urządzeń. Obecnie chyba ogranicza się go do sterowania kartą graficzną, myszą i klawiaturą ;) Możliwe, że ktoś napisze coś innego/lepszego, ale jak na razie "konkurencja" jest w powijakach.

W moim rozumieniu, X-server to tylko pośrednik. Pośredniczy pomiędzy tymi urządzeniami które wymieniasz i
aplikacją wykorzystującą  X-server. Za obsługę tych urządzeń odpowiadają sterowniki. Dlaczego zwracam
uwagę na tak drobiazgowe rozróżnienie? Ano właśnie dlatego, że może jednak używanie X nie oznacza
obciążania komputera.

Już nawet nie chodzi o sam serwer Xów (bo to raptem kilka mega - chociaż po co skoro i tak nikt by nie używał), ale musiałbyś do tego doinstalować cokolwiek co utrzymywałoby sesję graficzną, bo jak by się zachował program po zamknięciu sesji? Żeby cokolwiek znieść do tacki systemowej najpierw takowa musiałaby być, więc na serwerze musiałbyś zainstalować KDE, GNOME czy cokolwiek innego. A to dodatkowe komplikacje dla administratora i obciążenie dla serwera.

Co do sesji to chyba nie ma problemu, albo czegoś nie rozumiem. Natomiast masz rację, że tacka systemowa to element
ciężkich środowisk :/ To jest najlepszy argument przeciw zmuszaniu do GUI :/

No właśnie problem w tym, że jak na razie opisujesz coś co jest bardziej dedykowanym rozwiązaniem a nie takim "pod strzechy" (tutaj naprawdę duży cudzysłów). Oczywiście jest duża szansa, że znalazłaby się nisza zainteresowanych, ale to zupełnie inny target niż przykładowo BOINC - siłą rzeczy nie robiłbyś mu konkurencji

Więc jaki wniosek? Najlepsze rozwiązanie to takie, w którym i serwer, i klient może zostać skompilowany
warunkowo na aplikację GUI i/albo konsolową? Bo nakładki, choć są bardziej profesjonalne, to jednak
oznaczają większy nakład pracy?

Pozdrawiam

[krzyszp]

Myślę, że za bardzo odeszliście w teorię ;)

Mariotti - masz trochę inną wizję środowiska i mam (podobnie jak Karlik) opinię, że celujesz w trochę inną grupę docelową.
Spojrzyj na chwilę na BOINC - pomimo swoich wad (które my też zauważamy!) ma kilka sporych zalet:
1. Zintegrowane środowisko.
2. Wspólne API.
3. Wymaga exec'a, nie całej aplikacji z GUI, driverami, 100mln bibliotek do wyświetlenia tego - w zasadzie manager przejmuje sprawę wyświetlania "wodotrysków" typu pasek postępu, odnośniki.
4. Manager zarządza podziałem czasu CPU.
Najważniejsze:
99% aplikacji napisanych poprawnie może być po prostu cross-compilowane na inne systemy, co było by niemożliwe, gdyby aplikacja miała mieć GUI!!! Zauważ, że aplikacja radioaktywnego została uruchomiona na tunerze tv oraz routerze...

Niemniej, nie twierdzę ABSOLUTNIE, że Twoje podejście nie ma racji bytu - po prostu spróbuj, ja jestem pewien, że jest zapotrzebowanie i na takie rozwiązanie jak proponujesz, tylko to nie będzie zapewne kilka milionów komputerów (ale 10 tysięcy, czy 100tyś, czy nawet... 1 tysiąc to moim zdaniem powód do cholernej dumy).

Edit:

Tak sobie przeczytałem cały wątek i doszedłem do wniosku, że my chyba Mariotti'ego stopujemy przez nasze nawyki z BOINC... Może lepiej zwolnić i zobaczyć, co Mu wyjdzie? Może to będzie strzał w 10-tkę?

[mariotti]

Myślę, że za bardzo odeszliście w teorię ;)

Odeszliśmy, ale to chyba dobrze :)

Mariotti - masz trochę inną wizję środowiska i mam (podobnie jak Karlik) opinię, że celujesz w trochę inną grupę docelową.

Jest inaczej. Przestawiam Wam swoją wizję. Wy piszecie że to zadziała dla innej grypy docelowej. Z
kolei dla mnie to jest znak, że coś zaprojektowałem źle. Chcę aby grupa docelowa była zbliżona, więc
zmieniam niektóre założenia.

Spojrzyj na chwilę na BOINC - pomimo swoich wad (które my też zauważamy!) ma kilka sporych zalet:
1. Zintegrowane środowisko.

Co nazywasz zintegrowanym środowiskiem?

2. Wspólne API.

Tutaj mam mały zarzut: API jest w starym stylu. O wiele łatwiej programować w takim
API jak udostępnia Java, albo QT.

3. Wymaga exec'a, nie całej aplikacji z GUI, driverami, 100mln bibliotek do wyświetlenia tego - w zasadzie manager przejmuje sprawę wyświetlania "wodotrysków" typu pasek postępu, odnośniki.

Tutaj się zgadzam (co nie oznacza, że rozwiązanie o którym myślę, byłoby gorsze w tym względzie)

4. Manager zarządza podziałem czasu CPU.

Tutaj też wyszedł mały mankament: nie można ustawić tak żeby Perft optymalnie wykorzystywał zasoby.

Najważniejsze:
99% aplikacji napisanych poprawnie może być po prostu cross-compilowane na inne systemy, co było by niemożliwe, gdyby aplikacja miała mieć GUI!!! Zauważ, że aplikacja radioaktywnego została uruchomiona na tunerze tv oraz routerze...

Są rozwiązania przenośne z GUI. Właśnie owa Java albo C++ wraz z biblioteką QT.

Niemniej, nie twierdzę ABSOLUTNIE, że Twoje podejście nie ma racji bytu po prostu spróbuj, ja jestem pewien, że jest zapotrzebowanie i na takie rozwiązanie jak proponujesz, tylko to nie będzie zapewne kilka milionów komputerów (ale 10 tysięcy, czy 100tyś, czy nawet... 1 tysiąc to moim zdaniem powód do cholernej dumy).

Mój pogląd się wywrócił do góry nogami. Początkowo myślałem, że da się zrobić w około pół roku, ale bałem
się, że produkt nie będzie miał wzięcia. W tej rozmowie, choć myślałem że tylko będziecie protestować, to
także przedstawiliście mi kilka wad BOINC. Czyli zbiór wad dostrzeganych przeze mnie powiększył się.
W nowym produkcie można te wszystkie wady zniwelować. Z kolei to doprowadza mnie do wniosku, że
produkt byłby znacznie bardziej konkurencyjny niż początkowo myślałem. Jednak uświadomiliście mnie także, że
pewne rozwiązania na skróty nie zdadzą egzaminu. Teraz myślę że produkt miałby wzięcie, ale nie da
się go wykonać w wolne weekendy od niechcenia. Pół roku czasu przewiduję na samą dokumentację i aplikacje
przykładowe. Teraz myślę odwrotnie, produkt stałby się popularny, ale wymaga ogromnego nakładu pracy.

Edit:

Tak sobie przeczytałem cały wątek i doszedłem do wniosku, że my chyba Mariotti'ego stopujemy przez nasze nawyki z BOINC... Może lepiej zwolnić i zobaczyć, co Mu wyjdzie? Może to będzie strzał w 10-tkę?

Nie czuję się stopowany. W moim odczuciu odbyliśmy całkiem rzeczową rozmowę, a wcale nie chcę
przez to powiedzieć, że dobiegliśmy już do jej końca. Mój pogląd w tej chwili jest inny niż był na początku
rozmowy. Jestem teraz przekonany że produkt byłby strzałem w 10tkę, ale nie uda się go zrealizować,
ponieważ wymaga kolosalnego nakładu pracy.

Pozdrawiam