Witaj na Forum Linuxiarzy
Zanim zalogujesz się, by pisać na naszym forum, zapoznaj się z kilkoma zasadami savoir-vivre'u w dziale Administracja.
Wiadomości z problemami zamieszczone w wątku "Przywitaj się" oraz wszelkie reklamy na naszym forum będą usuwane.

Propozycje do kolejnego wydania

Zaczęty przez sir_lucjan, Marzec 25, 2013, 01:38:07 PM

Poprzedni wątek - Następny wątek

sir_lucjan

witam.

Jestem b. zadowolony z dystrybucji.

Używałem mandrive linux mint.

Aby używać sparky musiałem doinstalować pulse audio serwer bo nie moglem odpalić skype.

Skype nie instaluję się automatyczne.

warto by doinstalować zarządzanie energią dla laptopa-bo coraz więc ich się używa.

może aplet pogody.

wprowadzilem autologowanie zgodnie z -  http://forum.dug.net.pl/viewtopic.php?pid=231261

Dla początkujących może być problem z instalacją.

Poza tym rewelacja, polecam.
Dell Inspiron 15-3542 (3542-2538) || Arch Linux || linux-lucjan-git

marcinkiewiczm

#1
witam.

Jestem b. zadowolony z dystrybucji.

Używałem mandrive linux mint.

Aby używać sparky musiałem doinstalować pulse audio serwer bo nie moglem odpalić skype.

Skype nie instaluję się automatyczne.

warto by doinstalować zarządzanie energią dla laptopa-bo coraz więc ich się używa.

może aplet pogody.

wprowadzilem autologowanie zgodnie z -  http://forum.dug.net.pl/viewtopic.php?pid=231261

Dla początkujących może być problem z instalacją.

Poza tym rewelacja, polecam.

urbek

#2
Witam:) SparkyLinux to System lekki i dobrze działający nawet na starcszych maszynach a środowisko XFCE jest również dość lekkim środowiskiem i zarazem bardzo dobrze rozwijającym się w ostatnim czasie i chętnie bym zobaczył jego nową wersję w sparkym, ale nie wiem czy na nasze skromne warunki nie będzie to za wiele. Niedawno do sparky dołączyło środowisko mate i również podoba mi się ta wersja pulpitu. Nowe wydanie z tego co pavroo zdradził już trochę wczesniej ma bazować na debianie testowym "Jessie" i tu właśnie przydałby się niestandardowy kernel, bo skoro sparky dobrze działa na starszych maszynach nawet takich z prockami P3, które nie obsługują PAE(Physical Address Extension) a standardowe kernele go mają z urzędu to czemu nie zastosować rozwiązania , które nie tylko ten problem wyeliminuje, ale wniesie nową jakość. Wiem, że kernel w wersji 3.8 jaki miałem możliwość sprawdzić w systemie Bridge Linux bez problemu działał na P3. Własne repo to piekna myśl, ale ma sens wtedy jak stworzymy i wrzucimy do niego trochę swoich autorskich pakietów czy skryptów, których nie ma nigdzie indziej, lecz byłby to świetny krok, który bez wątpienia podkreśliłby własną tożsamość SparkyLinux.

MoroS

#3
Witam.



W temacie własnego repozytorium mogę dodać tylko tyle, że prace są w toku. Niestety sprawa nie jest taka prosta, z uwagi na to, iż przy różnych podejściach do tematu będziemy musieli się zmierzyć z różnymi problemami.



Przykładowo, gdybyśmy zdecydowali się na w pełni własne repozytorium, to konieczne byłoby posiadanie potężnego (w sensie przestrzeni dyskowej i transferu) serwera, który wszystko by pomieścił. Utrzymanie takie repozytorium pochłaniałoby też sporo czasu. W tej sytuacji jednak nie byłoby problemów z wersjonowaniem poszczególnych paczek i poleganiu na repozytoriach Debiana.

Z drugiej strony jest model na tzw. "nakładkę", czyli nadal korzystamy z repozytorium Debiana, ale dodatkowo włączamy też nasze repozytorium z dodatkowymi paczkami oraz paczkami w wersjach nowszych. Wymaga mniejszych zasobów, mniej czasu, ale pojawia się problem wersjonowania, gdzie repozytorium Debiana może raz na jakiś czas przykrywać nasze zmiany w paczkach, w przypadku gdy wydadzą paczkę z większym numerem wersji, niż mamy my (a my musimy utrzymać ten sam numer wersji, reprezentujący wersję danego oprogramowania + odpowiedni dopisek, aby nasza paczka była brana przez APT jako pierwsza w kolejności... w tym przypadku nowy numer wersji w repo Debiana skutkuje zignorowaniem naszych zmian do momentu wydania przez nas paczki w odpowiedniej wersji z dopiskiem). Nie muszę chyba wspominać, że przy pakietach podstawowych sprawa może okazać się katastrofalna w skutkach dla użytkowników (albo śmieszna co najmniej: wyobraźcie sobie, że raz system nazywa się i przedstawia jako "Sparky Linux", a raz jako "Debian", pomiędzy poszczególnymi update'ami).



Tak, czy inaczej prace nad własnym repo trwają. Prace nad autorskimi rozwiązaniami też, ale nie będę tutaj za dużo zdradzał. Mamy parę pomysłów na to, jak uczynić Sparkiego łatwiejszym w obsłudze. ;)
Nie ma rzeczy niemożliwych. Są tylko takie, których jeszcze nie umiemy wykonać. ;)

Albedo 0.64

#4
@urbek: Własne repozytorium to dość kosztowne podkreślanie tożsamości. Nie ma powodów by rezygnować z repo Debiana a dodanie własnego na wzór ubuntowych ppa jest chyba najbardziej optymalnym rozwiązaniem.
MX Linux Xfce
Linux registered user 556565

urbek

#5
@albedo: Jak wyżej napisałem własne repo ma sens wtedy jak stworzymy autorskie(własne) pakiety lub skrypty, których próżno szukać w repo debiana, więc masz rację, że na razie nie ma powodów, by zmieniać ten stan rzeczy. Myślę jednak, że wraz z rozwojem projektu trzeba będzie kiedyś taką opcję przynajmniej poważnie rozważyć, gdyż zaczną powstawać pakiety pisane dla sparkylinux i jedna z form własnego repo, które przedstawił MoroS mogła by zostać przyjęta. @MoroS

Quote:

Tak, czy inaczej prace nad własnym repo trwają. Prace nad autorskimi rozwiązaniami też, ale nie będę tutaj za dużo zdradzał. Mamy parę pomysłów na to, jak uczynić Sparkiego łatwiejszym w obsłudze


Wpadnij czasem na irc w wolnej chwili, gdyż na naszym kanale też już jest kilka osób, które mogły by pomóc w realizacji niektórych pomysłów i ewentualnie zgłosć własne pomysły.

Alphanumerix

#6
Jak dla mnie ogromnym plusem jest świetny kontakt na linii deweloperzy-społeczność :)



Cieszy mnie, że dystrybucja się rozwija.



Moim zdaniem własne repozytorium to świetny pomysł, który należy jednak odłożyć na półkę z napisem "koniecznie, lecz później". Teraz chyba nie ma na to ani środków, ani czasu, ani przede wszystkim potrzeby, by takie repozytorium utrzymywać. Wszystkie sensowne argumenty za i przeciw zostały zresztą już podane :)



Nie wiem ile kosztuje czasowo przygotowywanie nowej wersji systemu (z nowym DE), ale wydaje mi się, że troszkę za bardzo się rozdrabniacie. Jasne, to super, że jest wybór, ale już niejedno duże distro narobiło sobie takich wersji, a z czasem, gdy podrosło na siłach, to okazało się, że są one zbyt drogie w utrzymaniu (najlepszym przykładem niech będzie Linux Mint i jego "4%"). I tak zawsze znajdą się tacy, co stwierdzą, że "Sparky ssie, bo nie ma werji z forkiem forka forku gnome". Tak, czy inaczej cieszy mnie, że jest ochota, by coś robić, bo to najważniejsze :)



Sam nie wiem, co chciałbym widzieć w nowym Sparkym. Wiem za to, co chciałbym widzieć w moim distrze idealnym.



Po pierwsze - rolling release. Wg mnie to świetny model dystrybucyjny pozwalający w większym stopniu skupić się nad rozwojem dystrybucji i mniej czasu poświęcać na poprawki przy poszczególnych wersjach. Niestety, nie jest to zbyt "medialny" model wydań, ale moje idealne distro nie musi być popularne :p Zresztą, sam Debian Testing w pewnym stopniu można zaliczyć do rodziny rolling-release.



Po drugie - środowisko oparte w całości na bibliotekach QT (ale niekonieczne zbudowane na KDE), Jest kilka niezłych zamienników, na przykład mój faworyt - RazorQT). Jestem dużym fanem QT od bardzo dawna, w wolnych chwilach uczę się je wykorzystywać z użyciem C++. QT są nastawione na nowoczesność i uniwersalność i można w nich stworzyć bardzo wiele nie korzystając z niczego innego. Niestety, za wyjątkiem środowiska i aplikacji KDE nie są one jakoś rozpowszechniane, a szkoda. QT, pomijając fakt, że już w tej chwili jest dostępne na wszystkie liczące się platformy, to jako pierwsze rozpoczęło prace (i upubliczniło efekt) nad działąniem z nowym serwerem wyświetlania.



Po trzecie - stabilność i nowoczesność. Rozumiana przeze mnie oczywiście nieco inaczej, niż się na ogół o tym myśli. Debian Stable jest więcej niż stabilny, to beton z którego niewiele może się ukruszyć lub zepsuć. Debian Testing? Bardzo stabilna dystrybucja, wciąż jednak kosztem nowego softu. Aktualnie testuję dystrybucję Siduction (ma nawet wersję z RazorQT <3 :D) i muszę powiedzieć, że Debian Sid jest dobrą bazą. Wcześniej korzystałem m.in. z Arch Linuxa, który jeśli chodzi o świeżość softu, jest królem. I o dziwo nie został uwalony przez aktualizację ani razu, chociaż często można o tym usłyszeć, jaki to Arch jest zły przez to, że się samo psuje. Wystarczyło z mojej strony czytać komunikaty na stronie projektu i nie dotykać repozytorium "unstable" :p Widać innych kusiło... Akurat Sparky, do momentu posiadania własnego repozytorium manewry na tym polu ma bardzo ograniczone, jednak gdyby już do własnego repo doszło, to najlepszy model (moim zdaniem) to najnowsze stabilne i testowe aplikacje + stabilna, ociągająca się o tydzień, do miesiąca w stosunku do oficjalnych wydań "baza" systemowa.



Cóż więcej mogę powiedzieć... Nie ma chyba wstydu zapatrywać się na innych. Tak więc najbardziej zbliżonym do ideału zestawem aplikacji "startowych" jak dla mnie jest to, co zastałem w Siduction z RazorQT - wszystko bazujące na QT, jednocześnie niezależne od KDE. Całkiem spory sentyment żywię też do ChakraLinux, który to posiada jedną wspieraną architekturę i jedno wspierane środowisko. Test wersji LiveCD polecam każdemu, przyjemność z pracy jest niesamowita, a tą wierność dla jednej jedynej wersji czuć na każdym kroku. Plus rozwijany jest całkiem fajny system "bundli", który nie zaśmieca systemu bibliotekami, a te wymagane w zależnościach >zawsze< są usuwane razem z aplikacją.

MoroS

#7
Długi post. ;) Mogę tylko powiedzieć, że z mojej perspektywy repozytorium wcale nie jest "konieczne, ale później", a raczej "konieczne, jak najszybciej". Głównie z uwagi na model wprowadzania zmian, jak chciałbym zaproponować, czyli: podstawa Debian Testing + nasze repozytorium z modyfikacjami. Koszt materialny niewielki, ale dojdą dodatkowe czynności z kontrolowaniem wersji pakietów (konflikty wersji pomiędzy naszym repo, a repo Debiana, ale to w sumie nic czego dobrze napisany soft by nie załatwił).



Nie wiem dokładnie jaką Pavroo przyjął politykę z wersjami, ale nie przewiduję, aby miało ich powstać więcej (tak mi się przynajmniej wydaje). Wraz z repozytorium widziałbym nawet redukcję liczby wersji do dwóch: x86 i x86_64, gdzie instalowana jest tylko podstawa, a rodzaj instalacji (pulpit + zestaw aplikacji: np. wybieramy LXDE i dodatkowo rolę "biurowy desktop", "desktop do grania", "desktop studio" - oczywiście to przykładowe konfiguracje, które wymyśliłem na poczekaniu) wybierze sam użytkownik. Oczywiście wszystko można ładnie zorganizować meta-pakietami i ich zależnościami (vide Ubuntu, np. ubuntu-desktop, kubuntu-desktop, lubuntu-desktop, ubuntu-server - meta-pakiety z różnymi wersjami tego samego systemu).

Przy takim układzie instalacja "od zera" polegałaby na ustawieniu środowiska początkowego (partycjonowanie, instalacja bazy systemu), do którego instalator zrobi chroot i po prostu uruchomi np. "apt-get install sparky-lxde sparky-office-desktop". Potem już tylko konfiguracja sterowników (taki półautomat, coś jak w Ubuntu dla sterowników własnościowych, ale jeszcze w trakcie instalacji), lokalizacji i boot managera i po krzyku. ;)



Na przygotowanie rzeczy, o których wspomniałem potrzeba czasu, ale jednorazowo. Każda następna zmiana realizowana w takim modelu jest znacznie szybsza. Tak bym przynajmniej to widział, ale decyzja nie należy do mnie.



Co do dystrybucji idealnej:

- rolling release - HELL YEAH!! ;) po co czekać Bóg wie ile czasu na nowe wersje oprogramowania, jak można je udostępnić od razu? Czemu Ubuntu się przed tym tak broni? Nie wiem... Przecież i tak co najmniej połowa użytkowników instaluje repozytoria PPA, żeby mieć przynajmniej namiastkę aktualizacji na bieżąco.

- oparcie wszystkiego na Qt - muszę przyznać, że Qt wydaje się bardziej zwarte i dojrzałe od GTK (RazorQT też wygląda ładnie, aż spróbuję), a przy okazji przyjemniejsze w użyciu przy tworzeniu aplikacji (część rzeczy, które obecnie tworzę dla Sparkiego bazuje na Qt i pisze mi się w nim znacznie przyjemniej niż w GTK).

- stabilność i nowoczesność - tutaj proponowałbym prosty model repozytorium: stable i testing; Stable - oprogramowanie stabilne, przetestowane i "ma działać", testing - oprogramowanie niestabilne, w trakcie przygotowania bądź testów, "używaj na własną odpowiedzialność"; Dodatkowo wcześniej czy później będziemy musieli się zmierzyć z obsługą UEFI (tutaj też możliwe są różne podejścia: albo boot manager wspierający EFI, np. GRUB 2, albo odpowiednia wersja samego jądra systemu z konfiguracją "EFI stub" - to akurat działa piorunująco szybko, bo EFI uruchamia od razu jądro systemu, ale na dzisiaj nie jest pozbawione problemów, np. sterowniki nVidii mają problem z działaniem w czystym EFI, chociaż udało mi się to obejść);

- z jednej strony konfigurowalność, z drugiej maksymalne uproszczenia - temat nigdy nie jest łatwy, bo ciężko tutaj znaleźć złoty środek;

- ściśle ustalony cel architektoniczy: bez rozdrabniania się na milion architektur, obsługa jednej, maksymalnie dwóch;



Taki ogólnie mam pogląd na swoją idealną dystrybucję.



I jeszcze na temat tzw. "bundli" - fajna koncepcja, ale już dość stara i ma trochę wad. Ten model dystrybucji powstał z myślą o systemie NeXTSTEP i wraz z nim został wchłonięty przez Apple (bazuje na tym współczesny Mac OS X). O ile model ten jest fajny w kontekście utrzymania (każda aplikacja ma swój zestaw bibliotek, z którym działa najlepiej, a sam system na tylko podstawowe biblioteki), o tyle ma też sporo wad:

- każda aplikacja zajmuje więcej miejsca na dysku (każda ma swoje biblioteki);

- redundancja (biblioteki mogą się wielokrotnie powtarzać w różnych aplikacjach, więc dodatkowo "wzmacnia" pierwszą wadę);

- większe zużycie pamięci RAM (zamiast ładować do pamięci jedną wersję danej biblioteki dla różnych aplikacji, ładowanych jest parę różnych wersji, bo np. każda aplikacja korzysta z innej wersji);



Wady te widać w samym Mac OS X: to pierwszy system unixowy jaki widziałem, który używa (podobnie z resztą jak Windows) pamięci swap bez powodu, kiedy nadal ma dostępną zwykłą pamięć operacyjną. Możemy tutaj dyskutować, że przecież "pamięć RAM jest tania", ale cały pomysł szlag trafia, jeżeli człowiek sobie uświadomi, że Sparky ma też działać na starszych maszynach. ;)
Nie ma rzeczy niemożliwych. Są tylko takie, których jeszcze nie umiemy wykonać. ;)

urbek

#8
Witam:)

W pierwszej kolejności odniosę się do liczby wersji i rozdrobnienia, zauważyłem, testując wszystkie wersje bez wyjątku, że wersja SparkyLinux 2.1.1 ,,Eris" Ultra Edition nie ma aż tak bardzo znaczących zysków w wydajności do wersji SparkyLinux 2.1 ,,Eris" e17/LXDE i w moich testach na dwóch starszych maszynach czasem nawet lepiej sprawowała sie ta druga. Idea lekkości jest jak najbardziej słuszna i warta kontynuacji. W moim mniemaniu obie te wersje można by połączyć i zrobić wersję lekką, przyjazną starszym maszynom, która będzie kontynuować to co już osiągnięto.

Wersja mate jako fork gnome2 mnie osobiście się podoba i używam jej na codzień, lecz ważniejsze od mojego widzimisie jest to, że środowisko mate nie stoi w miejscu a rozwija się i ten rozwój może dobrze rokować projektowi. Właśnie wyszła wersja mate 1.6, która wniosła wiele poprawek i usprawnień.

Skoro już poruszyłem temat środowisk graficznych to zainteresowała mnie propozycja środowiska razor-qt i postanowiłem sobie to zobaczyć na moich starych maszynach. Do testów posłużył mi siduction z pulpitem razor-qt i pierwsze wrażenia są bardzo dobre. Środowisko na starym desktopie z 2002r (P4 1gb. ram i zintegrowana grafika intel 845G) działa bardzo płynnie i może się podobać, aczkolwiek wydaje mi się, że jest jeszcze mało konfigurowalne, co jednak może być spowodowane moją jego zupełną nieznajomością i faktem, że to nowy projekt który na pewno warty jest uwagi. Porównując razor-qt do innych środowisk, które na tym zabytkowym niemalże sprzęcie odpalałem wypadło nadspodziewanie dobrze, gdyż na powyższej maszynie środowiska takie jak gnome3 czy cinnamon nawet nie dały rady sie uruchomić, więc w mojej ocenie pasuje ono do idei sparky jako lekkiej dystrybucji.

Gdyby przyjąć model instalacji jaki zaproponował MoroS, to można by mieć dwie wersje systemu, a jednocześnie wybór już na etapie instalacji co do pulpitu i  instalowanego oprogramowania, z którego będziemy korzystać w przyszłości . Nie wiem tylko czy musiało by się to wiązać z rezygnacją z wersji live, bo jeśli tak to sparky na pewno nie jest na to gotowy. Po pierwsze bez systemu w wersji live użytkownicy z mobilnym internetem nie mieli by możliwości instalacji, a po drugie zanim ktoś zainstaluje system na dysk to chce sobie obejrzeć jak dany system sprawuje sie na jego sprzęcie. Jeśli dodać by netinstall do sparky to świetny pomysł w mojej ocenie, ale tylko opcjonalnie.

Alphanumerix

#9
Miło mi, że Razor-QT przypadł do gustu :)



Niestety stworzenie wersji Sparkyego z nim na pokładzie może być nieco problematyczne - projekt ten jest aktualnie w fazie alfa i z każdym nowym wydaniem występuje wiele nowości, więc o obecności świeżych wersji w oficjalnych repozytoriach Debiana Testinga możemy zapomnieć. Z kolei o ile można wpakować na starcie Razora skompilowanego ze źródeł w wersji aktualnej, to nie za bardzo potrafię sobie wyobrazić proces aktualizacji w przyszłości. Potrzebne by było jakieś autorskie narzędzie. W Archu mamy od tego Yaourta lub ręczną aktualizację, ale tam priorytetem jest prostota (KISS), a nie łatwość i przyjemność użytkowania przez Kowalskiego :p Jednak ocenę trudności i opłacalności pozostawiam naszym cudnym deweloperom :)



Sam Razor jest na chwilę obecną słabo konfigurowalny. Sytuację ratuje nieco wprawdzie ręczna edycja plików konfiguracyjnych, ale i tu nie ma jeszcze szału. Nie ma się co dziwić, projekt powstał 5 września 2010r i przez prawie dwa lata był tworzony w wolnych chwilach przez bardzo wąskie grono, które dopiero ostatnio się poszerzyło. Co do celów środowiska, to wydaje się ono dążyć do funkcjonalności podobnej do LXDE, wykorzystując do tego jednak biblioteki QT. Czy jest szybszy? Ciężko powiedzieć. Pamiętaj, że Debian SID, to nie Testing. Nowszy kernel, stery i inny zestaw aplikacji początkowych (w dodatku wszystkie z jednej "stajni") może zdziałać cuda i nieźle namieszać w wynikach końcowych.



Unifikacja wersji dystrybucji w przyszłości? Wyobrażam sobie po pewnych modyfikacjach współistnienie LXDE i XFCE, ale wśród nich raczej Razor-QT z racji swojej koncentracji na wiadomych bibliotekach by nie pasował, przynajmniej wg mnie. Ale takich prób jeszcze na distrowatch nie widziałem, choć kto wie, może jest bardziej uniwersalny, niż teraz mi się wydaje? :)



Tak na marginesie - używałem do tej pory Minta KDE, ale od wczoraj to Sparky Ultra jest moim bazowym distro, a zaraz obok niego do celów "na co dzień" stanie (wracający w blasku i chwale) Arch linux. Jeszcze raz - dobra robota!

MoroS

#10
Nie unikniemy tworzenia własnych pakietów DEB, więc w pewnym momencie będzie można też dostarczyć Razor-QT. Zobaczymy, to pieśń przyszłości.



Co do obaw o problemy z LiveCD z nowym przy proponowanym przeze mnie modelu: to nie musi być netinstall LiveCD. Z tego, co pamiętam, to do pełnej pojemności płytki DVD mamy jeszcze daleko, więc możliwe, że pakiety instalacyjne się zmieszczą bez większego problemu. :)



Zobaczymy, na razie chcę postawić testowe repozytorium z meta-pakietami i spróbować zrobić instalację Sparkiego przez chroot z apt-get (pierwszy krok w stronę własnego instalatora), a potem benchmarki z porównaniem czasów startu Sparkiego systemd+udev z openrc+eudev (o ile uda się je ostatecznie skompilować, bo problemy zapewne jakieś po drodze będą). Docelowo chciałbym, żeby wszystkie zmiany trafiały do odpowiednich pakietów .deb i żeby instalacja czy tworzenie LiveCD nie polegały na kopiowaniu tego samego zestawu danych w tą i z powrotem.



Pomysłów mam sporo. Jak będzie nimi zainteresowanie, to na pewno będę próbował je realizować. ;)
Nie ma rzeczy niemożliwych. Są tylko takie, których jeszcze nie umiemy wykonać. ;)

sovtware

#11


Quote:

Cytuj z sir_lucjan w March 25, 2013, 13:38

Witam ;) Chciałbym przedstawić swoje pomysły do kolejnego wydania



1. Znieść główną moim zdaniem wadę gałęzi testing - zastosować niedystrybucyjny kernel, przynajmniej jako rzecz opcjonalną. Tutaj proponowałbym kernel liquorix. Wprawdzie aptosid czy siduction szybciej wrzucają nowe wersje - niemniej liquorix "odczekuje" i wrzuca wtedy, jak uzna, że nie będzie problemów.



2. Brakuje wydania z Xfce - w tym wypadku również nie bawiłbym się w wierność testingowi i dał nowszą wersję z repozytorium siduction - system zyskałby kolejną rzecz, która u konkurencji raczej nie występuje



3. Własne repozytorium a w nim aktualne wersje przeglądarek Firefox, Opera, Chromium, komunikatorów jak np. Kadu, czy klientów poczty jak Thunderbird.





Testing moim zdaniem bardzo dobrze ze jest na takich pakietach przynajmniej system jest dystrybucją ciągłą a Debian ma tego najwięcej co to programów co opisałeś np: opera google kadu wystarczy dodać repo i ma się zawsze aktualne wersje piszesz o programie Thunderbird lecz on jest wolniejszy od programu który według mnie jest bardzo dobry icedove więc nie ma co zmieniać to moje zdanie więc bez urazy pozdrawiam wszystkich sympatyków SparkyLinux i wszystkie osoby pracujące nad Nim

sir_lucjan

#12
Należy zacząć od faktu, że nie napisałem nic o zmianie całego bazowania, miałem na myśli tylko i wyłącznie kernel. Po drugie, testing nie jest dystrybucją ciągłą w pełnym znaczeniu tego słowa. Po trzecie, ku twojej wiadomości - Icedove to debianowy fork programu Thunderbird.
Dell Inspiron 15-3542 (3542-2538) || Arch Linux || linux-lucjan-git

sovtware

#13


Quote:

Cytuj z sir_lucjan w April 12, 2013, 12:09

Należy zacząć od faktu, że nie napisałem nic o zmianie całego bazowania, miałem na myśli tylko i wyłącznie kernel. Po drugie, testing nie jest dystrybucją ciągłą w pełnym znaczeniu tego słowa. Po trzecie, ku twojej wiadomości - Icedove to debianowy fork programu Thunderbird.


w porządku musiałem źle przeczytać mi nie przeszkadza kernel jaki jest teraz a co do programu Icedove masz rację lecz ten jest szybszy i lżejszy niż Thunderbird myślę ze nic złego nie napisałem i Cię nie obraziłem

pavroo

#14
W takim razie i ja wtrącę kilka groszy.

Własne repozytoria są jak najbardziej potrzebne na własne pakiety. Nie będzie ich dużo ale będą podkreślały tożsamość Sparka. Jako system bazowy chcę utrzymać testing, nie widzę potrzeby zmiany na sid lub powrotu do stable.

Pulpit Xfce jest w trakcie prac jako wersja społecznościowa (Community Edition).

W oczekiwaniu na Jessiego, wprowadziłem pierwsze zmiany.

Przede wszystkim wybór lokalizacji w Live - dodałem około 20, w tym polską.

http://linuxiarze.pl/obrazy/sparky/sparky-ru.png" alt="sparky-ru.png" class="bbcode_img" />

Następna zmiana to dodanie opcji uruchomienia systemu w trybie tekstowym. Umożliwia zainstalowanie Sparka bez X-ów. Przetestowałem na wirtualu z przydzieloną pamięcią RAM 128MB i CPU 720MHz.  Działa bardzo płynnie.

Jak na razie tyle, pracuję nad kolejnym usprawnieniem - jak będą efekty, to powiem o co chodzi.
Czasami lepiej trzymać usta zamknięte i być traktowany jak idiota, niż je otworzyć i rozwiać wszelkie wątpliwości. Mark Twain

Zobacz najnowsze wiadomości na forum