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

[mariotti]

Mam zaszczyt otworzyć dyskusję na temat zupełnie nowego frameworka do
obliczeń rozproszonych. Cel dyskusji można sformułować bardzo zwięźle, można
go sprowadzić do jednego prostego pytania: jakie powinien mieć cechy porządny
framework? Ogólnie chyba wiadomo:
1) Od strony liczydłowych powinien oferować elastyczną konfigurację i powinien
    być intuicyjny w obsłudze. Nasuwają się więc kolejne pytania: co to jest elastyczna
    konfiguracja i co to jest intuicyjna obsługa?
2) Od strony programisty powinien umożliwiać łatwe i szybkie postawienie aplikacji.
    Co to konkretnie oznacza? W mojej ocenie oznacza to dobrze udokumentowane API w
    dobrym języku programowania, np. w Javie lub C++.
3) Od strony twórcy samego frameworka powinien dać się wykonać i przetestować
    stosunkowo małym nakładem pracy - dla mnie to oznacza użycie dobrych "wspomagaczy",
    jakimi są  wysokopoziomowe biblioteki. Liderem tutaj jest QT wraz z C++ lub Java wraz ze
    swoimi natywnymi bibliotekami.

Wystarczy chwila zastanowienia, aby dojść do wniosku, że punkt 3, pomimo użycia wspomagaczy,
przeczy punktom 1 i 2. Na pewno nie da się zrealizować bardzo dobrego produktu małym
nakładem pracy.  Może więc należy zadać pytania trochę inaczej: jakie cechy taki framework
musi mieć, aby w ogóle mógł funkcjonować? Jakie cechy musiałby mieć, aby wydawał się
atrakcyjny względem innych frameworków? No i w końcu jakie powinien mieć, aby był idealny?

Punkty 2 i 3 są bardzo techniczne i w przybliżeniu znam na nie odpowiedzi - a przynajmniej tak
mi się wydaje. Głównie interesuje mnie punkt widzenia liczydłowego. Już w jednym z postów
wspomniałem o tym, jak kiedyś dawno temu liczyłem coś dla SETI. Zdaje się że wtedy jeszcze
nie istniał BOINC. W biurze stało sporo komputerów i od popołudnia do rana nikt z nich nie
korzystał. Opłatę za energię elektryczną mieliśmy w czynszu. Więc aż się prosiło, żeby cokolwiek
liczyć na tych komputerach. Wtedy nie miałem żadnej swojej aplikacji która wymagała
żmudnych obliczeń, więc mogliśmy liczyć coś charytatywnie.  Niestety szef nie rozumiał
tej idei, gdy przychodził rano i widział że wszystkie komputery całkiem nieźle ogrzewają
biuro, to wpadał w furię. Rozwiązaniem w takiej sytuacji byłoby automatyczne wyłączenie
komputerów na chwilę przed otwarciem biura.

Ciekawy jestem jak wyglądają wasze zmagania i problemy z charytatywnymi obliczeniami :D

Pozdrawiam

[Dario666]

Czy jest sens wyważać otwarte drzwi? Chodzi mi o to, że może łatwiej byłoby zmodyfikować istniejącego BOINCa niż tworzyć coś zupełnie od nowa.
Druga sprawa - jaki jest przybliżony nakład pracy, by stworzyć nowy framework i ile osób (programistów) by musiało w to wejść, by w jakimś realnym czasie go skończyć?
Trzecia sprawa, i najważniejsza, to kto by z niego skorzystał, bo tworzenie nowego frameworka dla 1 albo 2 projektów jest raczej mało sensowne. Jakie są perspektywy tego PROJEKTU...?

[andy101fah]

Zobacz jak są stworzone dwa największe projekty obliczeniowe oprócz BOINC.

folding@home oraz PRPNet . Folding wykorzystuje technologię  http://pl.wikipedia.org/wiki/MPICH

http://www.mpich.org/ gdzie możesz skalować wydajność używając dowolnej liczby core u użytkownika. Występują w folding@home 2 rodzaje klientów: konsolowy i graficzny z podziałem na uniprocesor i multi. Warto rozważyć stworzenie rozwiązań dla dwu grup użytkowników. Mocne maszyny multicore ściągają dedykowaną wersję klienta.

http://folding.stanford.edu/

http://www.primegrid.com/forum_thread.php?id=1215&nowrap=true#60642

http://uwin.mine.nu/PRPNet/

[mariotti]

Czy jest sens wyważać otwarte drzwi?

Nie mam pewności czy to naprawdę jest wyważanie otwartych drzwi?
Jakie są argumenty za i przeciw?

Mój pierwszy argument: BOINC jest trudny w administracji i w stawianiu aplikacji. Dowody:
1) mało jest polskich projektów;
2) mnie się nie udało drugi raz postawić testowej aplikacji, chociaż pierwszy raz działała;
3) na forum była wypowiedź, że droga do działającego boinca jest trudna i długa, a opcje
     zaawansowane mają tylko najlepsze projekty;

Chodzi mi o to, że może łatwiej byłoby zmodyfikować istniejącego BOINCa niż tworzyć coś zupełnie od nowa.

Tutaj mam trzy argumenty:
1) Słyszałem o programistach którzy siadają do nieznanego i słabo udokumentowanego kodu, a
    następnie od razu go przerabiają na swoje potrzeby, ale nigdy takiego programisty nie widziałem, nigdy z
    takim nie pracowałem. Zwykle, np. gdy napiszę jakiś kawałek kodu w celu ponownego użycia, to
    wciąż muszę wszystkim przypominać jak się go używa. Tak więc dla mnie taka możliwość istnieje
    tylko teoretycznie, albo tylko w przypadku łatwego/małego kodu.
2) Trudność używania BOINCa wynika z dwóch powodów:
     a) po pierwsze trzeba zgrać wiele oprogramowania zewnętrznego,
     b) API BOINC jest napisane w starym stylu, tak jak się programowało z 20 lat temu.
    Jeśli frame-work ma być głównie nastawiony na prostotę i szybkość stawiania projektów, to
    trzeba pozbyć się dwóch powyższych punktów. To oznacza usunięcie znacznej części kodu.
3) Absolutnie nic nie będzie stawiane od zera, nowy frame-work będzie oparty o masę
    gotowego kodu, prawdopodobnie o bibliotekę QT.
   

Druga sprawa - jaki jest przybliżony nakład pracy, by stworzyć nowy framework i ile osób (programistów) by
musiało w to wejść, by w jakimś realnym czasie go skończyć?

Z oszacowaniem nakładu pracy każdego większego projektu informatycznego są problemy.
Z tego co wiem, większość projektów pada, bo niedoszacowano nakład pracy. Kiedyś
dla kogoś już napisałem coś podobnego, ale znacznie prostszego. Był to zestaw oprogramowania
który zadania rozdzielał dla komputerów po sieci lokalnej. Nie robił absolutnie nic więcej niż
rozdzielanie zadań. Zajęło mi to... nie pamiętam już... może 3 dni, może tydzień.

Do tego projektu przysiadłem jak na razie na jakieś 2-4 dni. Mam już projekt bazy danych, sporo
ustawień z poziomu GUI, mam firewalla i jeszcze sporo innych drobiazgów. Wydaje się, że w 30 dni
takich "od zmierzchu do świtu", można zrobić coś więcej niż podstawowy framework. Będę mógł
pracować nad tym jakieś 2 dni w tygodniu i to nie tak intensywnie. Powiedzmy że 15-20 tygodni dla jednej
osoby, która ma inny ważniejszy projekt, a ten może realizować z doskoku. Najprostszy framework
pewnie by się dało zrobić w kilka dni roboczych, ale z najprostszego nikt by nie chciał korzystać.
Ale to są oszacowania, mogę się tutaj mocno mylić, mogą pojawić się jakieś problemy których teraz
nie przewidziałem.

Trzecia sprawa, i najważniejsza, to kto by z niego skorzystał, bo tworzenie nowego frameworka dla 1 albo 2 projektów jest raczej mało sensowne. Jakie są perspektywy tego PROJEKTU...?

To moja największa obawa. Być może nikt z niego nie skorzysta poza mną. Nie umiem
przewidzieć kto będzie chciał go używać. Czy można w ogóle to przewidzieć? Nie mam
miliona dolarów na reklamę produktu... albo chętni znajdą się sami, albo projekt będzie
leżał martwy gdzieś na moim dysku.

Pozdrawiam

[mariotti]

Zobacz jak są stworzone dwa największe projekty obliczeniowe oprócz BOINC.

Czas mnie goni, odpowiem na razie tylko na to. Nie chodzi o to, aby zrobić coś
podobnego do MPI. MPI to świetny i bardzo wydajny framework, w którym można
efektywnie rozwiązywać większą klasę zadań niż w BOINC, co z kolei jest obarczone
innymi wymogami, np. dużą dostępnością, jakością i niezawodnością sprzętu, dużym
nakładem pracy na bardzo specjalistyczną aplikację liczącą, itd.

W nowym frame-worku chodzi o to, żeby zrobić coś podobnego do BOINC. Zaraz powiecie
pewnie, że na BOINC też można tak efektywnie rozwiązywać dużą klasę zadań. Owszem można,
ale jeśli zależy nam na ekstremalnej wydajności i na ekstremalnym wykorzystaniu sprzętu, to
na MPI mamy gotowe wsparcie do tego celu.


Więc chodzi o zrobienie czegoś z idei podobnego do BOINC, ale żeby było znacznie
prostsze w używaniu. Czyli standardowy, wręcz łopatologiczny schemat:
1) rozbijamy zadanie na pod-zadania,
2) pod-zadania zapisujemy na dysku serwera,
3) klienty otrzymują pod-zadania i liczą,
4) klienty odsyłają wyniki.
Oczywiście im więcej opcji wspomagających ten tym lepiej, ale zasadniczy
schemat ma być taki prosty. Jakby ktoś chciał zrobić zaawansowaną komunikację
pomiędzy aplikacjami liczącymi, to ten frame-work nie będzie się nadawał.

Wbrew pozorom, opcji wspomagających do takiego prostego schematu może
być baaardzo dużo.

Pozdrawiam

[krzyszp]

Po pierwsze zauważę, że nie chcę Cię zniechęcać - w końcu nic by nie powstało, jak by ktoś się nie uparł :)

W zasadzie idea przyświeca Ci szczytna, ale weź pod uwagę, że wszystkie opcje jakie są do wykorzystania na platformie BOINC powstały z jednego powodu - ktoś ich potrzebował.
Zgadzam się, że ogarnięcie serwera może być b. trudne, ale czy dla Ciebie nie jest przeszkodą właśnie to, że nie masz w niej praktyki? Wiem, że miałeś (masz) dużo problemów z wystartowaniem, teraz nie wiesz, dlaczego zadania się nie wysyłają, ale czy zadałeś sobie trud zapytania na liście dyskusyjnej developerów BOINC? Pisałem także, abyś zajrzał na IRC, praktycznie stale rezyduje tam TJM, jest również Rysiu - obydwaj postawili swoje serwery, a TJM ma wieloletnią już praktykę w administrowaniu dwoma serwerami (Enigma@Home i Radioactive@Home).

Dalej. Prosty framework nie będzie uniwersalny, to po prostu nie idzie w parze. Jeżeli ma to iść do ludzi, to pomyślałeś o walidacji wyników? Eksporcie statystyk? Obronie przed cheaterami?
Wiem, jestem upierdliwy :)

Niemniej, jeśli czujesz się na siłach, to pisz framework, najlepiej jako Open Source - może więcej programistów się przyłączy i Ci pomoże?

A teraz to, co mi brakuje w BOINC:
1. Większa kontrola nad wykonywanymi zadaniami. Poza przydzieleniem priorytetu lub liczby rdzeni/wątków nie mogę właściwie wymusić równoczesnego działania np. WCG i Enigma na jednym kompie. Wiem, mogę ręcznie pauzować itd, ale ja bym chciał jednak mieć nad tym większą kontrolę.
2. Praca w piaskownicy. Chodzi mi o to, aby każda próbka była w niej odpalana i abym miał możliwość (łatwą, z poziomu managera) np. zabronić jej komunikacji z siecią.
3. Komunikacja zza NAT. Mam 2-3 kompy w lokalizacjach, gdzie nie mogę przekierować portów ani zainstalować żadnego softu typu logmein, vpn. Dobrze, aby manager komunikować się np. za pomocą P2P.

To są chyba największe (z mojego punktu widzenia) braki w BOINC...

[mariotti]

Po pierwsze zauważę, że nie chcę Cię zniechęcać - w końcu nic by nie powstało, jak by ktoś się nie uparł :)

Potrzebuję dobrych argumentów, potrzebuję ich zwłaszcza z tych obszarów, które słabo rozumiem.  W sumie
drugorzędną sprawą jest czy one zachęcają czy zniechęcają. Potrzebny jest materiał do podjęcia
racjonalnej decyzji.

W zasadzie idea przyświeca Ci szczytna, ale weź pod uwagę, że wszystkie opcje jakie są do wykorzystania na platformie BOINC powstały z
jednego powodu - ktoś ich potrzebował.

Z pewnością tak.

Zgadzam się, że ogarnięcie serwera może być b. trudne, ale czy dla Ciebie nie jest przeszkodą
właśnie to, że nie masz w niej praktyki?

Tak, to jest przeszkodą. Jeśli za pół roku będę już miał praktykę, to (z małym wyjątkiem) powinienem
skupić się na BOINC. Natomiast jeśli za pół roku nadal będę osobą bez praktyki, to chyba lepiej
napisać nowy. A ten mały wyjątek jest taki, że lepiej będzie można przydzielać zasoby dla aplikacji
liczącej, nawet w pierwszych wersjach frameworka. To z kolei jest ważne dla projektu perft.

Kiedyś pytałem już, ile innym osobom zajęło stawianie aplikacji na BOINC, ale
nie otrzymałem odpowiedzi. Może ma ktoś takie dane?

Wiem, że miałeś (masz) dużo problemów z wystartowaniem, teraz nie wiesz, dlaczego zadania się nie wysyłają, ale czy zadałeś sobie trud zapytania na liście dyskusyjnej developerów BOINC?

Po polsku jest trudno opisać problem, głównie z powodu ogromnej ilości szczegółów, więc po angielsku nie
mam najmniejszych szans na porozumienie.

Pisałem także, abyś zajrzał na IRC, praktycznie stale rezyduje tam TJM, jest również Rysiu - obydwaj postawili swoje serwery, a TJM ma wieloletnią już praktykę w administrowaniu dwoma serwerami (Enigma@Home i Radioactive@Home).

Nie sądzę żeby ktokolwiek powiedział w czym tkwi problem. Ktoś by musiał zwyczajnie usiąść przy
tym, testować kawałek po kawałku, aby w końcu naprawić. Ale... ja to stawiałem od zera i uruchamiam
aplikację przykładową. Nie mieści mi się w głowie, że na takim początkowym etapie może coś nie działać.

Dalej. Prosty framework nie będzie uniwersalny, to po prostu nie idzie w parze.

Inaczej. Będzie z góry ustalona funkcjonalność. Ponadto w kolejnych wersjach ta
funkcjonalność może się zwiększać. Jeśli dla jakieś aplikacji funkcjonalność oferowana
przez framework nie wystarczy, to developer musi szukać czegoś innego, ten się
po prostu nie będzie nadawał. Natomiast jeśli wystarczy, to może go używać.

Z kolei gdy piszę o prostocie, to mam na myśli prostotę używania, pisania aplikacji liczących,
aplikacji serwerowych, itd. Chodzi o to, aby dla pewnej funkcjonalności zbudować ekstremalnie
proste w użyciu narzędzie. Dobrze jakby poza prostotą były to także narzędzia wydaje - ale
to cel drugorzędny.

Jeżeli ma to iść do ludzi, to pomyślałeś o walidacji wyników? Eksporcie statystyk? Obronie przed cheaterami?

Tak, pomyślałem o tym i jeszcze o kilku innych fajnych rzeczach. Boję się tego o czym już wspominałem: że źle
oszacowuję czas pracy, a także tego, że nawet jak narzędzia będą dobrze zrobione, to nie zdołam nikogo
zainteresować.

Wiem, jestem upierdliwy :)

W sumie o to też mi chodzi, chcę usłyszeć że coś jest problematyczne i sobie nie poradzę.

Niemniej, jeśli czujesz się na siłach, to pisz framework, najlepiej jako Open Source - może więcej programistów się przyłączy i Ci pomoże?

Myślałem o specyficznej licencji. Na pewno open-source. Do zastosowań małych-komercyjnych i dowolnych niekomercyjnych byłoby
wszystko za darmo, z drobnym wyjątkiem. Ten wyjątek to prawo do zmodyfikowanego kodu frame-worka (nie własnej aplikacji). Jakby ktoś
np. poprawił błąd w kodzie, to by musiał przekazać nieodpłatnie wszelkie prawa "pierwotnym" autorom. W sumie podobnie do LGPL. O
ile nie mylę, w LGPL prawa do modyfikacji spływają na wszystkich, a tutaj by spływały na pierwotną grupę twórców, niemniej wszyscy tak
samo jak w LGPL mogliby korzystać z modyfikacji.

A teraz to, co mi brakuje w BOINC:
1. Większa kontrola nad wykonywanymi zadaniami. Poza przydzieleniem priorytetu lub liczby rdzeni/wątków nie mogę właściwie wymusić równoczesnego działania np. WCG i Enigma na jednym kompie. Wiem, mogę ręcznie pauzować itd, ale ja bym chciał jednak mieć nad tym większą kontrolę.

To będzie z automatu. Będzie się ściągało tyle zadań ile będzie się chciało i każdemu się ustawi dowolną ilość
wątków, pamięci, itd. Oczywiście wszystko w granicach minimum i maksimum jakie dana aplikacja licząca
umie obsłużyć.

2. Praca w piaskownicy. Chodzi mi o to, aby każda próbka była w niej odpalana i abym miał możliwość (łatwą, z poziomu managera) np. zabronić jej komunikacji z siecią.

Nie rozumiem. Co to jest piaskownica?

3. Komunikacja zza NAT. Mam 2-3 kompy w lokalizacjach, gdzie nie mogę przekierować portów ani zainstalować żadnego softu typu logmein, vpn. Dobrze, aby manager komunikować się np. za pomocą P2P.

Gdy aplikacja jest za maskaradą, to (poza jakimś ograniczonym obszarem, np. sieć lokalna) nie widać że nasłuchuje na
porcie. Gdy tego nie widać, to manager z poza danego obszaru nie może się z nią połączyć. Jedyne rozwiązanie dla
aplikacji nasłuchujących to właśnie przekierowanie portu. Gdy portu nie można przekierować, to trzeba poszukać
jakiegoś innego rozwiązania. Przykładem może być manager który słucha na porcie, a aplikacje liczące np. co 60s
mogą próbować się z nim połączyć. Niestety wtedy są inne problemy: manager musi być widoczny, manager musi być
uruchomiony na jednym z określonych IP, a aplikacje klienckie obciążają komputer gdy ciągle próbują się łączyć. Można
też zrobić klienta poczty w aplikacjach klienckich. Aplikacja kliencka co jakiś czas odbierze pocztę i sprawdzi czy nie
ma dla niej poleceń. Oczywiście takie bajery wymagają sporo pracy i dokładnego przemyślenia, więc w początkowych
wersjach na pewno ich nie będzie, ale docelowo... jakby framework stał się popularny, to bardzo chętnie.

To są chyba największe (z mojego punktu widzenia) braki w BOINC...

Dzięki i pozdrawiam.

[krzyszp]

1. Piaskownica (sandbox) polega na uruchomieniu aplikacji klienckiej w wydzielonym środowisku, aby nie miała ona możliwości "mieszać w systemie".
2. Pisałem o komunikacji P2P z managerem, coś na kształt dawnego skype, który działa doskonale za maskaradą.
3. Czas potrzebny na postawienie aplikacji pod serwer w najprostszym wydaniu = czas pisania normalnego programu + wstawienie 4-5 linijek do kodu (c++). Pierwsze wersje kodu radioaktywnego tak działały (i działały ;)).
4. Temat listy dyskusyjnej jest pewnie nie do przejścia, dzisiaj niestety pewna znajomość angielskiego jest po prostu konieczna :/
5. Co do osiągnięcia praktyki z serwerem... Pewnego dnia gdy coś napisałeś na forum (nieistotne co), Rysiu usiadł do postawienia serwera "na czas", zajęło mu to kilkanaście minut... (ja utknąłem w jednym miejscu, ale nie chciało mi się już po prostu). Myślę, że powinieneś najpierw sobie dokładnie przestudiować jak to działa po stronie klienta (manager + różne projekty). Założę się, że w Twoim projekcie przydatne by mogło być użycie np "trickles", które występują w radioaktywnym...

Przepraszam, że tak punktuje, ale trochę się spieszę pisząc posta i nie chciałem się rozwodzić...

[mariotti]

1. Piaskownica (sandbox) polega na uruchomieniu aplikacji klienckiej w wydzielonym środowisku, aby nie miała ona możliwości "mieszać w systemie".

Po stronie klienta będzie zwykła-sieciowa aplikacja,  raczej nie powinna stwarzać jakiś
szczególnych problemów.

2. Pisałem o komunikacji P2P z managerem, coś na kształt dawnego skype, który działa doskonale za maskaradą.

Jeden z programów musi nasłuchiwać na gniazdku widocznym w sieci rozległej. Jeśli oba są za maskaradą, to
musi być jakiś trzeci program pośredniczący. Pewnie jakoś tak to w skypie bylo rozwiązane. Tak czy inaczej,
jest to do zrobienia, ale dość pracochłonne.

3. Czas potrzebny na postawienie aplikacji pod serwer w najprostszym wydaniu = czas pisania normalnego programu + wstawienie 4-5 linijek do kodu (c++). Pierwsze wersje kodu radioaktywnego tak działały (i działały ;)).

Ale chodziło mi o osobę która nie umie, czyli jeszcze plus czas nauki :)

5. Co do osiągnięcia praktyki z serwerem... Pewnego dnia gdy coś napisałeś na forum (nieistotne co), Rysiu usiadł do postawienia serwera "na czas", zajęło mu to kilkanaście minut... (ja utknąłem w jednym miejscu, ale nie chciało mi się już po prostu). Myślę, że powinieneś najpierw sobie dokładnie przestudiować jak to działa po stronie klienta (manager + różne projekty). Założę się, że w Twoim projekcie przydatne by mogło być użycie np "trickles", które występują w radioaktywnym...

Teraz na sformatowanym dysku wraz z kompilacją, instalacją baz danych, serwerów, konfiguracją apache, podpinaniem
sub-domen, dodaniem testowych aplikacji i testowych work-units w jeden dzień bym postawił. Gdy na systemie wcześniej
był już BOINC, to w 15 minut można zrobić spokojnie. Tyle że po postawieniu wszystko dziwnie się zachowuje, np. samo
zaczyna działać bez żadnej mojej poprawki.

Pozdrawiam

[mariotti]

http://www.mpich.org/ gdzie możesz skalować wydajność używając dowolnej liczby core u użytkownika.

Myślałem nad innym rozwiązaniem tego problemu. W jednej aplikacji liczącej programista zaszyłby
tyle wersji ile by uznał za sensowne. Można napisać jedną wersję skalującą, albo osobne na
każdą ilość wątków.  Użytkownik w ustawieniach widziałby minimalne i maksymalne zasoby
na jakich aplikacja umie pracować. Następnie użytkownik ustawiałby ilość pamięci, wątków,
szybkość łącza, rozmiar przestrzeni dyskowej, itd. Aplikacja na starcie otrzymałaby te
ustawienia, dostosowała się i prowadziłaby obliczenia.

Występują w folding@home 2 rodzaje klientów: konsolowy i graficzny z podziałem na uniprocesor i multi. Warto rozważyć stworzenie rozwiązań dla dwu grup użytkowników. Mocne maszyny multicore ściągają dedykowaną wersję klienta.

Podział na konsolę i GUI jak najbardziej tak. Jedni użytkownicy będą chcieli coś pobrać, kliknąć i się
nie martwić, albo oglądać ładny wygaszacz ekranu. Inni będą mogli liczyć gdzieś na jakimś routerze bez
GUI. Podziału na mocne komputery i słabe bym nie robił. Mniej wersji oznacza mniej kłopotów dla
użytkowników. Ponadto takie rozwiązanie zachęca do pisania aplikacji dostosowujących się do
dostępnych zasobów. Perft jest właśnie tak napisany i jest mi trochę smutno, że na BOINCu z
Perfta nie wyciśnie się wszystkich możliwości.

http://folding.stanford.edu/
http://www.primegrid.com/forum_thread.php?id=1215&nowrap=true#60642
http://uwin.mine.nu/PRPNet/

Dzięki za linki, ale to wszystko jakieś bardzo zaawansowane rozwiązania :) Ja myślę o
czymś prostym, takim jak BOINC, ale bez sytuacji, gdy w bazie są zadania, a klient
twierdzi że ich nie ma, albo brak mu miejsca na dysku, bo nie umie wczytać XMLa :)

Pozdrawiam

[goofyx]

A ja uważam, że boinc w tej chwili jest sporo przerośnięty przez co jest skomplikowany dla zwykłych śmiertelników.

Co tak naprawdę jest potrzebne aby ruszyć z obliczaniem rozproszonym:
1. serwer:
a) obsługa komunikacji <- wysyłka i odbiór WU
b) pilnowanie WU <- w tej chwili trzeba tworzyć skrypty i je pilnować. Nowy "framework" może mieć obsługę uruchamiania zewnętrznych exeków odpowiedzialnych za poszczególne zadania np.: generowania, przetwarzania  WU
c) obsługa bazy danych <- boinc preferuje MySql <- gdyby wykorzystać odpowiednie biblioteki to można obsłużyć minimum 5 różnych silników

2. klient:
a) obsługa komunikacji <- wysyłka i odbiór WU
b) przeliczanie WU czyli uruchamianie zewnętrznego exeka który przeliczy WU


Teoretycznie najprostszego miniBoinca można zrobić w tydzień przy pracy wieczorkami przez 2 programistów <- i co najlepsze każdy będzie mógł go zainstalować bez tajemnej wiedzy tka jak teraz. W tej chwili niektórzy mogą powiedzieć, że nie trzeba być geniuszem aby postawić serwer boinca <- powiedzmy sobie szczerze 75% ludzi na ziemi jest kompletnie zielona z linuksa. Może nie jestem wyznacznikiem całości, ale ja osobiście próbowałem kilkanaście różnych tutoriali i serwer postawiłem tylko raz, ale za holere nie wiem jakim cudem <- a raczej nie o to chodzi.

Gdyby się okazało, że coś takiego ma "branie" to można by się pokusić oto aby taki serwer obsługiwał Boinc Managera <- w końcu komunikacja serwer-manager odbywa się poprzez xml jak dobrze pamiętam

[krzyszp]

Zapominacie o "pierdołach" jak np. dlaczego preferowany jest MySQL?
Bo jest Open Source, bo jest w każdej dystrybucji Linuksa.

Niedawno zostałem zapytany, dlaczego nie oferuję swojego softu pod MSSQL... Podałem kwotę licencji i ograniczenia. Klient zrezygnował...
Naprawdę ludzie od BOINC myśleli, zanim jakieś rozwiązanie wprowadzili, a że jest trudne? Przepraszam, ale za obliczenia nie bierze się "Basia z księgowości" ;)
Przecież jak komuś bardzo zależy na wynikach, to zawsze może poprosić kogoś "kumatego" o postawienie serwera, prawda?

[goofyx]

Zapominacie o "pierdołach" jak np. dlaczego preferowany jest MySQL?
Bo jest Open Source, bo jest w każdej dystrybucji Linuksa.

Niedawno zostałem zapytany, dlaczego nie oferuję swojego softu pod MSSQL... Podałem kwotę licencji i ograniczenia. Klient zrezygnował...
Naprawdę ludzie od BOINC myśleli, zanim jakieś rozwiązanie wprowadzili, a że jest trudne? Przepraszam, ale za obliczenia nie bierze się "Basia z księgowości" ;)
Przecież jak komuś bardzo zależy na wynikach, to zawsze może poprosić kogoś "kumatego" o postawienie serwera, prawda?

ad <- 1
Firebird też jest open source ;)

ad <- 2
no ok, ale dlaczego pani Basia nie mogłaby pobawić się serwerem boinc? co by to szkodziło?
Tylko mi nie pisz że wtedy powstałoby setki śmieciowych projektów! <- jak uważasz że śmieć to nie liczysz i koniec gadania.

ad <- 3
baardzo mnie zależało i przez 3 lata prosiłem i błagałem kumatych ludzi i co.... minęło 3 lata a kumaci dalej nie pomogli <- niestety moja wiedza linuksowa jest bardzo uboga i choć bardzo bym chciał to nie mogę sobie pozwolić aby np.: tydzień siedzieć i grzebać w systemie aby uruchomić serwer boinc. 

ad <- 4
Ja nikomu nie ubliżam, ale ludzie od boinca to myśleli chyba o tym aby strona techniczna boinca była przewidziana tylko dla wybrańców

[krzyszp]

ad <- 1
Firebird też jest open source ;)

Ale wymięka w temacie skalowalności...

ad <- 2
no ok, ale dlaczego pani Basia nie mogłaby pobawić się serwerem boinc? co by to szkodziło?
Tylko mi nie pisz że wtedy powstałoby setki śmieciowych projektów! <- jak uważasz że śmieć to nie liczysz i koniec gadania.

Typowa pani Basia raczej nie napisze softu do Weird numbers (np.) ;)
Ale ok., uznaje argument...

ad <- 3
baardzo mnie zależało i przez 3 lata prosiłem i błagałem kumatych ludzi i co.... minęło 3 lata a kumaci dalej nie pomogli <- niestety moja wiedza linuksowa jest bardzo uboga i choć bardzo bym chciał to nie mogę sobie pozwolić aby np.: tydzień siedzieć i grzebać w systemie aby uruchomić serwer boinc. 

Sorry goofyx, ale jak byś poświęcił 6 miesięcy na nauczenie się różnić pomiędzy Win i Lin, to byś postawił...
Wiem, że Linux potrafi ludziom sprawić kłopoty, ale wg mnie to kwestia "przestawienia się", co jednym przychodzi łatwiej, a innym trudniej.
Inna sprawa - uważasz, że tydzień, to długo? Przy uwzględnieniu, że platforma daje Ci moc, która zaoszczędzi LATA???

ad <- 4
Ja nikomu nie ubliżam, ale ludzie od boinca to myśleli chyba o tym aby strona techniczna boinca była przewidziana tylko dla wybrańców

Nie, nie tylko. Ale jest tak uniwersalna, że wymaga jednak nauki.
Albo dostajemy klikalną zabawkę, albo platformę z potężnymi możliwościami... Zobacz, jak różne problemy są rozwiązywane pod BOINC...

Ok, nie twierdzę, że BOINC jest remedium na całe zło, twierdzę, że to w tej chwili najlepsze narzędzie w swojej klasie. A że działa pod Linuksem, a nie pod Windows, że nie ma kreatorów i pierdyliarda opcji w menu?
Nie ma... Kropka... Może mariotti po prostu zrobi lepszy framework? A może zrobi to ktoś inny? Nie wiem...

[Karlik]

Tak teraz sobie przypomniałem o jeszcze jednym sposobie na zrobienie "przetwarzania rozproszonego". Jak miałbyś chwilkę czasu to rzuć okiem na Test4Theory, ale na to co jest w środku (a nie to, że korzysta z maszyny wirtualnej). O ile dobrze pamiętam to przydział zadań i cała komunikacja jest oparta o XMPP. Nawet kompilację pliku wykonywalnego przed rozpocząciem obliczeń robi(ł) ;)
Jeżeli chodzi o MySQL to ja osobiście preferuję PostgreSQL.
Zgadzam się w ogólności  z ideą sandboxingu - właśnie przez to, że to będzie aplikacja sieciowa to powinno się zwracać uwagę na oddzielenie aplikacji od całego systemu.
A PRPNet wcale nie jest jakiś super zaawansowany czy skomplikowany, po prostu: pobiera zadanie, uruchamia przypisaną aplikację z pobranymi danymi wejściowymi, wysyła wyniki, pobiera kolejne zadanie... O ile się nie mylę to aplikacje liczące w ogóle z żadnego API (związanego z przetwarzaniem rozproszonym) nie korzystają.

[goofyx]

ad <- 3
baardzo mnie zależało i przez 3 lata prosiłem i błagałem kumatych ludzi i co.... minęło 3 lata a kumaci dalej nie pomogli <- niestety moja wiedza linuksowa jest bardzo uboga i choć bardzo bym chciał to nie mogę sobie pozwolić aby np.: tydzień siedzieć i grzebać w systemie aby uruchomić serwer boinc. 

Sorry goofyx, ale jak byś poświęcił 6 miesięcy na nauczenie się różnić pomiędzy Win i Lin, to byś postawił...
Wiem, że Linux potrafi ludziom sprawić kłopoty, ale wg mnie to kwestia "przestawienia się", co jednym przychodzi łatwiej, a innym trudniej.
Inna sprawa - uważasz, że tydzień, to długo? Przy uwzględnieniu, że platforma daje Ci moc, która zaoszczędzi LATA???

Tydzień jako taki to nie dużo <- ale nie mogę sobie pozwolić na taką przerwę w pracy :(
Co zapewne zaraz obrócisz jako argument i komentarz, że gdybym chciał to bym mógł.
Szkoda tylko, że B@P nie było mi wstanie pomóc przez lata, a PNT pomogło w 1,5 miesiąca.

[krzyszp]

ad <- 3
baardzo mnie zależało i przez 3 lata prosiłem i błagałem kumatych ludzi i co.... minęło 3 lata a kumaci dalej nie pomogli <- niestety moja wiedza linuksowa jest bardzo uboga i choć bardzo bym chciał to nie mogę sobie pozwolić aby np.: tydzień siedzieć i grzebać w systemie aby uruchomić serwer boinc. 

Sorry goofyx, ale jak byś poświęcił 6 miesięcy na nauczenie się różnić pomiędzy Win i Lin, to byś postawił...
Wiem, że Linux potrafi ludziom sprawić kłopoty, ale wg mnie to kwestia "przestawienia się", co jednym przychodzi łatwiej, a innym trudniej.
Inna sprawa - uważasz, że tydzień, to długo? Przy uwzględnieniu, że platforma daje Ci moc, która zaoszczędzi LATA???

Tydzień jako taki to nie dużo <- ale nie mogę sobie pozwolić na taką przerwę w pracy :(
Co zapewne zaraz obrócisz jako argument i komentarz, że gdybym chciał to bym mógł.
Szkoda tylko, że B@P nie było mi wstanie pomóc przez lata, a PNT pomogło w 1,5 miesiąca.

Nie będę obracał ;)
To Twój wybór i Twój projekt. Nie wiem tylko, dokładnie o czym piszemy (w kwestii pomocy), bo chyba nie postawiłeś serwera BOINC?

Ale czy my nie odbiegamy za bardzo w off-top?

[mariotti]

A ja uważam, że boinc w tej chwili jest sporo przerośnięty przez co jest skomplikowany dla zwykłych śmiertelników.

Chyba mam odmienne zdanie, chociaż nie jestem do końca pewny jak używasz określenia
"przerośnięty". W sumie ja nie widzę żeby było w BOINCu czegoś za dużo, albo czegoś
za mało. Moim zdaniem jest to oprogramowanie stworzone do rozwiązywania dobrze wydzielonej
klasy zadań, a właściwie do dobrze wydzielonej klasy sposobów rozwiązywania zadań.

Osobiście problemy widzę w czym innym.

1) Po pierwsze BOINC powstał dawno temu, na bazie oprogramowania które powstało jeszcze dawniej.
W dodatku większość kodu wygląd tak, jakby napisali go programiści, którzy programowali w
stylu jeszcze starszym niż data powstania BOINCa. Od tamtej pory powstało wiele mechanizmów
ułatwiających proces tworzenia aplikacji, a BOINC z nich nie korzysta.

2) BOINC był łatany, to oprogramowanie początkowo powstało do jednego konkretnego
projektu. Takie łatanie (czasami) jest nawet szybkim sposobem na zrobienie softu, ale
całość jako projekt robi się trudna do ogarnięcia i dalszego rozwijania.

3) BOINC ma różne braki i są z nim różne dziwne kłopoty których nie powinno być w
oprogramowaniu dla mas. Przykładem jest głupi znak \r, który raz w pliku XML może być,
BOINC dodaje zadania do bazy i znak \r mu nie przeszkadza, ale potem ogólnie nie pracuje.
Innym brakiem są raporty o błędach. Raporty często są nietrafione albo niepotrzebne. W
plikach logów są megabajty sieczki przez które strasznie ciężko się przekopać. Ostatnio
wszyscy widzieli, że pokazywał błędy o braku miejsca na dysku, a problemem było zupełnie
co innego.

4) BOINC korzysta z wielu różnych bibliotek i programów zewnętrznych. Wystarczy że
jest problem z jedną biblioteką i całość leży. Dziś całą aplikację można napisać w
oparciu o trzy składniki: baza danych, biblioteka, język programowania. Programista
musiałby zadbać o konfigurację tylko tych trzech rzecz. Konkretnie może to być
PostgreSQL, QT i C++; albo MySQL i Java ze swoimi natywnymi bibliotekami.

5) Konfiguracja przydziału zasobów po stronie komputera liczącego jest przestarzała.
Dobra była, gdy 99% mocy obliczeniowej pochodziło z komputerów jednordzeniowych. Komputery
wielordzeniowe już dawno trafiły pod strzechy. Ten brak dowodzi trudności w rozwijaniu,
inaczej ktoś by to napisał porządnie kilka lat temu.

Co tak naprawdę jest potrzebne aby ruszyć z obliczaniem rozproszonym:
1. serwer:
a) obsługa komunikacji <- wysyłka i odbiór WU
b) pilnowanie WU <- w tej chwili trzeba tworzyć skrypty i je pilnować. Nowy "framework" może mieć obsługę uruchamiania zewnętrznych exeków odpowiedzialnych za poszczególne zadania np.: generowania, przetwarzania  WU
c) obsługa bazy danych <- boinc preferuje MySql <- gdyby wykorzystać odpowiednie biblioteki to można obsłużyć minimum 5 różnych silników

2. klient:
a) obsługa komunikacji <- wysyłka i odbiór WU
b) przeliczanie WU czyli uruchamianie zewnętrznego exeka który przeliczy WU

Co jest potrzebne żeby ruszyć... Masz rację że niewiele. Perft ruszyłby naprawdę
na prościutkim frameworku, ale nie chodzi oto, aby framework nadawał się tylko do
Perfta.

Najpierw trzeba ustalić, do czego taki framework bedzie się nadawał, a do czego nie.
Podstawowy schemat jest taki:
1) Dzielimy zadanie na pod-zadania (statycznie albo dynamicznie)
2) Pod zadania zamieszczamy na jednym lub wielu serwerach
3) Klient łączy się z losowym serwerem i pobiera dane (czyli pod zadanie)
4) Uruchamiają się obliczenia na danych
5) Wynik jest odsyłany do serwera.
Ten prosty schemat w przyszłości będzie można rozszerzyć o komunikację pomiędzy
klientami bez pośrednictwa serwera.

Teoretycznie najprostszego miniBoinca można zrobić w tydzień przy pracy wieczorkami przez 2 programistów <- i co najlepsze każdy będzie mógł go zainstalować bez tajemnej wiedzy tka jak teraz.

Myślałem o czymś trochę więcej niż minimum.
1) Użytkownicy, tworzenie kont, logowanie, ranking w obliczeniach.
2) Optymalizacja transferu, bufor powtarzających się plików po stronie klienta.
3) Szyfrowana i kompresowana transmisja po SSL.
4) Zadania w transakcyjnej bazie danych, 100% odporności pady zasilania, itd.
5) Klonowanie serwerów, jeśli zadanie jest zbyt duże, to stawiamy nową skrzynkę i
   pod-zadania pakujemy do dwóch komputerów
6) Wewnętrzny fire-wall żeby ktoś mógł ograniczyć obliczenia tylko do prywatnych komputerów
7) Aplikacja webowa do prezentacji postępów, rankingu, itd
8) Jednolite API w postaci funkcji wirtualnych
9) Wygodne narzędzia do administrowania serwerem.
10) Wszelkie opcje na limity zadań dla jednego usera, na czas przedawnienia,
    weryfikację, itd.
11) Może dodatkowy server, specjalny do zarządzania wieloma klientami gdy są
    za maskaradą.

W tej chwili niektórzy mogą powiedzieć, że nie trzeba być geniuszem aby postawić serwer boinca <- powiedzmy sobie szczerze 75% ludzi na ziemi jest kompletnie zielona z linuksa. Może nie jestem wyznacznikiem całości, ale ja osobiście próbowałem kilkanaście różnych tutoriali i serwer postawiłem tylko raz, ale za holere nie wiem jakim cudem <- a raczej nie o to chodzi.

Mam podobne problemy :)

Gdyby się okazało, że coś takiego ma "branie" to można by się pokusić oto aby taki serwer obsługiwał Boinc Managera <- w końcu komunikacja serwer-manager odbywa się poprzez xml jak dobrze pamiętam

Myślę żeby na serwer składał się jeden program GUI, prosta aplikacja webowa i nic więcej. Niestety
rozwiązanie takie ma wadę: zmusza do instalowania jakiegoś środowiska graficznego na serwerze. Wydaje
się jednak, że zalety są ważniejsze:
1) nie trzeba pisać managera, bo załatwi to zdalny x-server
2) dużo łatwiej napisać jedną aplikację, niż dwie: server i manager


Pozdrawiam

[goofyx]

Moim zdaniem jest to oprogramowanie stworzone do rozwiązywania dobrze wydzielonej
klasy zadań, a właściwie do dobrze wydzielonej klasy sposobów rozwiązywania zadań.

W jakim sensie "dobrze wydzielonej klasy zadań" skoro możesz odpalić na boinc praktycznie każdy projekt.

Osobiście problemy widzę w czym innym.

1) Po pierwsze BOINC powstał dawno temu, na bazie oprogramowania które powstało jeszcze dawniej.
W dodatku większość kodu wygląd tak, jakby napisali go programiści, którzy programowali w
stylu jeszcze starszym niż data powstania BOINCa. Od tamtej pory powstało wiele mechanizmów
ułatwiających proces tworzenia aplikacji, a BOINC z nich nie korzysta.

2) BOINC był łatany, to oprogramowanie początkowo powstało do jednego konkretnego
projektu. Takie łatanie (czasami) jest nawet szybkim sposobem na zrobienie softu, ale
całość jako projekt robi się trudna do ogarnięcia i dalszego rozwijania.

3) BOINC ma różne braki i są z nim różne dziwne kłopoty których nie powinno być w
oprogramowaniu dla mas. Przykładem jest głupi znak \r, który raz w pliku XML może być,
BOINC dodaje zadania do bazy i znak \r mu nie przeszkadza, ale potem ogólnie nie pracuje.
Innym brakiem są raporty o błędach. Raporty często są nietrafione albo niepotrzebne. W
plikach logów są megabajty sieczki przez które strasznie ciężko się przekopać. Ostatnio
wszyscy widzieli, że pokazywał błędy o braku miejsca na dysku, a problemem było zupełnie
co innego.

4) BOINC korzysta z wielu różnych bibliotek i programów zewnętrznych. Wystarczy że
jest problem z jedną biblioteką i całość leży. Dziś całą aplikację można napisać w
oparciu o trzy składniki: baza danych, biblioteka, język programowania. Programista
musiałby zadbać o konfigurację tylko tych trzech rzecz. Konkretnie może to być
PostgreSQL, QT i C++; albo MySQL i Java ze swoimi natywnymi bibliotekami.

5) Konfiguracja przydziału zasobów po stronie komputera liczącego jest przestarzała.
Dobra była, gdy 99% mocy obliczeniowej pochodziło z komputerów jednordzeniowych. Komputery
wielordzeniowe już dawno trafiły pod strzechy. Ten brak dowodzi trudności w rozwijaniu,
inaczej ktoś by to napisał porządnie kilka lat temu.

Dokładnie to miałem na myśli pisząc "przerośnięty", choć ty użyłeś lepszego słowa "przestarzały" przez co w skrócie w źródłach panuje lekki chaos.

Co tak naprawdę jest potrzebne aby ruszyć z obliczaniem rozproszonym:
1. serwer:
a) obsługa komunikacji <- wysyłka i odbiór WU
b) pilnowanie WU <- w tej chwili trzeba tworzyć skrypty i je pilnować. Nowy "framework" może mieć obsługę uruchamiania zewnętrznych exeków odpowiedzialnych za poszczególne zadania np.: generowania, przetwarzania  WU
c) obsługa bazy danych <- boinc preferuje MySql <- gdyby wykorzystać odpowiednie biblioteki to można obsłużyć minimum 5 różnych silników

2. klient:
a) obsługa komunikacji <- wysyłka i odbiór WU
b) przeliczanie WU czyli uruchamianie zewnętrznego exeka który przeliczy WU

Co jest potrzebne żeby ruszyć... Masz rację że niewiele. Perft ruszyłby naprawdę
na prościutkim frameworku, ale nie chodzi oto, aby framework nadawał się tylko do
Perfta.

Najpierw trzeba ustalić, do czego taki framework bedzie się nadawał, a do czego nie.
Podstawowy schemat jest taki:
1) Dzielimy zadanie na pod-zadania (statycznie albo dynamicznie)
2) Pod zadania zamieszczamy na jednym lub wielu serwerach
3) Klient łączy się z losowym serwerem i pobiera dane (czyli pod zadanie)
4) Uruchamiają się obliczenia na danych
5) Wynik jest odsyłany do serwera.
Ten prosty schemat w przyszłości będzie można rozszerzyć o komunikację pomiędzy
klientami bez pośrednictwa serwera.

ad <- 1
Nie za bardzo rozumiem dlaczego to framework ma dbać o podziała zadania na pod zadania? <- o to aktualnie dba aplikacja danego projektu jeśli dobrze rozumiem. To twórca aplikacji decyduje co jego appka ma robić <- klient uruchamia appke i zadaje jej WU.
Chyba, że chodzi ci o tworzenie WU <- ale to też twórca projektu tworzy skrypty i określa jakie WU generuje i co zawierają

ad <- 2
w sensie WU chcesz przechowywać na kilku serwerach FTP czy kilku serwerach projektu?
a) kilka ftp nie byłoby głupim pomysłem i baaaaaardzo odciążyło by wymagania dla serwera boinc jeśli chodzi o łącze netowe
b) jeśli chcesz mieć WU na kilku różnych serwerach projektu to dochodzi ci problem z synchronizacją danych pomiędzy nimi <- no chyba że wszystkie łączą się do tej samej bazy danych co mija się z celem skalowania serwera projektu

ad <- 3
czy losowo wybrany serwer jest dobry? i tak i nie.
W przypadku jednego serwera projektu i kilku serwerów ftp z WU można spokojnie napisać prostą funkcje która skieruje klienta na taki ftp jaki chcemy.
Przykładowo mamy 3 ftp i 100 żądań:
a) ftp w domu na neo <- na niego kierujemy 1 żądanie o WU w serii
b) ftp na koncie hostingu <- na niego kierujemy np.: 15 kolejnych połączeń
c) dedykowany serwer ftp <- na niego kierujemy pozostałe 84 żądania
W takim przypadku mamy w miarę dobrze rozłożone obciążenie serwerów <- według mnie. Oczywiście podane liczby są przykładowe.
Miałem kiedyś podobny problem który rozwiązałem w sposób o jakim teraz wspomniałem <- tylko ja miałem jeden serwer zapytań który skierowywał do różnych ftp

ad <- 6
komunikacja między klientami, ale jak to widzisz?
na pewno dobrym pomysłem by było aby zrobić to czego nie ma boinc manager czyli jeśli w sieci mam X komputerów to chciałbym aby jeden komputer łączył się z serwerem ściągał zapas WU dla całęj sieci, a komputery z sieci łączyły się z komputerem mającym dane do przeliczenia.
Tego baaardzo brakuje. Nie mam przypadki, że w firmie tylko jeden komputer jest wystawiony do internetu, a reszta nie ma dostępu.

Teoretycznie najprostszego miniBoinca można zrobić w tydzień przy pracy wieczorkami przez 2 programistów <- i co najlepsze każdy będzie mógł go zainstalować bez tajemnej wiedzy tka jak teraz.

Myślałem o czymś trochę więcej niż minimum.
1) Użytkownicy, tworzenie kont, logowanie, ranking w obliczeniach.
2) Optymalizacja transferu, bufor powtarzających się plików po stronie klienta.
3) Szyfrowana i kompresowana transmisja po SSL.
4) Zadania w transakcyjnej bazie danych, 100% odporności pady zasilania, itd.
5) Klonowanie serwerów, jeśli zadanie jest zbyt duże, to stawiamy nową skrzynkę i
   pod-zadania pakujemy do dwóch komputerów
6) Wewnętrzny fire-wall żeby ktoś mógł ograniczyć obliczenia tylko do prywatnych komputerów
7) Aplikacja webowa do prezentacji postępów, rankingu, itd
8) Jednolite API w postaci funkcji wirtualnych
9) Wygodne narzędzia do administrowania serwerem.
10) Wszelkie opcje na limity zadań dla jednego usera, na czas przedawnienia,
    weryfikację, itd.
11) Może dodatkowy server, specjalny do zarządzania wieloma klientami gdy są
    za maskaradą.

ad <- 0 Ja miałem na myśli miniBoinc czyli pierwszą używalną wersję <- jasne, że to nie byłby koniec prac.
ad <- 2 a jakie pliki ci się powtarzają skoro dane WU mozna przerobić tylko raz na danym komputerze
ad <- 3 niby tak, zabezpieczać się trzeba, ale.. nie do końca rozumiem po co aż tak? Jeśli masz wysyłać dane na ftp lub do serwera projektu to po co ssl?
A jeśli chcesz przesyłać od razu do bazy i wystawiać ją pod publikę to według mnie jest to zły pomysł.
ad <- 5 a nie za bardzo komplikujesz? Jeśli serwer ma być przygotowany pod różne projekty, to autorzy projektów są odpowiedzialni za generowanie odpowiednich WU. Nie ma sensu rozdzielać projektu na kilka serwerów skoro np.: liczących będzie 100. Wtedy będzie to przerost formy nad treścią.
ad <- 6 to co w pkt.5, a to nie przesada?
ad <- 7 aplikacja webowa to dużo powiedziane ;) podobna strona jak jest teraz w każdym projekcie jest chyba w porządku
ad <- 8 API to niby dobry pomysł, ale lepszym jest umożliwienie odpalanie przez serwer innych aplikacji ustawionych przez usera np.: inny exe generuje WU, inny analizuje. A tak naprawdę sama aplikacja obliczająca nie potrzebuje API. Komunikację między aplikacją a managerem można zrobić na 2 inne sposoby:
a) manager i apka są połączone ze sobą po porcie tcp/ip i tu następuje prosta komunikacja <- np.: stop/pauza do aplikacji i stan postępu z aplikacji
b) w katalogu z projektem, każda odpalona instacja appki obliczającej tworzy plik XML (lub jakikolwiek inny) z informacją, że na slocie 1 appka ma 55% postępu <- a manager może to odczytywać co np.: 30-60 sekund.
ad <- 9 ooooo taaaaak <- tego brakuje i to zdecydowanie. Serwer powinien mieć prostego wizarda do wyklikania nowego projektu lub dodania nowej apki <- teraz linuksowcy mogą mnie zgnoić. Ale jako jeszcze prezes fundacji mającej na celu promowanie boinc uważam, że podstawowe czynności na serwerze powinny być MAKSYMALNIE proste i zautomatyzowane.
ad <- 10 teraz poniekąd można to ustawić z tego co wiem. Ale to dobry pomysł.
ad <- 11 to co w pkt.5 i 6 <- trzeba się zastanowić co tak naprawdę chciałbyś utworzyć? Bo tworzenie czegoś co będzie do wszystkiego skończy się napisaniem serwera który będzie do niczego. Serwer projektu obliczeń rozproszonych powinien być aplikacją wyspecjalizowaną. Jeśli jakiś admin będzie miał pod sobą projekt, który rozrośnie się do skali WCG to znaczy że ma w ekipie kilku ludzi, którzy zajmą musie maskaradą i dopasowaniem serwera do potrzeb projektu itp itd
Większość projektów to proste twory.

W tej chwili niektórzy mogą powiedzieć, że nie trzeba być geniuszem aby postawić serwer boinca <- powiedzmy sobie szczerze 75% ludzi na ziemi jest kompletnie zielona z linuksa. Może nie jestem wyznacznikiem całości, ale ja osobiście próbowałem kilkanaście różnych tutoriali i serwer postawiłem tylko raz, ale za holere nie wiem jakim cudem <- a raczej nie o to chodzi.

Mam podobne problemy :)

Dlatego uważam, że postawienie serwera powinno wymagać tylko i wyłącznie podstaw danego systemu.
W przeciwnym przypadku ludzie będą woleli pocierpieć i uruchomić aplikacje na kilku komputerach na uczelniach <- rezygnując z boinca.

Gdyby się okazało, że coś takiego ma "branie" to można by się pokusić oto aby taki serwer obsługiwał Boinc Managera <- w końcu komunikacja serwer-manager odbywa się poprzez xml jak dobrze pamiętam

Myślę żeby na serwer składał się jeden program GUI, prosta aplikacja webowa i nic więcej. Niestety
rozwiązanie takie ma wadę: zmusza do instalowania jakiegoś środowiska graficznego na serwerze. Wydaje
się jednak, że zalety są ważniejsze:
1) nie trzeba pisać managera, bo załatwi to zdalny x-server
2) dużo łatwiej napisać jedną aplikację, niż dwie: server i manager
Pozdrawiam

No tak, ale jakby udało się aby twój serwer obsługiwał boinc manager to by było dla wszystkich najlepiej.
Wtedy tworzysz tylko serwer bo manager już jest.

[goofyx]

Podsumowując moje podejście.
Tak naprawdę nie potrzeba nowego frameworka w pełnym znaczeniu tego słowa.
A prostszą alternatywę dla serwera boinca mogącą komunikować się z boinc manager.

[mariotti]

W jakim sensie "dobrze wydzielonej klasy zadań" skoro możesz odpalić na boinc praktycznie każdy projekt.

Chodziło mi nie tyle o klasę zadań, co o klasę sposobów rozwiązywania zadań. Czyli
najpierw mamy różne zadania. Potem każde zadanie ma wiele różnych sposób rozwiązania.
W tych sposobach są sposoby dobre, złe, szybkie, wolne, szeregowe, równoległe,
rozproszone, kwantowe i co tam jeszcze. Jeśli zdecydujemy się na BOINC, to do
uzyskania jednych sposobów napracujemy się więcej, do innych mniej, jeszcze
innych w ogóle nie uzyskamy. Jeśli zadanie da się z góry (czyt. przed startem projektu)
podzielić na pod-zadania, to BOINC jest idealny. Jeśli zadania powstają dynamicznie,
czyli w odpowiedzi na "sytuację obliczeniową", to BOINC niekoniecznie ułatwia
postawienie aplikacji. Po prostu jest to specyficzny framework, do jednych rzeczy jest
idealny, do drugich jeszcze się nadaje, do następnych lepiej go nie używać - pomimo że
teoretycznie można postawić na nim każdą aplikację.

Dokładnie to miałem na myśli pisząc "przerośnięty", choć ty użyłeś lepszego słowa "przestarzały" przez co w skrócie w źródłach panuje lekki chaos.

Ok, myślałem że chcesz powiedzieć coś w rodzaju, że oferuje za dużo udogodnień i
przestają one współgrać z sobą.

ad <- 1
Nie za bardzo rozumiem dlaczego to framework ma dbać o podziała zadania na pod zadania?

Nie ma dbać o podział na zadania. Podając tamten schemat, chciałem zdefiniować
pole zastosowań, w których taki framework istotnie uprości życie programiście i
administratorowi. Niemniej framework może oferować szereg narzędzi do wspomagania
podziału na zadania.

To twórca aplikacji decyduje co jego appka ma robić <- klient uruchamia appke i zadaje jej WU.

Jeszcze prościej to można zrobić, poprzz jakiś najzwyklejszy callback. Twórca wypełni kod funkcji
zwrotnej, albo zostawi kod domyślny, albo zostawi kod programu przykładowego i wio.
Raczej nie ma być podziału na klienta, managera i aplikację liczącą. Jakby było zainteresowanie
takim frameworkiem, to potem doszłoby coś zamiast managera, tak żeby np. jednym klikiem
wyłączyć 100 aplikacji liczących na 30 komputerach.

Chyba, że chodzi ci o tworzenie WU <- ale to też twórca projektu tworzy skrypty i określa jakie WU generuje i co zawierają

Główna idea tworzenia WU byłaby bardzo podobna jak w BOINC. Różnica polegałaby
tylko na lepszej parametryzacji i automatycznej optymalizacji - na razie nie ma sensu
podawać tego drobiazgu - przyjmijmy że tworzenie i dodawanie WU będzie na identycznej
zasadzie jak w BOINC.

Jednak kolosalna różnica będzie w realizacji tej zasady. Chodzi o spójność, o
spójność tak rozumianą, jak jest rozumiana w bazach danych. Czyli albo
work-units jest, albo go nie ma. Albo work-units się policzył, albo czeka na liczenie,
albo wystąpił błąd, albo czeka na odesłanie wyników. Nie może być sytuacji
wieloznacznych, w zależności od punktu analizy. Teraz w BOINC z punktu
widzenia bazy danych WU mogą być, a już z punktu widzenia schedulera ich nie ma, bo
jakiś biały znak uniemożliwia ich podawanie, a cholera wie jaka jeszcze inna interpretacja
może być z punktu widzenia asymilatora... Jak w takich warunkach można mieć pewność, że
dane są takie jak odesłał liczydłowy, a nie takie, ile udało się zapisać bajtów zanim
padło zasilanie na serwerze - przecież pady się zdarzają. Chodzi o jasną i konkretną
sytuację w przestrzeni całego frameworka. Służą do tego celu transakcje, blokady,
semafory, sumy kontrolne, dobre definicje, itd.

w sensie WU chcesz przechowywać na kilku serwerach FTP czy kilku serwerach projektu?

Są dwie możliwości. Jedna jako narzędzie, pełny automat, w pełni odciążający
programistę/administratora. Druga mniej automatyczna, ale bardziej wydajna.
Tę w pełni automatyczną widzę tak:
1) administrator klika w menu sklonuj serwer
2) wpisuje w okienko adres ip nowego serwera
3) wpisuje w okienko ile zadań ma się sklonować
4) serwer przez dłuższą chwilę mieli po dysku, obliczenia przez jakiś czas niestety staną
5) następnie wypluwa pełną konfigurację dla klona
6) na nowej maszynie uruchamiamy klona, podajemy ścieżkę do konfiguracji
7) gotowe - serwer działa dwa razy szybciej
Potem analogiczny automat do zbierania wyników.

a) kilka ftp nie byłoby głupim pomysłem i baaaaaardzo odciążyło by wymagania dla serwera boinc jeśli chodzi o łącze netowe
b) jeśli chcesz mieć WU na kilku różnych serwerach projektu to dochodzi ci problem z synchronizacją danych pomiędzy nimi <- no chyba że wszystkie łączą się do tej samej bazy danych co mija się z celem skalowania serwera projektu

Wspólna baza oczywiście mija się z celem (chociaż niekoniecznie, ale to szczegół na późniejsze rozważania). Jeśli WU będą
powstawały w czasie rzeczywistym, to by musiało być jakieś API do synchronizacji - trudniejsza sprawa, ale można się
zastanowić. Na razie myślałem o podziale bazy zadań na części, czyli głównie o przypadkach, w których przed startem
projektu można wygenerować wszystkie/większość WU.

ad <- 3
czy losowo wybrany serwer jest dobry? i tak i nie.
W przypadku jednego serwera projektu i kilku serwerów ftp z WU można spokojnie napisać prostą funkcje która skieruje klienta na taki ftp jaki chcemy.
Przykładowo mamy 3 ftp i 100 żądań:
a) ftp w domu na neo <- na niego kierujemy 1 żądanie o WU w serii
b) ftp na koncie hostingu <- na niego kierujemy np.: 15 kolejnych połączeń
c) dedykowany serwer ftp <- na niego kierujemy pozostałe 84 żądania
W takim przypadku mamy w miarę dobrze rozłożone obciążenie serwerów <- według mnie. Oczywiście podane liczby są przykładowe.
Miałem kiedyś podobny problem który rozwiązałem w sposób o jakim teraz wspomniałem <- tylko ja miałem jeden serwer zapytań który skierowywał do różnych ftp

Oczywiście losowy wybór jest najprostszym algorytmem. Można zastanowić się nad lepszym niż najprostszy.
Np. klient może dostać informację o ilość zadań od serwera i wybierać z większym prawdopodobieństwem z
tych serwerów, na których zadań jest więcej. Wtedy wystarczy że administrator na lepszych maszynach
zamieści więcej zadań - takich algorytmów równoważenia obciążenia jest sporo, można kombinować.

komunikacja między klientami, ale jak to widzisz?

Mam jakiś pomysł, ale nie wiem czy warto to implementować. Komunikacja (rzecz jasna - tylko w
jakimś ograniczonym zakresie)  według schematu  P2P, to zastosowania dla takich bibliotek jak MPI.
W tym frameworku może się wydarzyć wszystko co najgorsze. Klient chce się skontaktować z innym
klientem, a inny jest za maskaradą, albo ściąga coś ftp i łącze jest zapchane, albo padło mu zasilanie, albo liczy
task w przypadku którego komunikacja nie ma sensu, albo wolontariusz wyłączył komputer...
Komunikacja P2P ma sens raczej gdy ktoś na swojej prywatnej sieci chce liczyć i ma
prawie gwarancje że komunikacja się uda i przyniesie korzyści.

na pewno dobrym pomysłem by było aby zrobić to czego nie ma boinc manager czyli jeśli w sieci mam X komputerów to chciałbym aby jeden komputer łączył się z serwerem ściągał zapas WU dla całęj sieci, a komputery z sieci łączyły się z komputerem mającym dane do przeliczenia.
Tego baaardzo brakuje. Nie mam przypadki, że w firmie tylko jeden komputer jest wystawiony do internetu, a reszta nie ma dostępu.

Dobrze że o tym napisałeś, sam bym nigdy na to nie wpadł! Koncepcyjne jest to całkiem proste,
w realizacji będzie trudniej.

ad <- 2 a jakie pliki ci się powtarzają skoro dane WU mozna przerobić tylko raz na danym komputerze

Np. robimy system do jakiś ciężkich obliczeń. Co jest ciężkim obliczeniem? Powiedzmy
że szukamy optymalnego rozłożenia elementów na jakimś materiale. Przychodzi klient do firmy
która ma usługi CNC. Klient chce szybko wykonaną usługę. Firma chce zaoszczędzić materiał.
Żeby szybko policzyć tak trudne zadanie, potrzeba setek komputerów - to koszt większy niż
potencjalne oszczędności. Ale różnych firm może być 20 i w każdej może być 10 komputerów. Więc
gdy jedna firma nie ma klienta, to pożycza moc obliczeniową pozostałym. Oczywiście im firma
więcej udostępniała, tym potem więcej otrzyma - wszystko nadzoruje frame-work lub aplikacja. Więc
firmy wrzucają zadania do rozproszonego systemu. Definicja zadania powtarza się, więc
w jednym pliku mamy tę definicję. W drugim pliku możemy mieć parametry dla algorytmu, np.
najlepsze dotychczasowe rozwiązanie, zarodek liczb losowych, itd. Dalej klient pyta
serwer o zadanie. Serwer odpowiada że jest zadanie i sklada się z pliku A i B. Klient
pobiera pliki A i B. Potem odsyla wyniki i znowu pyta się o zadanie. Serwer mówi, że jest
zadanie i składa się z plików A i C. Więc klient pobiera tylko C, bo A sobie zapisał na
dysku. Oczywiście do tego dochodzą priorytety, sprawdzanie czy jest miejsce na
zapisywanie takich danych, algorytmy do optymalizacji kolejności zadań z powtarzającymi
się plikami, itd, itd. W BOINC coś takiego jest, ale ciężkie opanowaniu i używaniu - nie
działa automatycznie.

ad <- 3 niby tak, zabezpieczać się trzeba, ale.. nie do końca rozumiem po co aż tak? Jeśli masz wysyłać dane na ftp lub do serwera projektu to po co ssl?

Może ktoś prywatnie liczyć. Może liczyć jakiś swój komercyjny projekt, z ważnymi-tajnymi danymi, a komputery może
mieć rozrzucone po sieci globalnej. Niby można zrobić SSL jako opcję - kto nie będzie chciał, to zrobi zwyczajnie. Ale
z tego co wiem, SSL z automatu kompresuje dane, więc to może nawet oznaczać wygodę dla twórców frameworka.

A jeśli chcesz przesyłać od razu do bazy i wystawiać ją pod publikę to według mnie jest to zły pomysł.

Nie wiem, zależy czy bazy są odporne na ataki z zewnątrz.

ad <- 5 a nie za bardzo komplikujesz? Jeśli serwer ma być przygotowany pod różne projekty, to autorzy projektów są odpowiedzialni za generowanie odpowiednich WU. Nie ma sensu rozdzielać projektu na kilka serwerów skoro np.: liczących będzie 100. Wtedy będzie to przerost formy nad treścią.

Nie wiem, myślę że to czasami może się przydać.

ad <- 6 to co w pkt.5, a to nie przesada?

W prywatnych projektach to przydatna i wygodna rzecz. De facto można użyć
zewnętrznego firewalla, ale... jakoś tak wyszło, że akurat to mam prawie gotowe :)

ad <- 7 aplikacja webowa to dużo powiedziane ;) podobna strona jak jest teraz w każdym projekcie jest chyba w porządku

Tak, o to mi chodziło :)

ad <- 8 API to niby dobry pomysł, ale lepszym jest umożliwienie odpalanie przez serwer innych aplikacji ustawionych przez usera np.: inny exe generuje WU, inny analizuje.

Moim zdaniem, właśnie z powodu wielości niezależnych aplikacji, tak trudno jest zapanować nad
spójnością, że w BOINC nawet nie podjęli takiej próby. Każdy program działa niezależnie, każdy
ma trochę inne problemy, jeden program coś drugiemu poda, drugi nie wie co z tym zrobić,
trzeci nie rozpozna że drugi nie wiedział, czwarty wygeneruje niepoprawny komunikat o błędzie...

Aby zapewnić spójność w środowisku rozproszonym (choćby rozproszenie było tak małe jak
serwer właściwy i manager serwera), to trzeba się naprawdę dużo napracować. W jednej
aplikacji,  na jakimś prostym mechanizmie można wszystko zsynchronizować.
Jeśli w krótkim czasie ma powstać lepsze narzędzie, to może się składało tylko z
dwóch ważnych aplikacji: serwer i klient. Potem dwie dodatkowe aplikacje: aplikacja
webowa i aplikacja do zarządzania wieloma klientami na raz.

A tak naprawdę sama aplikacja obliczająca nie potrzebuje API.

To prawda.

Komunikację między aplikacją a managerem można zrobić na 2 inne sposoby:

Nie ma być podziału na managera, klienta i aplikację liczącą. Po stronie jednostek
obliczających ma być jedna aplikacja kliencka. Tzn framework ma dostarczać
jedną jedyną aplikację po stronie klienta, a programista z poziomu tej aplikacji
może sobie uruchomić tysiąc innych zewnętrznych. Programista będzie mógł też
całe obliczenia zawrzeć "wewnątrz" tej aplikacji z frameworka - jego wybór.

a) manager i apka są połączone ze sobą po porcie tcp/ip i tu następuje prosta komunikacja <- np.: stop/pauza do aplikacji i stan postępu z aplikacji

Owszem prosta, ale można jeszcze prościej, tak jak pisałem powyżej: jedna jedyna aplikacja.

b) w katalogu z projektem, każda odpalona instacja appki obliczającej tworzy plik XML (lub jakikolwiek inny) z informacją, że na slocie 1 appka ma 55% postępu <- a manager może to odczytywać co np.: 30-60 sekund.

Też można prościej: programista wywoluje funkcję API z parametrem 55% i na GUI przesuwa się pasek
postępu.

ad <- 9 ooooo taaaaak <- tego brakuje i to zdecydowanie. Serwer powinien mieć prostego wizarda do wyklikania nowego projektu lub dodania nowej apki <- teraz linuksowcy mogą mnie zgnoić. Ale jako jeszcze prezes fundacji mającej na celu promowanie boinc uważam, że podstawowe czynności na serwerze powinny być MAKSYMALNIE proste i zautomatyzowane.

Dla mnie idealne jest QT. Gdy mam coś zrobić, to przeszukuję bazę gotowych-przykładowych
programów i też swoje programy. Wybieram najbardziej podobny program. Kompiluję, uruchamiam i już
działa. Potem nanoszę swoje wymagania. Tak samo chciałbym mieć tutaj. Copy-paste
programu przykładowego i od razu coś działa. Potem edycja funkcji liczącej - i działa na
innych obliczeniach.

ad <- 10 teraz poniekąd można to ustawić z tego co wiem. Ale to dobry pomysł.

Można, kiedyś czytałem jak, ale od tamtej pory zapomniałem - dlatego serwer
powinien być aplikacją GUI.

ad <- 11 to co w pkt.5 i 6 <- trzeba się zastanowić co tak naprawdę chciałbyś utworzyć? Bo tworzenie czegoś co będzie do wszystkiego skończy się napisaniem serwera który będzie do niczego. Serwer projektu obliczeń rozproszonych powinien być aplikacją wyspecjalizowaną. Jeśli jakiś admin będzie miał pod sobą projekt, który rozrośnie się do skali WCG to znaczy że ma w ekipie kilku ludzi, którzy zajmą musie maskaradą i dopasowaniem serwera do potrzeb projektu itp itd
Większość projektów to proste twory.

Chodzi o kompromis pomiędzy wygodą liczydłowych a nakładem pracy na frame-work. Liczydłowym
trudno jest zarządzać wieloma aplikacjami liczącymi. Programistom trudno jest napisać porządnego
managera. Co gorsza, gdy klient pracuje jako serwer dla managera, to liczydłowy ma problem z maskaradą,
więc nawet jak się napisze managera, to problemy nie znikną... a tu jeszcze manager może być za maskaradą...
Jedyne rozwiązanie jakie znam, a nawet podejrzewam że inne nie istnieją, to jakiś mały zewnętrzny
serwer. Taki serwer może (ale nie musi) być aplikacją www. Przykładowy scenariusz: liczydłowy zaloguje się stronę
www, naciśnie stop, a po 60 sekundach wszystkie jego aplikacje, na wszystkich komputerach, zatrzymają się.
Zaraz ktoś powie, że tylko jeden komputer w sieci lokalnej ma dostęp do www... i to się da obejść, ale niestety
coraz większym nakładem pracy.

Dlatego uważam, że postawienie serwera powinno wymagać tylko i wyłącznie podstaw danego systemu.
W przeciwnym przypadku ludzie będą woleli pocierpieć i uruchomić aplikacje na kilku komputerach na uczelniach <- rezygnując z boinca.

Zapewne tak jest. Wiedzę dodatkową można ograniczyć do znajomość relacyjnych baz
danych i języka programowania, np. Postgres i C++. Resztę podpowie GUI.

No tak, ale jakby udało się aby twój serwer obsługiwał boinc manager to by było dla wszystkich najlepiej.
Wtedy tworzysz tylko serwer bo manager już jest.

To by zapewniło łagodne przejście z jednego systemu na drugi. Przyznaję, że bardzo cwane :D
Szkoda tylko, że już mnie rozbolała głowa na myśl o robieniu tego w taki sposób :D

Pozdrawiam

[Karlik]

Można, kiedyś czytałem jak, ale od tamtej pory zapomniałem - dlatego serwer powinien być aplikacją GUI.

Możesz dorobić osobny konfigurator w gui, ale sam serwer musi/powinien być konsolowy - z możliwością całkowitego przejścia w tło - cały output/logi powinny się zapisywać w podanych ścieżkach, bez potrzeby przekierowywania standardowego wejścia/wyjścia.
Tak samo klient - GUI może być dodatkiem, ale musi/powinna być możliwość uruchomienia i skonfigurowania bez użycia żadnego narzędzia graficznego. Swoją drogą to mnie trochę irytuje w BOINCu, że konfiguracja jest niejednolita i ciężko do niektórych opcji dokopać się spoza managera.

[mariotti]

Można, kiedyś czytałem jak, ale od tamtej pory zapomniałem - dlatego serwer powinien być aplikacją GUI.

Możesz dorobić osobny konfigurator w gui, ale sam serwer musi/powinien być konsolowy - z możliwością całkowitego przejścia w tło - cały output/logi powinny się zapisywać w podanych ścieżkach, bez potrzeby przekierowywania standardowego wejścia/wyjścia.
Tak samo klient - GUI może być dodatkiem, ale musi/powinna być możliwość uruchomienia i skonfigurowania bez użycia żadnego narzędzia graficznego. Swoją drogą to mnie trochę irytuje w BOINCu, że konfiguracja jest niejednolita i ciężko do niektórych opcji dokopać się spoza managera.

Wiem do czego zmierzasz i przyznaję Ci całkowitą racje, że tak byłoby profesjonalnie. Jednak rozbijanie
serwera na dwie aplikacje wiąże się z dużym narzutem dodatkowej pracy, albo pojawiają się te wszystkie
problemy, jakie ma BOINC. Nawet jeśli na serwer będą się składały tylko dwie aplikacje, to trzeba pisać
kod odpowiedzialny za ich synchronizację. Z kolei jeśli serwer będzie miał GUI, to bedzie trzeba
tylko(?) instalować środowisko GUI i zalogować się przez jakiś vncviwer - to chyba nieduży kłopot?

Generalnie myślałem o czymś takim, że gdy serwer pracuje, to widać go jako tę ikonkę w trayu. Użytkownik
klika na ikonce i ma pełen, wypasiony panel administracyjny. Np. chce zablokować jakieś IP, to
wchodzi na zakładkę firewalla i wpisuje maskę IP. Chce zobaczyć wyniki usera, to wchodzi na
zakładkę userów, szuka i klika na interesującego go usera, no i ma wyniki. I tak samo z wszystkimi
ustawieniami.

Pozdrawiam

[krzyszp]

No tak, ale z góry właściwie odcinasz użytkowników słabszych VPS, dla których postawienie środowiska graficznego oznacza pozbawienie się RAM'u, którego każdy kilobajt jest cenny, jak masz ich 256...

[Gołąbpocztowy]

Linia komend jest dużo dużo dużo wygodniejsza niż jakiekolwiek GUI. Zresztą GUI to tylko nakładka która będzie zmieniać wpisy w plikach konfiguracyjnych. Wg. mnie podstawa to linia komend, a GUI to dodatek dla leniwych.

[mariotti]

Linia komend jest dużo dużo dużo wygodniejsza niż jakiekolwiek GUI. Zresztą GUI to tylko nakładka która będzie zmieniać wpisy w plikach konfiguracyjnych. Wg. mnie podstawa to linia komend, a GUI to dodatek dla leniwych.

Jest różnie. Czasami łatwiej wpiać treść zadania z klawiatury, a czasami
łatwiej zadanie wyklikać. Gdy łatwiej wpisać, to GUI nie pozbawia nas takiej
możliwości - wpisuje się w okienku tekstowym.

No tak, ale z góry właściwie odcinasz użytkowników słabszych VPS, dla których postawienie środowiska graficznego oznacza pozbawienie się RAM'u, którego każdy kilobajt jest cenny, jak masz ich 256...

To na pewno racja, GUI zżera dużo zasobów. Może zastanowię się jeszcze raz
nad takim rozwiązaniem.

Kiedyś pisałem aplikację do wspomagania zarządzania małym osiedlem, głownie
do zarządzania miejscami parkingowymi. Ta aplikacja właśnie tak działa. Główna
aplikacja uruchamia się jako usługa windows NT, a konfigurator pracuje jako
okienkowe GUI. Pisaliśmy wraz z kumplem tę aplikację przez ponad rok czasu :D

Pozdrawiam

[Karlik]

Ogólnie wymuszanie posiadania Xów czy innego środowiska graficznego na serwerze tylko po to, żeby działał jakiś daemon jest... złym pomysłem (żeby nie powiedzieć dosadniej).

[mariotti]

Ogólnie wymuszanie posiadania Xów czy innego środowiska graficznego na serwerze tylko po to, żeby działał jakiś daemon jest... złym pomysłem (żeby nie powiedzieć dosadniej).

Myślę jakby to było bez Xów. Na razie widzę dwie inne możliwości:
1) konfiguracja musi znaleźć się w plikach tekstowych;
2) konfiguruje się ze zdalnego managera.

Możliwość 1 jest diabelnie niewygodna. Trzeba pobrać pliki logów na
lokalny komputer. Następnie trzeba logi przeanalizować. Potem trzeba
zmienić pliki konfiguracyjne (np. zablokować złośliwe IP). W końcu trzeba
zresetować serwer. Kolejne wady, to brak interakcji z serwerem, chyba
że przez jakieś przerwania, albo komendy tekstowe. Jak znam życie, to
po dwóch latach autor programu nie będzie pamiętał jaka jest składnia
poleceń :)

Możliwość druga oznacza napisanie "dwóch serwerów" w jednym programie.
Jeden pracuje jako serwer dla aplikacji liczących, a drugi jako serwer dla
managera. Więc dochodzi kod drugiego serwera, kod synchronizujący
całość i kod pośredniczący pomiędzy bazą danych - serwerem - managerem.
Oczywiście też dochodzi kod managera. Obawiam się, że drugi sposób wymaga
trzy razy więcej roboty niż jedna aplikacja GUI. Na taki projekt może zabraknąć
rąk do pracy, zwłaszcza że to ma być oprogramowanie napisane bardzo starannie,
bezpiecznie, bez krytycznych błędów, itd.

Jest więcej wad drugiego rozwiązania. Gdy potem na takim frameworku programista
będzie chciał postawić niestandardową aplikację, np. będzie chciał dodać jakieś
opcje, to musi:
1) zmodyfikować serwer aplikacji liczących
2) manager serwera
3) dodać ramki do protokołu komunikacyjnego pomiędzy serwerem a managerem.

Obawiam się, że w ten sposób miniemy się z najważniejszym celem, czyli z
prostotą stawiania aplikacji. Chyba nie ma innego wyjścia, serwer musi być
aplikacją GUI. 

Pozdrawiam

[krzyszp]

Oj, pojechałeś...

Myślę jakby to było bez Xów. Na razie widzę dwie inne możliwości:
1) konfiguracja musi znaleźć się w plikach tekstowych;

Niby dlaczego? Może być w bazie, plikach tekstowych, zmiennych systemowych - nie musi być w plikach tekstowych...

Możliwość 1 jest diabelnie niewygodna. Trzeba pobrać pliki logów na
lokalny komputer.

Nie prawda...

Potem trzeba
zmienić pliki konfiguracyjne (np. zablokować złośliwe IP). W końcu trzeba
zresetować serwer.

Znowu nieprawda. Daemon może (np.) co określony interwał odczytywać konfig z bazy...

2) konfiguruje się ze zdalnego managera.
...
Możliwość druga oznacza napisanie "dwóch serwerów" w jednym programie.
Jeden pracuje jako serwer dla aplikacji liczących, a drugi jako serwer dla
managera.

Ta sama uwaga, co powyżej...

U jednego z moich klientów pracuje w sumie 5 osobnych programów przechowujących wszystkie informacje konfiguracyjne w jednej tabeli we wspólnej bazie, zmiana jednego powoduje automatyczne uwzględnienie w innych. Każdy z programów co określony (wartością w bazie!) interwał sprawdza zmiany i się dostosowuje. Oczywiście zmiany w danych (nie konfiguracyjne) są z miejsca odczytywane w czasie rzeczywistym (ale to "oczywista oczywistość").

[Szopler]

Krzychu 100% racji!
Nie widzę problemu by serwer trzymał konfig w bazie danych i konfigurowalny był plikiem wykonywalnym z konsoli. Do tego nakładka graficzna wywołująca konsolowy program z odpowiednimi parametrami linii poleceń... i wszystko.

To tak na podstawie działania AVRDude - programiku do programowania uP ATMELA.
Tam jest avrdude.exe - konsolowy programik, config z opisem każdego procesora jest w pliku txt. Do tego prosta nakładka AVRDudeGUI - exe który odpala (w ukryciu) avrdude.exe dodając do linii poleceń przełączniki i parametry w zależności od ustawień w okienku aplikacji.

[mariotti]

Oj, pojechałeś...
Niby dlaczego? Może być w bazie, plikach tekstowych, zmiennych systemowych - nie musi być w plikach tekstowych...

Ale czy konfiguracja w bazie lub w zmiennych systemowych jest dla użytkownika o
wiele łatwiejsza niż w plikach tekstowych?

Możliwość 1 jest diabelnie niewygodna. Trzeba pobrać pliki logów na
lokalny komputer.

Nie prawda...

Prawda. Na serwerze nie mamy GUI, więc nie mamy wygodnych/dedykowanych
narzędzi do analizy logów. Trzeba logi pobrać na komputer gdzie jest GUI, albo
pisać skrypty na serwerze.

Znowu nieprawda. Daemon może (np.) co określony interwał odczytywać konfig z bazy...

W dosłownym rozumieniu owszem to jest nieprawda. Przepraszam, ale zafiksowałem się
na kontekście łatwego używania :) Więc czy taka możliwość istotnie przyczyna się do
ułatwienia obsługi i do ułatwienia stawiania aplikacji? Trzeba napisać aplikację, która
połączy się z bazą, wczyta ustawienia, umożliwi edycję ustawień i zapisze w
bazie. W przypadku stawiania aplikacji niestandardowej, programista będzie musiał
zmieniać kod dwóch aplikacji. Z punktu widzenia obsługi, dokładnie to samo co
konfiguracja w plikach tekstowych.

U jednego z moich klientów pracuje w sumie 5 osobnych programów przechowujących wszystkie informacje konfiguracyjne w jednej tabeli we wspólnej bazie, zmiana jednego powoduje automatyczne uwzględnienie w innych. Każdy z programów co określony (wartością w bazie!) interwał sprawdza zmiany i się dostosowuje. Oczywiście zmiany w danych (nie konfiguracyjne) są z miejsca odczytywane w czasie rzeczywistym (ale to "oczywista oczywistość").

Wyobrażam sobie taki scenariusz najprostszego użycia. Jakiś naukowiec zastanawia
się nad jakimś problemem. Nie bardzo zna się na komputerach, ale ma w domu bądź w pracy
windowsa albo linuxa i coś umie zrobić w edytorze tekstu, a może nawet w arkuszu kalkulacyjnym.
Problem nad którym się zastanawia wymaga skomplikowanego algorytmu, ale znalazł
w sieci gotowy program do liczenia. Następnie ściąga frameworka do obliczeń rozproszonych
wraz z przykładem użycia na zewnętrznej aplikacji liczącej. Najpierw w arkuszu, albo w
notatniku wpisuje zadania dla tej aplikacji. Potem odpala serwer. W serwerze przy pomocy
GUI robi import pliku csv, albo import plików tekstowych. Potem w kliencie podmienia
aplikację liczącą. Niestety musi jeszcze w klientach skonfigurować IP serwera - tego nie
da się przeskoczyć, może jakiś informatyk mu pomoże. W końcu zanosi klienta z aplikacją
liczącą do kumpli, albo na komputery w pracy. Kopiuje pliki na pulpit, raz klika i liczą
mu się zadania w środowisku rozproszonym. Na koniec przez GUI serwera robi eksport
par wejście - wyjście. Bym zapomniał, jeszcze będzie musiał zainstalować bazę danych.

Czy da się taki efekt uzyskać w inny sposób niż serwer GUI?

Pozdrawiam

[Szopler]

Za bardzo kombinujesz... Co ma aplikacja licząca do serwera i jakie konfigurowanie IP serwera w klientach?
Serwer musi obsłużyć zaledwie kilka zdarzeń:  wyślij aplikację, wyślij WU, przyjmij wynik, sprawdź/porównaj wyniki (walidacja), przyjmij kod błędu gdy coś się wysypie.
Klient podobnie: przyjmij aplikację, przyjmij WU, oblicz, odeślij wynik lub kod błędu i w zasadzie to jest miniumum.

Klient podłącza się do www projektu i to wolontariusz decyduje do jakiego projektu się podłącza. Admin z poziomu serwera do tego nic nie ma. Może najwyżej kogoś zbanować za cheating.

Konfiguracja serwera w zasadzie może być robiona przez stronę - formularz napisaną w PHP.

[krzyszp]

A i owszem - poprzez stronę www :)

Natomiast z punktu obsługi konfiguracja w bazie niczym nie różni się od tej w pliku tekstowym - kwestia sposobu, w jakim będzie zapisywana, przecież aplikacja ma jakoś to odczytać/zapisać i doprawdy wszystko jedno, czy wykona to poprzez edycję pliku txt, czy zapisu/update w bazie - w końcu obydwa sposoby wymagają napisanie jakiegoś kodu...

Analogicznie logi mogą być:
1. Wyświetlane poprzez WWW
2. Pobierane do aplikacji lokalnej w postaci txt
3. Serwowane za pomocą webservice...

Pp prostu moim zdaniem trzymanie konfigu w bazie zabezpiecza np. przed innymi lokalizacjami takich plików na różnych dystrybucjach/systemach (domyślne ścieżki do plików). Oczywiście, możesz wymusić swoje ścieżki, ale to nie jest eleganckie rozwiązanie...

W przypadku stawiania aplikacji niestandardowej, programista będzie musiał
zmieniać kod dwóch aplikacji.

Nie rozumiem o czym piszesz.
Z Twojej wypowiedzi wynika, że autor projektu musiałby edytować pliki serwera. To bez sensu, przecież może pobierać ustawienia standardowe pobierać z serwera, a swoje nietypowe (dodatkowe) ustawienia trzymać "u siebie".

Wyobrażam sobie taki scenariusz najprostszego użycia. Jakiś naukowiec zastanawia
się nad jakimś problemem. Nie bardzo zna się na komputerach, ale ma w domu bądź w pracy
windowsa albo linuxa i coś umie zrobić w edytorze tekstu, a może nawet w arkuszu kalkulacyjnym.
Problem nad którym się zastanawia wymaga skomplikowanego algorytmu, ale znalazł
w sieci gotowy program do liczenia. Następnie ściąga frameworka do obliczeń rozproszonych
wraz z przykładem użycia na zewnętrznej aplikacji liczącej. Najpierw w arkuszu, albo w
notatniku wpisuje zadania dla tej aplikacji. Potem odpala serwer. W serwerze przy pomocy
GUI robi import pliku csv, albo import plików tekstowych. Potem w kliencie podmienia
aplikację liczącą. Niestety musi jeszcze w klientach skonfigurować IP serwera - tego nie
da się przeskoczyć, może jakiś informatyk mu pomoże. W końcu zanosi klienta z aplikacją
liczącą do kumpli, albo na komputery w pracy. Kopiuje pliki na pulpit, raz klika i liczą
mu się zadania w środowisku rozproszonym. Na koniec przez GUI serwera robi eksport
par wejście - wyjście. Bym zapomniał, jeszcze będzie musiał zainstalować bazę danych.

Wiesz, ja chyba nie rozumiem. Chcesz napisać serwer, który sobie całą konfigurację odczyta z pliku csv i zrozumie przy tym "co poeta miał na myśli" w osobie naukowca, co sobie opracował założenia w arkuszu kalkulacyjnym?
Tak czy siak, to wcale nie zmienia faktu, że serwer dalej może przechowywać konfig w bazie danych, co w połączeniu z faktem, że i tak baza jest w użyciu czyni całe rozwiązanie bardziej eleganckim...

[mariotti]

Może macie rację, muszę to wszystko przetrawić. Może ja jestem za bardzo przyzwyczajony do
swojego schematu pisania aplikacji. A może Wy nie bierzecie pod uwagę wszystkiego co program
musi zrobić po zmianie w opcjach. Zwykle tak jest, że coś się przed rozpoczęciem kodowania
wydaje proste i oczywiste.

Właśnie wklepuje w innym projekcie system regułowy do wspomagania decyzji. Początkowo
wydawało się tak prosto: użytkownik zdefiniuje reguły, zrobi test na danych uczących, potem
będzie miał jeszcze edycję parametrów. Okazało się, że na takich założeniach nawet nie
da się pracować, nie przewidzieliśmy około 95% ważnych rzeczy. To oznacza, że mamy
pracy 20 razy więcej niż się początkowo wydawało. Tak miałem prawie przy każdym większym
projekcie :)

Z doświadczenia wiem, że jak ktoś mówi "przecież to tylko tylko zapis i odczyt ustawień", to
powinienem się przygotować na pół roku dodatkowej pracy :) W dużych systemach trudność
wynika z konieczności zgrania wielu drobnych elementów. Każdy pojedynczy element jest
prosty w zaprogramowaniu, ale razem mogą stanowić koszmar.

Nie rozumiem o czym piszesz.
Z Twojej wypowiedzi wynika, że autor projektu musiałby edytować pliki serwera. To bez sensu, przecież może pobierać ustawienia standardowe pobierać z serwera, a swoje nietypowe (dodatkowe) ustawienia trzymać "u siebie".

Niektórym nie wystarczy to co oferuje framework. Chcę żeby framework był łatwy do rozbudowania, tak
żeby programista mógł łatwo dodać nowe cechy. Podział na dwie aplikacje oznacza trudniejszą rozbudowę.

Wiesz, ja chyba nie rozumiem. Chcesz napisać serwer, który sobie całą konfigurację odczyta z pliku csv i zrozumie przy tym "co poeta miał na myśli" w osobie naukowca, co sobie opracował założenia w arkuszu kalkulacyjnym?

Nie nie, chodzi tylko o zadania do policzenia w pliku csv. Niemniej domyślna konfiguracja ma być
taka, żeby dało się od kliknięcia uruchomić obliczenia rozproszone.

Tak czy siak, to wcale nie zmienia faktu, że serwer dalej może przechowywać konfig w bazie danych, co w połączeniu z faktem, że i tak baza jest w użyciu czyni całe rozwiązanie bardziej eleganckim...

Myślę że wszyscy razem potrafimy przewidzieć nie więcej niż 5% problemów jakie się pojawią :) Mnie się to
teraz też wydaje łatwe. Problem w tym, że zawsze przy każdym projekcie takie łatwe się wydawało. Potem w
realizacji okazywało się, że trzeba oprogramować wiele nieprzewidzianych rzeczy.  Przypuszczam że
pojawią się skomplikowane interakcje pomiędzy parametrami i stanem w jakim jest serwer. W pojedynczej
aplikacji ładnie zablokuję edycję parametrów gdy będzie ona z jakiś powodów niewskazana.

W przypadku edycji na bazie co mogę zrobić? Niby pobieram, edytuję i zapisuję. Nie potrafię udowodnić, że
serwer w każdym etapie pracy po takim zapisie nadal będzie pracował stabilnie i poprawnie. Załóżmy że ktoś
wprowadził niepoprawne parametry, co się dzieje dalej? Serwer zwali logi do jakiegoś pliku - znowu żmudna
analiza logów. Po analizie logów znowu konsternacja jak przywrócić poprawne wartości... Żeby zapobiec
wprowadzaniu niepoprawnych parametrów, to trzeba zrobić w managerze jakieś skanowanie stanu serwera i
nie pozwalać na edycję tego co w danej chwili może zaszkodzić. Ale jak serwer padnie, to nie da się z nim
połączyć. Więc manager by musiał mieć dwa tryby edycji: gdy serwer padł i gdy serwer pracuje :) Bez względu
czy powyższy scenariusz jest choć trochę realistyczny, czy jest całkowicie fantastyczny, to tego
typu problemy się pojawia. Z mojego doświadczenia wynika, że tych problemów będzie 10-20
razy więcej niż jesteśmy w stanie przewidzieć. To z kolei przekłada się na wiele dni kodowania, albo
framework znowu będzie wymagał wiedzy magicznej.

Pozdrawiam

[krzyszp]

Problemy z bazą, które opisujesz wystąpią tak samo, przy plikach tekstowych (a nawet prędzej, w przypadku gdy dwa kawałki kodu będą chciały się do nich dostać w tym samym czasie).

Niemniej wydaje mi się, że popełniasz błąd w założeniach.
Jeżeli napiszesz serwer, który jednocześnie ma dodawać zadania, walidować wyniki, prezentować dane, itd. to powstanie kobyła potrzebująca xxxMB (setek) megabajtów do pracy... IMHO, zdecydowanie lepszym rozwiązaniem jest stworzenie zestawu narzędzi przeznaczonych do wykonania konkretnego zadania i "zniknięcia" z pamięci - co zresztą wcale nie wyklucza stworzenia GUI dla całości, wywołującego konkretny programik wtedy, gdy jest potrzebny :)
No tak, ale w takim wypadku otrzymamy... BOINC ;)

Oczywiście zgadzam się z Tobą, że niektóre rozwiązania w serwerze BOINC wprawiają w przerażenie, np właśnie braki przy imporcie danych, które Ciebie zastopowały, ale czy nie lepiej w takim przypadku po prostu poprawić tę część kodu i wysłać poprawkę społeczności?

Potwierdzam, że chyba największym minusem serwera BOINC jest... brak porządnego przewodnika po instalacji i konfiguracji oraz dodawaniu projektów, napisanego "dla ludzi".
Mam zamiar nad tym popracować (na tę chwilę udało mi się spokojnie postawić serwer na wirtualce, aczkolwiek nie miałem czasu pobawić się dodawaniem próbek).

Dla Twojej informacji (albo innych chętnych) - stawiałem na Debianie 7 i pierwszy (drobny) problem był taki, że trzeba zdecydowanie pododawać wszystkie wymagane biblioteki zanim zainstaluje się serwer.

Kod [Zaznacz] Rozwiń

m4, make, dh-autoreconf, pkg-config, git, vim oraz:

Kod [Zaznacz] Rozwiń

libapache2-mod-php5
mysql-server-5.1
libmysqlclient-dev
php5-mysql
php5-cli
php5-gd
phpmyadmin
python
python-mysqldb
libssl-dev

[Karlik]

Zastanawiam mnie trochę Twoja awersja do logów, tak jakby ich analiza (nawet jeśli są sensownie przygotowane) była jakimś koszmarem, a to raptem kilka grepów/sedów/awków najczęściej ;)
Jeżeli nie baza danych/pliki tekstowe to gdzie chcesz trzymać te konfiguracje? Przecież gdzieś one się muszą znaleźć. Jeżeli nawet będą to pliki binarne (własne) to i tak przecież zapis jest obarczony jakimś ryzykiem, że filesystem coś napsoci (chociaż większa szansa, że dysk sam w sobie w krytycznej sytuacji) - a traci się bardzo dużo: łatwość przeglądania, porównywania, poprawiania konfiguracji "w locie", zawsze będzie wymagana Twoja aplikacja a to możnaby np. zrealizować jakimś skryptem.

[krzyszp]

Ależ ja nie mam awersji do zapisu logów w plikach tekstowych :)
Po prostu preferuję zapis danych konfiguracyjnych w bazie, skoro i tak program ma ją wykorzystywać i o tym piszę ;)

[mariotti]

Ależ ja nie mam awersji do zapisu logów w plikach tekstowych :)
Po prostu preferuję zapis danych konfiguracyjnych w bazie, skoro i tak program ma ją wykorzystywać i o tym piszę ;)

Chyba chodziło o moją awersję :D
Wszystko przeczytałem, ale już padam. Muszę wszystko przetrawić na spokojnie i jutro odpiszę :)
Pozdrawiam

[mariotti]

Za bardzo kombinujesz... Co ma aplikacja licząca do serwera i jakie konfigurowanie IP serwera w klientach?

Moim zdaniem upraszczam. Teraz BOINC ma serwer składający się z wielu
rodzimych i zewnętrznych programów. Po stronie komputera liczącego
jest podobnie: manager, klient i aplikacje liczące. Chcę to uprościć:
Serwer to jedna aplikacja, klient to druga aplikacja i koniec, nic
więcej, ewentualne dodatkowy serwer pomagający zarządzać ludziom wieloma
klientami gdy są za maskaradą. Czyli maksymalnie 3 programy.

Serwer musi obsłużyć zaledwie kilka zdarzeń:  wyślij aplikację, wyślij WU, przyjmij wynik, sprawdź/porównaj wyniki (walidacja), przyjmij kod błędu gdy coś się wysypie.

Musi wiele więcej. Gdy wydaje się polecenia doświadczonemu pracownikowi, to
taki schemat jak napisałeś wystarczy - pracownik domyśli się szczegółów.
Aplikacja komputerowa - nie. Z założenia nie ma być pobierania aplikacji (chyba
że aplikacja pobierze samą siebie gdy będzie nowa wersja). Generalnie duża
ilość różnych zdarzeń świadczy o dużych możliwościach dostosowania aplikacji
do potrzeb różnych projektów.

Klient podobnie: przyjmij aplikację, przyjmij WU, oblicz, odeślij wynik lub kod błędu i w zasadzie to jest miniumum.

Może i tak, ale nie chodzi o minimum. Chodzi o coś w miarę wypasionego. Do Perfta
minimalny framework w dwa-trzy dni napisałbym, ale nikt inny na tym swojego projektu
nie postawiłby.

Klient podłącza się do www projektu i to wolontariusz decyduje do jakiego projektu się podłącza.

Tutaj wolontariusz będzie ściągał aplikację "na pulpit" i dwa razy na niej klikał. Aplikacja
się uruchomi i przejdzie do tacki systemowej. Jak wolontariusz zainteresuje się bliżej,
to aplikację dostosuje do możliwości swojego komputera. Więc aplikacja będzie musiała mieć
wbity adres serwera, przynajmniej jednego z klonów.

Admin z poziomu serwera do tego nic nie ma. Może najwyżej kogoś zbanować za cheating.

No tak, admin w takim scenariuszu nic do tego nie ma. Ale ktoś czasami będzie chciał
postawić na tym malutki projekt, np. miesiąc obliczeń na 20 komputerach. Może coś
takiego będzie chciał zrobić jakiś student na pracę naukową. Te 20 komputerów
pozyska od znajomych, może z pracy, może ze szkoły, może weźmie też swoje z domu. Wtedy
zmodyfikowaną aplikację zaniesie na te 20 komputerów i zainstaluje sam, zamiast
znajomych zmuszać do ściągania ze strony :)

Problemy z bazą, które opisujesz wystąpią tak samo, przy plikach tekstowych (a nawet prędzej, w przypadku gdy dwa kawałki kodu będą chciały się do nich dostać w tym samym czasie).

Zgadza się, ale w przypadku jednej aplikacji, bez względu czy konfiguracja będzie
w bazie czy w plikach tekstowych, synchronizacja jest łatwiejsza w wykonaniu i
potem dostosowanie aplikacji do nietypowych projektów też będzie łatwiejsze. W sumie
sama rozbudowa frame-worka będzie też łatwiejsza.

Niemniej wydaje mi się, że popełniasz błąd w założeniach.
Jeżeli napiszesz serwer, który jednocześnie ma dodawać zadania, walidować wyniki, prezentować dane, itd. to powstanie kobyła potrzebująca xxxMB (setek) megabajtów do pracy... IMHO,

Jak weźmiemy pod uwagę że jest ogromna baza z danymi, to rozmiar aplikacji jest
relatywnie mały, nawet jak ma wiele MB.

zdecydowanie lepszym rozwiązaniem jest stworzenie zestawu narzędzi przeznaczonych do wykonania konkretnego zadania i "zniknięcia" z pamięci - co zresztą wcale nie wyklucza stworzenia GUI dla całości, wywołującego konkretny programik wtedy, gdy jest potrzebny :)
No tak, ale w takim wypadku otrzymamy... BOINC ;)

Niekoniecznie byłby to BOINC, można wprowadzić wiele istotnych zmian. Po
prostu ja widzę dwa/trzy problemy w takim rozwiązaniu:
1) dużo pracy dla twórców takiego oprogramowania
2) trudne stawianie aplikacji na czymś takim
3) pracochłonna rozbudowa frame-worka

Oczywiście zgadzam się z Tobą, że niektóre rozwiązania w serwerze BOINC wprawiają w przerażenie, np właśnie braki przy imporcie danych, które Ciebie zastopowały, ale czy nie lepiej w takim przypadku po prostu poprawić tę część kodu i wysłać poprawkę społeczności?

Zastopowało mnie coś innego: pierwszy raz błędy w tutorialu, nie miałem
wszystkich potrzebnych pakietów i nie wiedziałem że są potrzebne. Drugi raz brak
spójności pomiędzy programami narzędziowymi BOINC. BOINC ma programy i API do
dododawania zadań. Program dodający zadanie dodał i wyświetlił że wszystko
jest w porządku. Na stronie www w panelu też było widać że wszystko jest w porządku -
były zadania. Jedna wersja klienta nie wyświetlał że brakuje zadań, ale że
brak miejsca na dysku. A problem miał scheduler, nie widział że zadaia są poprawnie
dodane do bazy, bo mu znak \r przeszkadzał. Zastopował mnie dwa razy brak spójności
pomiędzy programami i dokumentacją.

Czy nie lepiej poprwić BOINC? Wątpię żebym zdołał się połapać w jego kodzie.

Potwierdzam, że chyba największym minusem serwera BOINC jest... brak porządnego przewodnika po instalacji i konfiguracji oraz dodawaniu projektów, napisanego "dla ludzi".

A może problemem jest właśnie to że są tutiriale? Ja jakiś znalazłem, ale
zamiast trafić na autoryzowaną strone, to robiłem według znalezionego.
Tutorial w sieci powinien być jeden, przygotowany przez autorów, bo tylko
oni wiedzą jak najlepiej używać frameworka... Jako ciekawostkę podam, że
trafialem też na tutorial do BOINCa, w którym autor opisywał "że dobrze to
można zrobić kobiecie a nie postawić serwer" :)

Mam zamiar nad tym popracować (na tę chwilę udało mi się spokojnie postawić serwer na wirtualce, aczkolwiek nie miałem czasu pobawić się dodawaniem próbek).

Nie wiem czy to dobry pomysł. Byś musiał śledzić zmiany. Jak coś
zmienią, to też powinieneś zmienić w tutorialu, w przeciwnym razie
wprowadzasz kogoś w błąd. Moim zdaniem dobry tutorial mogą zrobić
tylko autorzy.

Dla Twojej informacji (albo innych chętnych) - stawiałem na Debianie 7 i pierwszy (drobny) problem był taki, że trzeba zdecydowanie pododawać wszystkie wymagane biblioteki zanim zainstaluje się serwer.

Kod [Zaznacz] Rozwiń

m4, make, dh-autoreconf, pkg-config, git, vim oraz:

Kod [Zaznacz] Rozwiń

libapache2-mod-php5
mysql-server-5.1
libmysqlclient-dev
php5-mysql
php5-cli
php5-gd
phpmyadmin
python
python-mysqldb
libssl-dev

Nom pierwsze przez co trzeba przebrnąc w przypadku BOINC, to lista
niezbędnychy pakietów. Drugi problem to dostosowanie webserwera,
uprawnień, itd.

Krzychu 100% racji!
Nie widzę problemu by serwer trzymał konfig w bazie danych i konfigurowalny był plikiem wykonywalnym z konsoli. Do tego nakładka graficzna wywołująca konsolowy program z odpowiednimi parametrami linii poleceń... i wszystko.

Bo w dosłownym rozumieniu to nie jest problemem. To bylo napisane w określonym
konteście i z kontekstu wynikalo o jakie problemy chodzi :)


Pozdrawiam

[Szopler]

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... ;)
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.) 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.