BOINC@Poland

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

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...?

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/

Cytat: Dario666 w 27 Sierpień 2013, 14:56
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;

Cytat: Dario666 w 27 Sierpień 2013, 14:56
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.
   

Cytat: Dario666 w 27 Sierpień 2013, 14:56
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.

Cytat: Dario666 w 27 Sierpień 2013, 14:56
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

Cytat: andy101fah w 27 Sierpień 2013, 15:10
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

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

Cytat: krzyszp w 27 Sierpień 2013, 16:58
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.

Cytat: krzyszp w 27 Sierpień 2013, 16:58
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.

Cytat: krzyszp w 27 Sierpień 2013, 16:58
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?

Cytat: krzyszp w 27 Sierpień 2013, 16:58
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.

Cytat: krzyszp w 27 Sierpień 2013, 16:58
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ć.

Cytat: krzyszp w 27 Sierpień 2013, 16:58
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.

Cytat: krzyszp w 27 Sierpień 2013, 16:58
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ć.

Cytat: krzyszp w 27 Sierpień 2013, 16:58
Wiem, jestem upierdliwy :)

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

Cytat: krzyszp w 27 Sierpień 2013, 16:58
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.

Cytat: krzyszp w 27 Sierpień 2013, 16:58
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ć.

Cytat: krzyszp w 27 Sierpień 2013, 16:58
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?

Cytat: krzyszp w 27 Sierpień 2013, 16:58
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.

Cytat: krzyszp w 27 Sierpień 2013, 16:58
To są chyba największe (z mojego punktu widzenia) braki w BOINC...

Dzięki i pozdrawiam.

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ć...

Cytat: krzyszp w 27 Sierpień 2013, 19:10
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.

Cytat: krzyszp w 27 Sierpień 2013, 19:10
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.

Cytat: krzyszp w 27 Sierpień 2013, 19:10
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 :)

Cytat: krzyszp w 27 Sierpień 2013, 19:10
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

Cytat: andy101fah w 27 Sierpień 2013, 15:10
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.

Cytat: andy101fah w 27 Sierpień 2013, 15:10
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.

Cytat: andy101fah w 27 Sierpień 2013, 15:10
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

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

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?

Cytat: krzyszp w 27 Sierpień 2013, 23:52
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

Cytat: goofyx w 28 Sierpień 2013, 00:01
ad <- 1
Firebird też jest open source ;)

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

Cytat: goofyx w 28 Sierpień 2013, 00:01
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...

Cytat: goofyx w 28 Sierpień 2013, 00:01
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???

Cytat: goofyx w 28 Sierpień 2013, 00:01
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...

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ą.

Cytat: krzyszp w 28 Sierpień 2013, 00:30

Cytat: goofyx w 28 Sierpień 2013, 00:01
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.

Cytat: goofyx w 28 Sierpień 2013, 00:44

Cytat: krzyszp w 28 Sierpień 2013, 00:30

Cytat: goofyx w 28 Sierpień 2013, 00:01
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?

Cytat: goofyx w 27 Sierpień 2013, 23:46
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.

Cytat: goofyx w 27 Sierpień 2013, 23:46
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.

Cytat: goofyx w 27 Sierpień 2013, 23:46
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ą.

Cytat: goofyx w 27 Sierpień 2013, 23:46
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 :)

Cytat: goofyx w 27 Sierpień 2013, 23:46
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

Cytat: mariotti w 28 Sierpień 2013, 15:40
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.

Cytat: mariotti w 28 Sierpień 2013, 15:40
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.

Cytat: mariotti w 28 Sierpień 2013, 15:40

Cytat: goofyx w 27 Sierpień 2013, 23:46
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.

Cytat: mariotti w 28 Sierpień 2013, 15:40

Cytat: goofyx w 27 Sierpień 2013, 23:46
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.

Cytat: mariotti w 28 Sierpień 2013, 15:40

Cytat: goofyx w 27 Sierpień 2013, 23:46
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.

Cytat: mariotti w 28 Sierpień 2013, 15:40

Cytat: goofyx w 27 Sierpień 2013, 23:46
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.

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.

Cytat: goofyx w 29 Sierpień 2013, 00:33
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ę.

Cytat: goofyx w 29 Sierpień 2013, 00:33
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ą.

Cytat: goofyx w 29 Sierpień 2013, 00:33
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.

Cytat: goofyx w 29 Sierpień 2013, 00:33
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.

Cytat: goofyx w 29 Sierpień 2013, 00:33
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.

Cytat: goofyx w 29 Sierpień 2013, 00:33
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.

Cytat: goofyx w 29 Sierpień 2013, 00:33
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.

Cytat: goofyx w 29 Sierpień 2013, 00:33
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ć.

Cytat: goofyx w 29 Sierpień 2013, 00:33
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.

Cytat: goofyx w 29 Sierpień 2013, 00:33
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.

Cytat: goofyx w 29 Sierpień 2013, 00:33
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.

Cytat: goofyx w 29 Sierpień 2013, 00:33
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.

Cytat: goofyx w 29 Sierpień 2013, 00:33
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.

Cytat: goofyx w 29 Sierpień 2013, 00:33
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ć.

Cytat: goofyx w 29 Sierpień 2013, 00:33
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 :)

Cytat: goofyx w 29 Sierpień 2013, 00:33
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 :)

Cytat: goofyx w 29 Sierpień 2013, 00:33
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.

Cytat: goofyx w 29 Sierpień 2013, 00:33
A tak naprawdę sama aplikacja obliczająca nie potrzebuje API.

To prawda.

Cytat: goofyx w 29 Sierpień 2013, 00:33
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.

Cytat: goofyx w 29 Sierpień 2013, 00:33
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.

Cytat: goofyx w 29 Sierpień 2013, 00:33
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.

Cytat: goofyx w 29 Sierpień 2013, 00:33
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.

Cytat: goofyx w 29 Sierpień 2013, 00:33
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.

Cytat: goofyx w 29 Sierpień 2013, 00:33
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.

Cytat: goofyx w 29 Sierpień 2013, 00:33
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.

Cytat: goofyx w 27 Sierpień 2013, 23:46
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

Cytat: mariotti w 29 Sierpień 2013, 04:05Moż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.

Cytat: Karlik w 29 Sierpień 2013, 10:39

Cytat: mariotti w 29 Sierpień 2013, 04:05Moż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

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

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.

Cytat: Gołąbpocztowy w 29 Sierpień 2013, 12:18
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.

Cytat: krzyszp w 29 Sierpień 2013, 11:52
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

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

Cytat: Karlik w 29 Sierpień 2013, 14:40
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

Oj, pojechałeś...

CytatMyś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...

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

Nie prawda...

CytatPotem 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...

Cytat2) 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ść").

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.

Cytat: krzyszp w 29 Sierpień 2013, 16:24
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?

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

Cytat: krzyszp w 29 Sierpień 2013, 16:24
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.

Cytat: krzyszp w 29 Sierpień 2013, 16:24
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.

Cytat: krzyszp w 29 Sierpień 2013, 16:24
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

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.

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

CytatW 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".

CytatWyobraż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...

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.

Cytat
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ę.

Cytat
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.

Cytat
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

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.
m4, make, dh-autoreconf, pkg-config, git, vim oraz:
libapache2-mod-php5
mysql-server-5.1
libmysqlclient-dev
php5-mysql
php5-cli
php5-gd
phpmyadmin
python
python-mysqldb
libssl-dev

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.

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

Cytat: krzyszp w 29 Sierpień 2013, 19:49
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

Cytat: Szopler w 29 Sierpień 2013, 17:25
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.

Cytat: Szopler w 29 Sierpień 2013, 17:25
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.

Cytat: Szopler w 29 Sierpień 2013, 17:25
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.

Cytat: Szopler w 29 Sierpień 2013, 17:25
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.

Cytat: Szopler w 29 Sierpień 2013, 17:25
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 :)

Cytat: krzyszp w 29 Sierpień 2013, 19:05
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.

Cytat: krzyszp w 29 Sierpień 2013, 19:05
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.

Cytat: krzyszp w 29 Sierpień 2013, 19:05
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

Cytat: krzyszp w 29 Sierpień 2013, 19:05
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.

Cytat: krzyszp w 29 Sierpień 2013, 19:05
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" :)

Cytat: krzyszp w 29 Sierpień 2013, 19:05
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.

Cytat: krzyszp w 29 Sierpień 2013, 19:05
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.

Cytat
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

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.

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?

Cytat: Tobas w 01 Wrzesień 2013, 22:50
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.

Cytat: Tobas w 01 Wrzesień 2013, 22:50
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.

Cytat: Tobas w 01 Wrzesień 2013, 22:50
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.

Cytat: Szopler w 01 Wrzesień 2013, 22:06
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?

Cytat: Szopler w 01 Wrzesień 2013, 22:06
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.

Cytat: Szopler w 01 Wrzesień 2013, 22:06
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

Cytat: mariotti w 02 Wrzesień 2013, 17:21
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)?

Cytat: mariotti w 02 Wrzesień 2013, 17:21
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.

Cytat: mariotti w 02 Wrzesień 2013, 17:21Dlaczego 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.

Cytat: mariotti w 02 Wrzesień 2013, 17:21

Cytat: Szopler w 01 Wrzesień 2013, 22:06
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:

Cytat: mariotti w 02 Wrzesień 2013, 17:21

Cytat: Szopler w 01 Wrzesień 2013, 22:06
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

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

Cytat: Karlik w 02 Wrzesień 2013, 17:46
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.

Cytat: Karlik w 02 Wrzesień 2013, 17:46
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.

Cytat: Karlik w 02 Wrzesień 2013, 17:46
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.

Cytat: Karlik w 02 Wrzesień 2013, 17:46
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ć?

Cytat: Karlik w 02 Wrzesień 2013, 17:46
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.

Cytat: Karlik w 02 Wrzesień 2013, 17:46
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.

Cytat: Karlik w 02 Wrzesień 2013, 17:46
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

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.

Cytat: mariotti w 02 Wrzesień 2013, 21:13Chciał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

Cytat: Karlik w 02 Wrzesień 2013, 22:18
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 :)

Cytat: Karlik w 02 Wrzesień 2013, 22:18
, 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.

Cytat: Karlik w 02 Wrzesień 2013, 22:18
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ę.

Cytat: Karlik w 02 Wrzesień 2013, 22:18
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.

Cytat: Karlik w 02 Wrzesień 2013, 22:18
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.

Cytat: Karlik w 02 Wrzesień 2013, 22:18
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.

Cytat: Karlik w 02 Wrzesień 2013, 22:18
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?

Cytat: Karlik w 02 Wrzesień 2013, 22:18
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.

Cytat: Karlik w 02 Wrzesień 2013, 22:18
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 :/

Cytat: Karlik w 02 Wrzesień 2013, 22:18
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

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ę?

Cytat: krzyszp w 03 Wrzesień 2013, 00:10
Myślę, że za bardzo odeszliście w teorię ;)

Odeszliśmy, ale to chyba dobrze :)

Cytat: krzyszp w 03 Wrzesień 2013, 00:10
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.

Cytat: krzyszp w 03 Wrzesień 2013, 00:10
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?

Cytat: krzyszp w 03 Wrzesień 2013, 00:10
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.

Cytat: krzyszp w 03 Wrzesień 2013, 00:10
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)

Cytat: krzyszp w 03 Wrzesień 2013, 00:10
4. Manager zarządza podziałem czasu CPU.

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

Cytat: krzyszp w 03 Wrzesień 2013, 00:10
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.

Cytat: krzyszp w 03 Wrzesień 2013, 00:10
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:

Cytat: krzyszp w 03 Wrzesień 2013, 00:10
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