Zastępstwo Poradnka

[qmic]

Biorąc pod uwagę że goście z Debiana pojechali po Fedorze (patrz wątek Fafig - dlaczego nie lubię Debiana), dość słusznie że w poradniku jest strasznie dużo elementów w trybie tekstowym, chciałbym to przyjąć na klatę i to zmienić. W związku z tym proponuję co następuje:

1) Zastąpić poradnik aplikacją w której będzie wszystko one-click

 

Samemu mnie denerwuje że przy aktualizacji / reinstalacji muszę robić tak wiele zamiast wybrać z listy operacje do wykonania i zrobić kilkoma ruchami aby to był perfect desktop.

 

Pojawia się pytanie

a) Czy jest już takie narzędzie

- jeśli nie:

Czy macie jakieś pomysły co do tego (chodzi mi o funkcjonalności itp)

 

c) czy dobrym by było pomysłem dodać do tego tzw. problem-solver, czy jest jakaś lista głupich problemów które się notorycznie pojawiają i można je naprawić skryptami ?

np. (dlaczego w Fedorze nie ma i jak zrobić aby był xorg.conf, a tu bach ciach i jest)

 

 

 

 

[thof]

IMO szkoda czasu. Poradnik jest ok, bo system trzeba poznać. Osoby, które bezmyślnie przeklejają polecenia z poradnika i tak długo na linuksie nie pociągną. Jest np. autoten z bardziej znanych i jeszcze bunny1985 coś pisał, ale projekt chyba nie wypalił.

EDIT: Ale też nie mówię, że takie coś nie ma sensu i byłoby bezużyteczne. Po prostu jest to trudne do zrealizowania ze względu na niewiedzę i lenistwo nowych użytkowników. W fedorze na starcie jest wystarczająco dużo rzeczy OOTB i jak ktoś ma chęci to sobie poradzi bez dodatkowych konfiguratorów.

[Jusko]

Cóż - takie coś jest i dobre, i złe. Złe, bo zmusza do klepania w konsoli, a no...nie każdy ma na to ochotę. Dobre, bo Linux to nie system dla idiotów i np. ja lubię zgrabne połączenie aplikacji GUI z konsolą i w Fedorze bardzo fajnie jest to połączone. Użytkownik nie może bezsensownie klikać, bo w razie awarii reinstaluje system, gdyż zabrakło mu GUI, a bez GUI nie ruszy z miejsca (dlatego ze zgrozą patrzę na aplikacje GUI do byle czego dla Ubuntu, tworzone przez fanów). Jak ktoś chce graficznych konfiguratorów i out of box, to ma Ubuntu. Fedora to drugie Ubuntu nie jest, dlatego nie poleciłbym jej początkującemu (choćby przez to, że czasem Yum chce wywalić za dużo przy --remove-leaves) a PackageKit ma swoje zaciachy (choćby mało inteligentne szukanie pakietów - jak nie znasz choćby przybliżonej nazwy pakietu, to ciężko znaleźć). Dlatego też Fedorę stawiam na równi z Debianem - w obu distrach trzeba zrobić coś samemu na piechotę, a idąc dalej - wymaga się nieco bardziej rozgarniętego usera. Dla początkującego dobre jest na start Ubuntu, a jeszcze lepiej OpenSUSE (bo ten szum wokół "ach jakże cudownego Ubuntu", skutecznie zniechęca wazeliną, jaką produkują przy promowaniu jego userzy).

 

Ewentualnie - w Ubuntu (jego polskich remixach) jest skrypt automatyzujący wszystko. Wybiera się czy pobrać javę i inne bajery. Taki skrypt w Bashu (Klik). Podmienić co trzeba i jest :-)

[DAREK WL.]

Wg mnie ; problemem nie jest to że w Fedorze trzeba coś zrobićć "na piechotę"

Nie jest problemem wyłączyć X-y i napisać w konsoli ; yum install kmod-nvidia"

Albo ; yum install zynaddsubfx . Sztuką jest to by ststem te polecenia wykonał a nie wywalał niezrozumiałymi błędami . Przewaga ubuntu nad fedora 12 polega włażśnie na tym że w ubuntu instalacja sterów nvidii , czy syntezatora dzwięku przebiega bezproblemowo[u mnie]

A na Fedorze 12 nawet pierwszy kreatorek wstępnej konfiguracji nie chce sie pojawić ,choć instalowałem zarówno 32 jak i 64-bitową wersję systemu .

W ubuntu też na przykład trzeba popracować w konsoli by potem sprawnie doinstalować np KDE 4.4 RC2 , albo 64-bitową wersję wtyczki flash , ale mółwie wam ; te polecenia w konsoli które sie wpisze są wykonywane prawidłowo . a w Fedorze

Window manager warning; buggy client sent a NETACTIVE WINDOW message with a timestamp of 0 for 080041[firstboot]
Meta window activate called by a pager with a timestamp a pager needs to be fixed .

A po wykonaniu "kmod-nvidia" jes ciemny ekran i klops

[bunny1985]

W sumie to ciągle coś się dzieje w temacie programiku:

http://github.com/Piotrek23/auto-config-pl/

 

 

 

[qmic]

W sumie to ciągle coś się dzieje w temacie programiku:

http://github.com/Piotrek23/auto-config-pl/

 

O widze ze jest fajne narzedzie. przydaloby sie to wrzucic na poczatek poradnika.

[Raven]

Na to ta aplikacja jest zdecydowanie w zbyt wczesnym stadium rozwoju. Trzeba poczekać, albo pomóc autorowi.

[thof]

I jeszcze to http://www.easylifeproject.org/

[borzole]

Jest też ciekawy z GUI, ale niezbyt działający http://code.google.com/p/ailurus/ do tego dołączone są artykuły z http://tdt.sjtu.edu.cn/ailurus/

Całość dość chaotyczna, ale interesująca.

[borzole]

@Jusko

ten skrypt w bash dla ubuntu to chyba żart

 

@bunny1985

* Na miłość boską, posprzątaj trochę te źródła bo nie wiadomo, który plik do czego tam jest i musiałem się chwilę zastanowić.

- wystarczy jak oddzielisz źródła GUI od "pluginów"

- dostać srpm byłoby szczytem mażeń

 

* Trochę nie bardzo jest ten system, że nazwa skryptu i jego opis to to samo. Przykładowo: nie można uruchomić skryptu z jakąś opcją.

 

* Mam propozycję co do pluginów. W chwili obecnej każdy plugin to jeden plik z ręcznie dodawanym opisem (zacząłem się uczyć pythona i tam na jednym pliku to się "nie da" ). Przydałby się sposób mniej inwazyjny, a jednocześnie o większych możliwościach. RPM, czy nawet wtyczki do Firefox to zwykłe archiwum zawierający kilka plików, łącznie z opisem. Można by zrobić taki prosty kontener z zip i hopa.

 

* Bym się przyłączył, tyle że założenia projektowe mnie kują w oczy i nie bardzo mam czas, ale pomarudzić zawsze można

 

ps. w kwestii formalnej: pluginy to wtyczki w formie binarnej

[Jusko]

A co z tym skryptem dla Ubuntu jest nie tak? Pytam z ciekawości, gdyż tego cuda nigdy:

 

- nie widziałem w akcji.

- nie widziałem w ogóle kodu, gdyż nie znam basha i nie ciągnie mnie do nauki go (nie ma takiej potrzeby - to, że używam Linuksa nie znaczy, że mam znać wszystko co z nim związane od kuchni ).

- tym bardziej nigdy tego cuda nie używałem. Wiem tylko, że robi furorę w polskich remiksach tego distra

[borzole]

@Jusko

Oj, mea kulpa. Kliknąłem w "demo" a tam samo menu bez działającego czegokolwiek. Odszukałem starszą wersją i tam już coś było Skrypt podobny do tego co bunny1985 pokazywał na samym początku.

 

Nie wiem jak to działa, ale napisane jest bałaganiarsko i odstrasza formatowaniem (podobno na starych unixach wcięcia nie przejdą, ale to nie jest stary unix) do tego pisanie po 10 razy tego samego bloku instrukcji, zero parametrów, nazywanie funkcji man1-7 cholera wie dlaczego i żadnej kontroli, czy się wykonało.

Każdy programuje jak potrafi, ale ten skrypt napisano składniowo w sposób bardzo początkujący i odpycha by coś poprawiać/zaktualizować.

 

Przeglądałem różne tego typu skrypty i trochę mnie przeraża ich użycie. Dopóki polega to na "yum install" czy "wget http://" to pół biedy, gorzej gdy zaczynają robić coś w plikach konfiguracyjnych. Sam jestem beznadziejny w wyrażeniach regularnych, ale widzę jak niektórzy zakładają na chama, że plik tak wygląda i już. Kasują i dodają coś na wpół w ciemno. Ustawienie czegokolwiek w pliku przez skrypt to rzeźba.

[bunny1985]

* Trochę nie bardzo jest ten system, że nazwa skryptu i jego opis to to samo. Przykładowo: nie można uruchomić skryptu z jakąś opcją.

 

Skrypty z opcjami. Fajnie, ale gdzie ustawiać te opcje w graficznym menedżerze dla każdego skryptu? Nie wydaje mi się ,żeby to był dobry pomysł. W końcu to jest projekt dla naprawdę początkujących, albo naprawdę leniwych. Jak ktoś bardzo chce ,to może sobie przez konsolę skrypty odpalać.

Generalnie sam pomysł :nazwa znaczy opis upraszcza sprawę. Można kombinować ale doszedłem do wniosku,że jest to przerost formy nad treścią. Sam program w c++, ma być bardzo prosty. Mógłbym pododawać w menu odnośniki do stron z programem/opisem, opis samego pluginu, kolory ,czy co tam jeszcze. Tylko po co?

A To Twój cytat z innego tematu :

...tylko ze doszedł problem aktualizacji i samoopisu takiego pliku. Ja bym poprzestał na samoopisowej nazwi, ale bunny1985 chce sobie nadłożyć drogi.

Daj boziu mu ją znaleźć

Fakt. Program jest napisany niechlujnie i nawet ostatnio zastanawiałem się , czy by go nie przepisać, ale dopóki spełnia swoją role - odpala skrypty to nie widzę większego sensu.

* Na miłość boską, posprzątaj trochę te źródła bo nie wiadomo, który plik do czego tam jest i musiałem się chwilę zastanowić.

Marudzenie Spec jest. Także srcrpm prawie też jest.

Na temat programu nie trzeba się dużo zastanawiać , bo plik auto-config-pl.pro mówi chyba wszystko:

SOURCES += main.cpp \

menuwindow.cpp \

editd.cpp

HEADERS += menuwindow.h \

editd.h

FORMS += menuwindow.ui \

editd.ui

RESOURCES += zasoby.qrc

 

* Mam propozycję co do pluginów. W chwili obecnej każdy plugin to jeden plik z ręcznie dodawanym opisem (zacząłem się uczyć pythona i tam na jednym pliku to się "nie da" ). Przydałby się sposób mniej inwazyjny, a jednocześnie o większych możliwościach. RPM, czy nawet wtyczki do Firefox to zwykłe archiwum zawierający kilka plików, łącznie z opisem. Można by zrobić taki prosty kontener z zip i hopa.

Nie wiem,czy dobrze zrozumiałem, ale jesłi chodzi o "pluginy" złożone z wielu plików, to też nie jest zasadniczy problem. Przykładowo całość skryptów pythona możemy umieśić w katalogu i w pluginach :

wrzucić jeden pliku uruchamiający || umieścić skrypt , który wejdzie do katalogu i odpali program|| zrobić dowiązanie do danego pliku w katalogu

Jeśli chodzi zaś o paczki rpm z dodatkowymi pluginami to też nie jest problem,żeby takową stworzyć. De fakto jest to pewien pomysł do przyszłego wykorzystania.

Opis w plikach jest już nie ważny- teraz nazwa pliku jest opisem wyświetlanym w programie, natommist paczka typu: auto-config-pl-plugins-Gnome_scrpits.rpm była by całkiem fajnym rozwiązaniem.

[borzole]

Ja nie twierdzę, że tak jak jest teraz jest źle (jak coś działa to musi być ok), ale można to rozwinąć i uelastycznić. Kontynuuj projekt w takiej jak jest formie, ale pomyśl co by tu ulepszyć.

Jeśli miałbym być szczery, to w drugiej wersji, nadałbym aplikacji sporego rozmachu. Dodać bazę ustawień aplikacji, udostępnić interfejs bez X, wyświetlić opisowe info o działaniu pluginu, uzależnić aktywację pluginu w zależności od uprawnień usera.

Zasadniczo to jest problem projektowy, bo połączyć potem funkcje A do B potrafi już każdy. Niestety nigdy nie uczyłem się o wzorcach projektowych/konstrukcyjnych i zawsze coś robię na "chyba tak będzie ok".

 

* Myślałeś o przejściu na pythona? Nie potrzeba kompilacji, rezultat widoczny od razu, jedna wersja na obie architektury.