Uruchamianie systemu: ubuntu – arch linux – windows 10

Steve Jobs: „Gdyby można było w ten sposób uratować komuś życie, dałbyś radę skrócić czas startu systemu o dziesięć sekund?”*

Kiedy patrzy się na system, uważa się, że pewne niedociągnięcia można pominąć. Ale tak naprawdę, choćby jedno niedociągnięcie może sprawić, że tobie to nie będzie przeszkadzać, ale 10 innym osobom już tak.

Wykonałem kilka niezbyt dokładnych (starałem się, aby były dokładne) pomiarów odnośnie uruchamiania się systemu. Dane mogą… zdziwić 😉

(poniższe wartości to sekundy)
Ubuntu 15.10 (długo na dysku, aktualizacja systemu z jednej wersji do drugiej) – 43
Ubuntu-next (15.10) (unity8) – 45
Lubuntu 15.10 Alpha 2 (czysta instalacja) – 29
Lubuntu 15.10 Alpha 2 (po zainstalowaniu kilkunastu programów i czego tam się chce) – 35
Arch linux – 30
Debian unstable – 37
Windows10 – 32

Menadżer logowania:
Arch, ubuntu, lubuntu, debian – lxdm.
Windows 10 – własny.
Ubuntu-next – lightdm.

Najdziwniejsze było dla mnie to, że mój stary system, który miałem na dysku jakiś czas uruchamiał się ponad 40 sekund. Podobny wynik uzyskuje Ubuntu-next (Unity8). Zaskoczyło mnie Lubuntu 15.10 aplha 2, które po czystej instalacji na dysk uruchamiało się 26. Ale może to być spowodowane tym, że podczas ładowania systemu, nie były montowane żadne dyski oprócz systemowego i home. Ale obecny wynik, 35 sekund do ukazania się lxdm to moim zdaniem… sukces. Wyznacznikiem szybkiego załadowania systemu do pokazania się np. lxdm jest dla Arch. Ten system ładuje się bardzo szybko, co może być spowodowane szybkim montowaniem dysków, jak i też brakiem dodatkowych rzeczy, które spowalniają cały ten proces. Może też kogoś zachwycić czas Windowsa, choć dla mnie jak na taki system, z takim budżetem to raczej… średni wynik.

Podsumowując, liderem dla mnie zostaje Arch linux, później jest lubuntu 15.10 alpha 2 (oby nie zostało to zepsute), później Windows 10, Debian unstable i to co pozostało…

Nie chcę tu nikogo obrazić, bo nie ma fedory, mageia, czy opensuse, ale nie mam tych dystrybucji zainstalowanych, więc logiczne jest, że… nie mogę podać czasu ich uruchamiania się 🙂

* – cytat pochodzi z książki: Walter Isaacson – Seve Jobs wydanej w 2011 przez Insignis Media.
(mam nadzieję, że nikt mnie nie powisi za to jedno zdanie ;))

Reklamy

sparkylinux – Debian testing

Sparky Linux

Debian testing

Twórcy: Polska.
Nie lubię narzekać na samym początku tekstu, ale w przypadku Sparky Linux muszę zacząć od tego. Chodzi o wersje. Twórcy przejawiają jakieś dziwne zauroczenia i romanse z różnymi pulpitami – wydanie 3.6: openbox, jwm, e19, wydanie 3.6dev1: Budgie, wydanie 4.0 RC: openbox, wydanie 4.0 (oficjalne): LXDE, LxQt, Mate, KDE i XFCE.
I może nie czepiał bym się, gdyby nie fakt, że wprowadza to pewną konsternację: chcę wersję w miarę najnowszą, ale z openbox – muszę pobrać wydanie 4.0 RC, jak chce e19 – aby przetestować ten pulpit – 3.6, a jak chcę zobaczyć – co to Budgie – to 3.6dev1.
Oczywiście, jeśli pobierzesz wydanie 3.6 czeka cię aktualizacja całego systemu do najnowszego wydania. Czyli, pobrałeś obraz płyty, około/ponad 700 MB, to instalacji czeka cię (ponownie) pobranie około/ponad 600MB. Dziwne jest, że od początku twórcy wypuszczają wersję z openbox, ale 4.0 (oficjalne wydanie ) openbox nie uświadczymy.

Oczywiście wybrałem wersję 4.0 RC – wielkość .iso świadczy o tym, że za wiele śmiecia tam nie uświadczę. I tak jest w rzeczywistości.

Instalator jest na tyle przyjazny, że pozwala zaznaczyć opcję: nie instalowania (wyłączenie) GRUB. Jedynie gdzie można się zaciąć to przy partycjonowaniu. Powód? Brak jasnego przycisku pozwalającego edytować daną partycję pod instalację systemu (czyt. punkt montowania i opcja wykonania formatowania). Aby ustawić daną partycję, trzeba kliknąć na nią PPM i wybrać: Edytuj. Przecież jasnowidzem nie jestem i mogę nie wiedzieć, czy jak kliknę dwa razy w partycję to: przejdę do jej ustawiania, a może nic się nie stanie, a może przejdę dalej.

Sparky Linux to Debian w wersji testing. Czyli uwaga na błędy, ale można używać. Jednak największą zaletą jest fakt, że… jak napisałem to Debian. Oznacza to, że 95% do Debian, a 5% to wkład własny. Podobnie przecież jest z Ubuntu i Mint, ale ludzie jak mantrę powtarzają, że Mint lepszy (mimo, że to w 95% Ubuntu).

Jakie więc zalety ma ta dystrybucja, tworzona przez Polaków?
To, że to Debian.
Wiem, powtarzam się, ale nic więc nie mogę napisać, bo się po prostu nie da.

Twórcy nie ingerują w głębokie warstwy Debiana, aby tam dokonywać zmian np. optymalizujących, likwidujących błędy, czy ulepszających dane elementy. To raczej odchudzony do granic możliwości Debian testing, z możliwością instalacji na dysku i opcją dostosowania systemu do swoich potrzeb, po przez instalowanie tego co potrzebujemy z repozytoriów (internet).

Choć… Sparky Linux ma coś, czego próżno szukać w Debian testing. Chodzi oczywiście o możliwość zainstalowania Budgie Desktop, czy e19. I tak jak w przypadku tego pierwszego, to oczywiście pociąga za sobą obowiązek pobrania „śmieci” od gnome3, to w przypadku e19 pobieramy jedynie… jeden plik (który musi zawierać w sobie pełen pulpit).

Podsumowując… Sparky Linux nie jest złe, bo to Debian testing. Ale posiadając działające Ubuntu w wersji rozwijanej, 15.10, może z jakimś „garbem na plecach”, który obciąża, to nie widzę sensu przesiadania się i ustawiania wszystkiego od nowa, od postaw. Wadą Debiana jest brak kompatybilności z paczkami w launchpad. Gdybym chciał zainstalować obs-studio to czeka mnie kompilacja… ffmpeg, oraz samego obs-a. I może działa to wszystko lepiej, szybciej lub sprawniej, ale to zasługa tego, że to Debian. Ubuntu jest obłożone opcjami i ustawieniami, które są przydatne pewnej grupie użytkowników, bo coś im nie działa, mimo że innej grupie to działa, ale poprawka dotyczy wszystkich. Nie zmienia to też faktu, że Sparky Linux uruchamia się szybciej około (+/-3 sek.) 10 sek. szybciej niż Ubuntu. Ale nic na to nie poradzę. Debian to Debian, a Ubuntu to Ubuntu.

ps.
Mi udało się w przeciągu 2 dni testowania zawiesić e19 i Budgie Desktop, że musiałem zalogować się do systemu z innego tty i dokonać restartu Xorg, który odświeża sesję.

ps2.
Skąd ten pomysł na… Debiana?
Bo pobrałem, zainstalowałem i wywaliłem SteamOS 2.0 (chwilowe testy), które jest oparte o Debian 8.1, ale ma problem z aktualizacją do najnowszej wersji gnome-shell, na której jest oparty system od Valve. Więc pomysł, aby znaleźć alternatywę opartą o Debiana testing, i zobaczyć jak obecnie prezentuje się system, na którym opiera się Ubuntu.

xfce – Zapomniany pulpit.

XFCE – pulpit pisany w gtk2, który swego czasu miał zastąpić gnome2.

Jednak gdyby wejść na stronę xfce można by odnieść wrażenie, że dla tego pulpitu czas się zatrzymał. Ostatnia wersja pojawiła się… w 2012 roku. Za chwilę rok 2015, a choćby informacji o pracach nad nową wersją, nie ma.

Czy zatem, ten pulpit jest martwy?
Nie.

Jednakże, wiele dystrybucji nie sięga do git, a to właśnie tam można zobaczyć, że pulpit ten jest, w pewnym sensie, cały czas w rozwoju: http://git.xfce.org/

Debian testing swego czasu przeszedł na xfce, a obecnie dokonuje przesiadki z powrotem na gnome-shell. Szkoda, że nikt nie napisał, że najświeższe wersje xfce są w repozytoriach experimental. Podobnie jest z Ubuntu, gdzie w wersji stabilnej mamy stabilne wydania, a najnowsze znajdą się w nadchodzącym Ubuntu, czyli 14.10.

Nie ma co się jednak oszukiwać, rozwój xfce zwolnił w porównaniu do lat poprzednich. Jednak nadal ktoś dłubie nad kodem tego desktop-u i to jest ważne.

Czego nie aktualizować w Ubuntu 14.10?

Ubuntu to specyficzna dystrybucja, ponieważ instalując stabilną wersję systemu trzeba się godzić na delikatnie przestarzałe i nie aktualizowane programy, czy elementy systemu, zaś developerska wersja to baza najnowszych wydań i wersji, ale udostępniana raczej do testowania, a nie używania na co dzień.

Innymi słowy, stabilna wersja w dniu wydania jest aktualna, ale już po dwóch miesiącach może trącić trochę stęchlizną.
Ja rozwiązuje to dodając repozytoria developerskiej wersji, aby nie musieć patrzeć na innych użytkowników, którzy bawią się najnowszymi wersjami, a ja siedzę na, jakby nie było, starej wersji, która może nie zawierać pewnych nowości, czy udogodnień.

Ale nie warto wszystkiego aktualizować do najnowszej wersji.
Tak jest na przykład z pitivi lub mc.

Muszę tu zaznaczyć, że czasami nie warto zaopatrywać się w wersje programów od Canonical, jeśli nie używacie Unity, gnome-shell, plasma-next.

Wersja Pitivi w Ubuntu 14.10 (i obecnie już w Ubuntu 14.04) to 0.93, wersja która… jest wersją testową, niedorobioną i brakuje jej wiele opcji, czy funkcji. Dlatego lepiej jest pobrać sobie wydanie 0.15.2 (Ubuntu 13.10), mimo że mogą się pojawić problemy z zależnościami, które łatwo ominąć.

Kazam 1.3.0, czy może 1.4.5 (stable), albo 1.5.3 (unstable)?
Ja używam wersji 1.3.0, która działa bardzo dobrze na lxde, oraz wykorzystuje ffmpeg. Twórcy przy ostatnich wydaniach programu kazam dokonali przesiadki z ffmpeg na gstreamer 1.0, co doprowadziło do tego, że program z lekkiego i prostego stał się zasobożerny podczas nagrywania, oraz dość mało wygodny (suwaki głośności w panelu ustawień).

claws-mail – wersja od Canonical „wyłącza” widoczność ikonki w tray-u, jeśli korzystacie z xfce, lxde lub e18. Wszystko po to, aby ikonka była widoczna na panelu Unity.
Polecam korzystać z wersji z repo launchpad lub wersji dla Debiana.

pidgin – Canonical kilka dni temu dodał opcję widoczności stanu w Unity. Zgaduje, że ikonka statusu przestała być widoczna w tray-u na pulpitach opartych o gtk2.
Wersja dla Debiana sprawdza się tu wyśmienicie.

liferea – Podobna historia co z pidgin. Wersja od Canonical nie wyświetli ikonki na panelu w pulpitach opartych na gkt2, zaś na Unity będzie widoczna.
Wersja dla Debiana przychodzi z pomocą.

Jądra… 3.13, czy pokusić się o instalację 3.16 (ubuntu 14.10)?
Ja używam 3.13, nie dlatego że to starsze wydanie, ale dlatego, że na wersji 3.16 nie działa mi wbudowany czytnik kart w moim laptopie, a na 3.13 działa on wyśmienicie. Co może wydawać się jeszcze dziwniejsze, ale ładowanie systemu w przypadku jądra 3.13 przy użyciu systemd jest odczuwalnie krótsze, niż w przypadku jądra 3.16, choć nie wiem dlaczego.

I na koniec… mc. Starsza wersja (14.04) nie ma problemów z okienkiem kopiowania plików i innymi okienkami, zaś ta przeznaczona dla 14.10 ma z tym problem.
Cofnięcie wersji do wydania 14.04 rozwiązuje problem.

Canonical ewidentnie chce, w pewnym sensie, siłowo dodać swojemu tworowi funkcjonalności. Ale cierpią na tym osoby, które nie używają Unity lub gnome-shell, czy plasma-next (kde5). Linux uczy myślenia, dlatego jeśli ktoś nie chce godzić się z polityką Canonical zawsze może odwołać się do repozytoriów i wersji społeczności lub zainstalować wersje przeznaczoną dla Debiana.
Zawsze jest jakieś wyjście z sytuacji 🙂