przystajnik

Tara o której wiemy już wszystko. Linux Mint 19 „Tara”

Na przekór etykietce „najpopularniejszej dystrybucji tej dekady”, Linux Mint 19 „Tara” uniknął marketingowego embarga informacyjnego. Kompletnie nie eskalowano napięcia przed ostateczną wersją finalną. Od tygodni znamy nowe funkcje elementów składowych systemu, zmiany w środowisku graficznym. Ba, udostępniono nawet obrazy instalacyjne wersji Beta. I dla większość fanów tej dystrybucji finalna wersja Linux Mint 19 była aktualizacją dla wspomnianej wersji Beta, która u wielu jest już podstawowym systemem od kilku tygodni.

Linux Mint 19 Tara

Jednak powiedzmy to otwarcie. Zgodnie z zapowiedziami, końcem czerwca ukazało się ostateczne wydanie Linux Mint 19 „Tara”. Najpopularniejszy Linux na desktopie doczekał się licznych zmian w obrębie elementów systemu, nowej wersji środowiska Cinnamon 3.8 oraz co najważniejsze – został zbudowany z wykorzystaniem Ubuntu 18.04 LTS. Tym samym Mint 19 stał się zalążkiem nowej serii wydawniczej (poprzednio seria 18.xx z Ubuntu 16.04 LTS jako bazą) i nową jakością. Ale po kolei.

Nowa podstawa

Linux Mint 19 z kernelem 4.15 i bazą paczek z Ubuntu 18.04 nikogo nie powinien dziwić. To sukcesywne podążanie za koncepcją wydań ogłoszoną parę lat temu. Z każdą nową wersją o długoterminowym wsparciu – nowa seria Minta. Wybawienie dla osób znudzonych wersją oprogramowania z 16.04. Tym razem w roli głównej występuje np. serwer grafiki X.Org 1.19.6, biblioteki Gtk+ 3.22.30, Qt 5.9.5, glibc 2.27 i Mesa 18.0.0, kompilator gcc 7.3.0 oraz demon systemd 237.

Cinnamon 3.8

Flagowe i autorskie środowisko graficzne w nowym wydaniu musiało otrzymać oczywiście nowy numer. Nie jest to jednak zmiana kosmetyczna, ale potężna dawka poprawek i ulepszeń, które autorzy zaaplikowali swojemu dziełu.

Na początku należy wspomnieć o ogromnej ilości optymalizacji jakich doczekał się Cinnamon. Okna rysowane są obecnie niemal cztery razy szybciej niż w poprzednich wersjach.

Wyszukiwanie

Swoje tempo działania poprawił również menedżer plików Nemo. Usprawnienia w libnemo-extensions sprawiają, że menedżer żwawiej wyświetla zawartość katalogów, kopiowanie plików z/na nośniki USB nie laguje jak poprzednio a wyszukiwanie plików jest bardziej przydatne i równie szybkie.

Powiadomienia systemowe stały się sprytniejsze. Pojawił się przycisk zamykania, który robi to co ma robić, bez odsyłania do programu generującego powiadomienie. Okienko nie ulega również rozmyciu po najechaniu myszką. Wprowadzono limit powiadomień w jednostce czas na aplikację. Okienka znikają, jeżeli zostanie aktywowany program który chce przykuć naszą uwagę. Możemy również skonfigurować miejsce pojawiania się tych informacji.

150%

W ustawieniach dźwięku pojawiła się możliwość wzmocnienia głośności do 150%. Aplet miksera i inne oprogramowania nadal posługują się wartościami 0 do 100%, jednak z uwzględnieniem ustalonej przez nas skali. Tym samym „przesterowanie” sygnału możemy aktywować bez potrzeby wdawania się w ponowną dyskusję z ustawieniami.

Pojawiły się również ikony symboliczne poprawiające nowoczesność całego środowiska.

CJS, interpreter Javascriptu to obecnie GJS 1.50.2 i wykorzystuje mozjs52.

Poprawiono wsparcie dla dekoracji okna CSD, dodano wsparcie dla GTK 3.22.

Elementy systemowe zostały przepisane do Pythona 3.

Dodano wsparcie dla protokołów admin://, elogind i systemd-timedated1.

System oraz środowisko sprawniej dogadują się też z laptopami. Ekran jest automatycznie blokowany przed uśpieniem, touchpad jest aktywowany automatycznie gdy system nie wykryje myszki, zamknięcie pokrywy laptopa może również wyłączać system.

Pamiętaj o migawkach systemu

Timeshift i Menedżer Aktualizacji

Istotnym elementem systemu stał się Timeshift umożliwiający sprawne tworzenie migawek systemu i jego przywracanie w przypadku problemów po np. aktualizacji. Również Menedżer Aktualizacji przypomina o ustawieniu tego narzędzia (sam system informuje nas o takiej możliwości już na ekranie startowym). Przyrostowe tworzenie kopii systemu (rsync, btrfs) pozwala niemal bezstresowo aktywować automatyczne aktualizacje systemu. W przypadku jego awarii przywrócenie ostatniej działającej wersji Minta to parę chwil. W tym wszystkim najlepiej odnajdą się nawet zwykli (automatyczne aktualizacje). Nie powinni oni mieć problemów z ewentualnym przywróceniem systemu do stanu sprzed paru dni. Ułatwia to graficzny interfejs za pomocą którego obsługujemy cały proces.

Menedżer Oprogramowania

Menedżer Oprogramowania

Niekończąca się rozbudowa i przebudowa Menedżera Oprogramowania trwa nadal. Tym razem zmieniono nieco układ okna, dodano delikatne animacje, poprawiono nawigowanie za pomocą klawiatury. Wyszukiwanie podsuwana nam wiele bardziej sugestywnie wyniki (z uwzględnieniem kategorii). Pojawiła się wewnętrzna pamięć podręczna programu, dzięki której Menedżer tak samo łatwo obsługuje paczki deb (APT) oraz Flatpak. Wsparcie dla .flatpakref oraz .flatpakrepo pozwala instalować Flatpaki wprost z internetu (przycisk na stronie). A przy okazji program uruchamia się też znacznie sprawniej niż poprzednio.

Nowe ustawienia zapewnia libXapp

Aplikacje systemowe

Osławione XApps również doczekały się rozwinięć swojej funkcjonalności i innych usprawnień.

Edytor tekstu Xed doczekał się nowego okna z ustawieniami. Program podciągnięto również pod standard GTK 3.22. Wprowadzono skróty klawiszowe w menu pomocy a nowa wtyczka zajmie się autouzupełnianiem tekstu.

Przeglądarka PDF, Xreader, doczekała się podobnego okna z preferencjami. Mamy możliwość aktywowania opcji „ostatnio oglądane” i szybkiego powrotu do poprzednich plików PDF. Możemy także zmienić rozmiary miniatur oraz wykasować notatki.

Oczywiście tapety

Inne

Wśród pozostały licznych zmian znajdziemy też kilka takich, które mogą mieć namacalny wpływ na codzienną jakość pracy.

Nośniki pamięci USB możemy sformatować z systemem plików exFat.

Źródła Oprogramowania potrafią pokazać paczki zainstalowane z PPA.

Ekran logowania wspiera wielomonitorowe stanowiska pracy i pozwala wybrać ten domyślny.

Firefox pokaże nam na panelu postęp pobieranych plików.

W domyślnej instalacji znajdziemy GNOME Calendar z możliwością zsynchronizowania go z kontem Google.

Kodeki multimedialne zawierają również fonty Microsoftu.

Zobaczymy też wiele nowych tapet, poprawiony temat graficzny Mint-Y (domyślny), nowe ikony, jeszcze lepsze wsparcie dla HiDPI.

System będzie otrzymywał poprawki bezpieczeństwa do 2023 roku. Wszystkie następne wersje Linux Mint aż do roku 2020 będą korzystać z tej samej podstaw – Ubuntu 18.04 LTS i Mint 19.

Instalacyjne obrazy ISO znajdziemy pod tym adresem

Post navigation

74 comments for “Tara o której wiemy już wszystko. Linux Mint 19 „Tara”

  1. redram
    2 lipca, 2018 at 8:39

    Ciekawe czy przewidziano możliwość upgrade’u z 18? Czy może trzeba będzie instalować od nowa, jak przy zmianie 17 na 18.

  2. 2 lipca, 2018 at 8:52

    Niedługo pojawią się informacje, jak wykonać jaką aktualizację.

  3. Titi
    2 lipca, 2018 at 10:06

    Pozostaje czekać na wydanie HPLIP-a pod Tarę.

  4. pavbaranov
    2 lipca, 2018 at 10:48

    A jaki masz z tym problem, bo nie bardzo rozumiem? Jak praktycznie 100% programów „core” Minta pochodzą one bezpośrednio z Ubuntu, a tu:… https://packages.ubuntu.com/search?keywords=hplip&searchon=names&suite=bionic&section=all voila 😉

  5. pavbaranov
    2 lipca, 2018 at 10:52

    Mam pytanie do kogoś, kto ma Mint 19 z Cinnamonem na jakiejkolwiek, ale lepiej (tzn. szybciej się zobrazuje) z mniejszą ilością RAM (ot, powiedzmy 4GB), maszynie. Czy dalej po kilkunastu-kilkudziesięciu minutach wykonywania tych samych operacji system ulega totalnemu zawieszeniu (wycieki pamięci)?

  6. gom1
    2 lipca, 2018 at 11:19

    Nowego Minta postawiłem na sprzęcie, na którym wcześniej testowałem Ubuntu 18.04:
    https://pastebin.com/NhSHkqHK
    Nie zwróciłem uwagi na wykorzystanie RAM, ale też nie zauważyłem takich problemów.

  7. Titi
    2 lipca, 2018 at 12:18

    Próbowałem z najnowszym HPLIP 3.18.6
    System w Printers -localhost drukarkę LaserJet M1132 MFP widzi ale nie drukuje (brak ikonki HP w pasku na dole)
    W terminalu sh hplip-3.18.6.run wyrzuca error: linuxmint-19 version is not supported…
    Można ją w inny sposób zmusić do pracy ?

  8. pavbaranov
    2 lipca, 2018 at 13:09

    Ok… Zdaje się, że już rozumiem pierwszy post. W Ubuntu/Mint masz wersję 3.17.10 i ta powinna działać. Co ciekawe nawet w nadchodzącym wydaniu 18.10 jest nadal ta wersja hplip.
    HPLIP 3.18.6 powstał, gdy jeszcze Mint 19 nie było. Jeśli skrypt w *.run sprawdza wersję, to w istocie otrzyma odpowiedź, że jest to Mint 19 i wygeneruje błąd.
    Jeśli bardzo potrzebujesz akurat tej wersji hplip to musisz poszukać, czy nie ma w jakimś PPA lub zbudować sobie paczkę ze źródeł lub spróbować zainstalować pakiet dostarczany w tarballu (osobiście jestem jednak zwolennikiem wprowadzania do systemu wyłącznie pakietów rozpoznawanych przez ich menedżer w danej dystrybucji).

  9. clfapujc
    2 lipca, 2018 at 14:35

    Ja bym stawiał na czystą instalację. Przejście z init (16.04) na systemd (18.04) może utrudnić bezbolesny upgrade. A jak ktoś miał swoje własne konfiguracje systemu, to tym bardziej. I nie trzeba czekać na żadne poradniki. Godzinka i po strawie.

  10. clfapujc
    2 lipca, 2018 at 14:38

    reddit /r/linux4noobs/comments/8v7n14/mint_why_is_cinnamon_taking_up_4g_of_ram/

    Prawdopodobnie jakieś niezałatane pluginy. Nigdy nie używałem Cinnamona więc nie znam się na tym.

  11. 2 lipca, 2018 at 14:48

    To nie do końca tak, a przynajmniej być może nie na wszystkich konfiguracjach sprzętowych. U mnie sam Cinnamon znajda około 240 – 280 MB pamięci. Więc jest całkiem nieźle. Niestety, pozostały 500MB zjada 21 oddzielnych procesów cinnamon-settings-daemon (wprowadzonych na rzecz rozproszonej i stabilniejszej kontroli nad systemem). W ten sposób sam system zajmuje nam około 800 – 900 MB pamięci RAM. Trochę słabo to się sprawdzi na maszynkach z 4GB.

    A jak do tego dojdą wycieki… To już inna bajka. Na szczęście mój Mint wytrzymuje bez resetowania już od tygodnia i nie zauważyłem przygód z wyciekami.

  12. Titi
    2 lipca, 2018 at 15:15

    Niestety wersja 3.17.10 domyślnie zainstalowana z obrazu Mint 19 nie działa i chociaż system drukarkę wykywa, ta nie drukuje. /3.18.16 z Mint 18.2 na lapku żony drukuje bez problemów/. Wygląda na to że niestety będę musiał wrócić do wcześniejszej wersji Mint bo nie mam wiedzy odnośnie budowania paczki ze źródeł. Dziękuję za odpowiedź.

  13. pavbaranov
    2 lipca, 2018 at 15:30

    Nie musisz nawet budować paczki (choć gorąco zalecam; może znajdzie się jakaś dobra dusza, która Ci to zbuduje – spytaj np. na forum Minta) – możesz ściągnąć tarball ze stronki hplip, a instrukcja instalacji również się tu mieści: https://developers.hp.com/hp-linux-imaging-and-printing/howtos/install#howtocheck5

  14. pavbaranov
    2 lipca, 2018 at 15:43

    To nie są niezałatane pluginy Cinnamona, a jakaś kwestia między bibliotekami Gtk a domyślnym WM używanym tak w GNOME3, jak również w jego klonie w Cinnamon. Na komputerze żony wprawdzie Cinnamon brał chyba mniej RAM niż owe 800-900MB, ale po jakimś czasie (powtarzalne czynności – to jest ważne) – powodował kompletne zawieszenie się komputera, któremu nie pomagało nic innego oprócz twardego resetu. Problem był nagłośniony w okolicach wejścia Ubuntu 18.04, ale znany jest już wcześniej.
    Aha i raczej nie chodzi o to co na reddicie. Dla mnie obojętne jest, czy Cinnamon bierze sobie 4GB, czy 200MB byleby tylko potrafił racjonalnie zarządzać pamięcią. Np. w przypadku Plasmy, gdy jakaś aplikacja ma wycieki pamięci (np. tak było choćby z Qupzillą czy Kadu), to sam proces plasmashell się wywłaszcza (zajmuje mniej RAM) – fakt, Plasma wolniej chodzi, ale mam czas na reakcję. W przypadku Cinnamona (i pojawiło się to w wersji 3.8.x + Gtk+3.22) dochodzi do zapełnienia wszystkiego i system wisi. Nie ma reakcji na dowolny klawisz. Nawet na konsolę nie da rady się przełączyć, by pozamykać zbędne procesy.

  15. 2 lipca, 2018 at 15:53

    A udało Ci się ustalić co tak puchnie? Sam Cinnamon, czy któryś z csd?

  16. pavbaranov
    2 lipca, 2018 at 16:19

    Nie. Jak już spuchnie – koniec kropa – nie ma żadnej możliwości dowiedzenia się (twardy reset). Komputer żony – nie używam i tylko słyszę, że: nic nie mogę zrobić! Teraz już też nie ustalę, albowiem Cinnamon poszedł do kosza i nie bardzo chyba mam potrzebę go przywracać. Ogólne objawy natomiast dokładnie takie same jak szeroko opisywane przy okazji Ubuntu 18.04 (tak z Gnome, a nie z Cinnamonem, ale… Gtk+ to samo, a WM w obu tych przypadkach praktycznie ten sam).

  17. 2 lipca, 2018 at 17:02

    A powiedz jeszcze, czy to sprzęt Della?

  18. Titi
    2 lipca, 2018 at 17:27

    Już wszystko działa. Rozwiązaniem okazał się być brakujący HP-plugin /qt5ct/. Jeszcze raz dziękuję za pomoc.

  19. pavbaranov
    2 lipca, 2018 at 17:31

    Packard Bell, czyli Acer. To chyba nie jest zaleźne od sprzętu. W necie miły filmik. Gostek naciska na przycisk menu przez kilkanaście minut i… zwiecha 🙂

  20. pavbaranov
    2 lipca, 2018 at 17:44

    A to co napisałeś jest… jak dla mnie śmieszne. Qt5ct to jest wyłącznie „programik”, którego jedynym celem jest to, by aplikacje Qt5 miały w innych środowiskach odpowiedni wygląd. Nie powinno to w ogóle mieć żadnego wpływu na możliwość drukowania. Czego to się człowiek jeszcze nie dowie w swoim starczym życiu…
    Inna sprawa, że taki Mint adresowany ponoć do ZU winien ów qt5ct mieć po prostu na pokładzie OTB.

  21. Titi
    2 lipca, 2018 at 18:05

    Rozumiem, że dla starego wyjadacza może to byc śmieszne.. Kończyłem kierunek nie mający nic wspólnego z politechniką więc jestem takim ZU. W konsoli wpisałem hp-plugin. Coś tam sobie pociągnął z sieci i bingo ! Zadziałał 🙂

  22. Pseudodrummer
    2 lipca, 2018 at 18:09

    Tak,wybierasz instalację ręczną w hplip i wskazujesz system ubuntu 18.04,jakos tak

  23. Pseudodrummer
    2 lipca, 2018 at 18:11

    Jest na to rada,prosta i skuteczna:
    XFCE

  24. pavbaranov
    2 lipca, 2018 at 18:16

    Jest też: MATE, Plasma, Deepin, OpenBox, JWM i od groma innych. Sam (za żonę) taki wybór zresztą dokonałem. Czy jednak przez ten wybór Cinnamon i GNOME pozbędą się tych problemów – wątpię.

  25. pavbaranov
    2 lipca, 2018 at 18:17

    Grunt że działa.
    PS: Nie mam żadnego wykształcenia technicznego, a gdy się uczyłem, to o PC nikt nawet nie słyszał. Informatyka w szkole? 😀

  26. Titi
    2 lipca, 2018 at 18:58

    Tak, mogłem raz na fizyce popatrzeć przez chwilę na Timex Computer 2048 😀

  27. 2 lipca, 2018 at 19:36

    Musi być Mint? Obecne wydanie choć zdaje się być responsywniejsze od poprzedniego to jednak swoje wymagania ma i rakietą nawet na szybszym sprzęcie nie jest. Zerknij ma MX Linux (podrasowany, customowy Debian z XFCE): świeższe kernele, soft podobny, brak systemd i flatpaki z popularnym softem ładnie działają. Fajnie działa na starszych sprzętach.

  28. pavbaranov
    2 lipca, 2018 at 20:19

    Cinnamon nie był na Mincie i – po wielu, doprawdy wielu, latach z dystrybucjami opartymi o APT (od Debiana, przez jego bezpośrednie pochodne np. Sidux, dalsze pochodne – jak *buntu, na krótkiej randce z Mintem skończywszy) – nie wrócę do nich i w domu i w firmie, dopóki ja zarządzam tymi komputerami żadna dystrybucja taka nie stanie. Niemniej jednak gdyby okazało się, że problem w Mint 19 Cinnamon nie występuje, to wiedziałbym gdzie szukać problemu. XFCE właśnie postawiłem żonie i jak na razie jestem z tego zadowolony na jakieś 60-70%. Flatpak – nie problem (działa), ale nie potrzebuję go.
    Po prostu chciałem wiedzieć jak z tym Cinnamonem. Pewnie jak się wnerwię, to zainstaluję tam KDE i będę miał spokój 🙂 Przynajmniej środowisko, które dość dobrze znam, a po ostatnich zmianach zaczyna być doprawdy mało wymagające. Aplikacje – dla niesmartfonowca (a żona nim nie jest) – też zdecydowanie bardziej czytelne w obsłudze. W sumie… może to niezły pomysł.

  29. 3 lipca, 2018 at 8:36

    Jeśli to cudzy komputer to… trzymaj się tego co znasz, co działa i nie trzeba naprawiać.

    Ja przy doborze distra kieruję się dostępnym softem i długim wsparciem, a następnie jeśli chodzi o środowisko graficzne równam w dół tj. do najsłabszej maszyny. W ten sposób wszędzie mam to samo i nie nadwyrężam przesadnie mózgownicy jak coś gdzieś sprawia problemy.

  30. Marek
    3 lipca, 2018 at 11:03

    Ja mam od około tygodnia Mint 19 (wcześniej beta) na starym AMD z 4 GB RAMu i na dysku SSD 😉

    Jeszcze ani razu system mi się nie zwiesił….

    Fakt , świeża instalacja i uruchamiam głównie programy do obróbki zdjęć na kilka chwil oraz przeglądarkę Firefox ale daje radę. Jedyne co ma miejsce to rozłączanie z wifi bez sygnalizacji tego faktu. Pomaga wyłącz i włącz sieć bezprzewodową…

  31. jjatosam
    3 lipca, 2018 at 11:33

    Tak trochę poboczem i obok wątku. Nie wiem czy jestem za stary czy czegoś nie kumam. „cynamona” z Archem od dziewięciu miesięcy używam i jedyne problemy to przejście z 3.6 na 3.8. Po pierwszej aktualizacji osunięte restarty . Lapka bez potrzeby nie wyłączam , czasami chodzi i 12 godzin bez współpracy, nagminnie używam Dartable do obróbki 300 i więcej zdjęć (ot taka mania na starość) potem Gimp żeby wygładzić efekt, a w chwilach wolnych Calibre. No nie było wypadku żeby odmówił współpracy, zawiesił się przy wybudzeniu. A sprzęt nienowy, system wykrywa 3,7 RAMu. (a producent twierdzi ze mam 4 Gb). Na innym forum czytałem żeby sprawdzić że po kilku minutach klikania ikony Menu sprzęt zawiesza się dokumentnie. Ludzie, naprawdę się w to bawicie? Dla mnie powtarzalne sytuacje to odpalnie przeglądarki, Audacius w tle, Dartable w natarciu – no zero czknięć nawet po wybudzeniu.

  32. Marek
    3 lipca, 2018 at 11:54

    Czemu lapka nie wyłączasz ? Za długo startuje system ? 😉 Ja od niedawna mam Linuxa na SSD i moim zdaniem to ideał , nawet 4 GB RAM-u wystarcza żeby pracować bez żadnych zacięć i spowolnień…Wyłączanie systemu trwa 2 sek. ? Startuje nieco dłużej bo kilkadziesiąt sekund ale jest przepaść między tym co było a jest…

  33. etmoon
    3 lipca, 2018 at 13:11

    Miałem podobny problem w pracy na Gentoo. Miałem Cinnamona, który po tygodniu pracy na komputerze zawieszał się i trzeba było go restartować. Z Gnomem shellem na prywatnym lapie miałem podobne przeboje (Ubuntu GNOME). Rozwiązaniem okazało się powrót do korzeni, czyli przełączenie na środowisko MATE w pracy i instalacja Ubuntu MATE na prywatnym lapku.

  34. pavbaranov
    3 lipca, 2018 at 13:12

    Jeśli na SSD system włącza Ci się (jak rozumiem z zimnego) kilkadziesiąt sekund, to przyglądnąłbym się temu SSD lub swoim ustawieniom. Stanowczo zbyt długo. Tyle nie powinien startować nawet komputer z najbardziej tradycyjnym HDD (choć niektóre DE będą szybciej nadawały się do używania).

  35. Marek
    3 lipca, 2018 at 14:52

    Zmierzony odczyt to zaledwie 283 MB/sek. 😉 Przy teoretycznym 550 MB/sek. Winna jest stara SATA ? Chyba w wersji I a sam dysk jest w standardzie SATA III. Jutro lub dziś sprawdzę ze stoperem ile to dokładnie trwa od wybrania Linux Mint w Grubie 😉

  36. pavbaranov
    3 lipca, 2018 at 15:22

    No to – prawdopodobnie – masz wąskie gardło: SATA.

  37. Marek
    3 lipca, 2018 at 15:30

    Można by pewnie zrobić upgrade i kupić kartę z portami SATA III na PCI-Express (to komputer desktop) tylko nie wiem czy to ma sens ? Byłoby do 2 x szybciej ? Na początek zainwestowałem w kartę z USB 3.0 do podpinania szybkich urządzeń peryferyjnych , czytnik kart SD , HDD itd. 😉

  38. 3 lipca, 2018 at 17:31

    Patrząc na wartość transferu masz złącze SATA II. Nie warto kupować dodatkowego kontrolera, bo dobre karty są trudno dostępne i drogie, a na kiepskich złapiesz wartości jak dla SATA II lub niewiele większe. Jak masz wolne złącze PCI-e 2.0 4x to warto rozważyć SSD w formacie M2 na karcie/adapterze do tego złącza.

    Tak jak napisał @pavbaranov:disqus coś Ci ten system za długo startuje (no chyba, że bardzo długo wisi na BIOSie).

  39. redram
    3 lipca, 2018 at 18:18

    Niczego nie ryzykuję, /home mam i tak w osobnej partycji, więc jeżeli upgrade nie wypali, zawsze mogę postawić system od nowa.

  40. Marek
    3 lipca, 2018 at 20:07

    Od naciśnięcia Enter w Grub do pojawienia się pulpitu mija ok. 31 sek. 😉

    Faktycznie mam SATA II , płyta główna to ASUS M2N-E (NVIDIA nForce® 570 Ultra™ MCP supports:
    – 1 x Ultra DMA 133 / 100 / 66 / 33
    – 6 x Serial ATA 3.0Gb/s
    – NVIDIA MediaShield™ RAID supports RAID 0, 1, 0+1, 5 and JBOD span cross Serial ATA drives) .

    Obejrzałem sobie tanie chińskie karty z rzekomo SATA III i tam ludzie w rzeczywistości osiągają transfery niższe od mojego obecnego na SATA II 😉 Z kolei dobre karty SATA III kosztują pół ceny mojego dysku SSD , więc odpuszczam temat… W zasadzie to obecna wydajność systemu dyskowego jest dla mnie więcej jak dobra , średnia prędkość odczytu 282,4 MB/s (100 próbek) , czas dostępu 0,07 ms (1000 próbek). Wolę klasyczny dysk na złączu SATA bo można go łatwo przenieść do dowolnego komputera w tym laptopa.

  41. Xyzz
    3 lipca, 2018 at 20:19

    „Startuje nieco dłużej bo kilkadziesiąt sekund ale jest przepaść między tym co było a jest…”

    Zamiast wróżyć z magicznej, szklanej kuli polecę sprawdzenie co tam się dzieje za pomocą „systemd-analyze blame”/”systemd-analyze critical-chain” – być może jakiś unit startuje bardzo długo. Szklana podpowiada mi, że przyczyną takich atrakcji mogą być uszkodzone/przestarzałe configi (pacman sam configów nie podmienia – zapisują się jako pliki nazwaconfigu.pacnew).

    Drugą opcją może być to, że zapomniałeś o włączeniu funkcji trim i wydajność I/O z czasem bardzo spadła – Arch nie ma włączonego domyślnie cotygodniowego trima (można sprawdzić to za pomocą „systemctl status fstrim.timer”) ani nie dodaje opcji discard w fstab. Trzeba włączyć samemu.

  42. Marek
    4 lipca, 2018 at 7:30

    Trim włączony , każdego dnia się sam robi przez crona.
    Czasem robię ręcznie w terminalu.
    W fstab noatime bez discard bo tak zalecają w poradniku mint 19 i ssd

    System postawiony od nowa , więc nie wiem co by mogło być przestarzałe ?
    Fakt , nie widzę co się długo inicjuje bo widać wyłącznie logo linux mint , wskaźnik myszki pojawia się ok. 5 sek. wcześniej niż sam ekran główny systemu. Musiałbym przejrzeć logi bootowania ?

  43. 4 lipca, 2018 at 11:25

    Instrukcja upgrade z wersji 18.3 systemu już dostępna na :

    https://community.linuxmint.com/tutorial/view/2416

  44. Marek
    4 lipca, 2018 at 11:26
  45. pavbaranov
    4 lipca, 2018 at 11:32

    Obie komendy nie pokażą jednak czasu od „zimnego” startu do pojawienia się możliwości pracy w DE.

  46. pavbaranov
    4 lipca, 2018 at 11:41

    To co się długo inicjuje nie zobaczysz nawet jeśli splasha nie będzie (choć samo wczytanie splasha również zajmuje jakiś czas; być może tam też plymouth jest – nie wiem i nie chce mi się sprawdzać).
    Podstawowe komendy do diagnozowania czasu bootowania w systemach, gdzie jest systemd, są obie, wskazane Ci wyżej przez @Xyzz. Po wywołaniu ich w konsoli zobaczysz co najdłużej zajmuje czas przy bootowaniu. Jest to jednak lekko złudne, albowiem część z usług podnoszonych przez systemd jest podnoszonych równolegle, część jest podnoszonych jeszcze gdy masz już możliwość korzystania z DE itp. Trochę trzeba to umieć czytać 🙂 Np. uruchomiony w pewnym momencie dzisiaj komputer pokazał mi, że jedna usługa trwała ponad 1,5 minuty, a jeszcze inna ok. 30 sek. Nie oznacza to jednak, że DE pojawiło się dopiero po kilku minutach.
    IMO – jeśli czas z „zimnego” startu Ci pasuje, a nie znasz się na tym, które usługi możesz wyłączyć, a których na pewno nie, to zostaw jak jest lub daj komputer komuś, kto będzie wiedział co ma zrobić. Przy czym jeśli będzie wiedzieć bez wypytania Ciebie o to co jest, a co nie jest potrzebne, to nie jest to ktoś, kto się zna.

  47. Xyzz
    4 lipca, 2018 at 11:52

    Czekaj, czekaj – „Trim włączony , każdego dnia się sam robi przez crona.”. Z tego co pamiętam, to starsze ssd-ki nie były demonami prędkości jeśli chodzi o szybkość manualnego trim i kilkanaście sekund potrafiło to zająć. Jak zapisujesz/usuwasz codziennie ~ 1/10 pojemności dysku, to codzienny trim może być delikatną przesadą i można rozważyć cotygodniowy trim.

    Jeśli włączyłeś codziennego trima przez crona, to łatwej metody sprawdzenia czy to jest powodem dłuższego startu systemu nie ma (oprócz wyłączenia tego w crontabie i sprawdzenia, czy system bez tego startuje szybciej).

    Jeśli włączyłeś to korzystając z timerów systemd (edytując timer fstrim.timer aby startował codziennie oraz wpisując „systemctl enable fstrim.timer”), to czas startu danej jednostki sprawdzisz poleceniem „systemd-analyze blame”. Jeśli problemem jest tutaj wolny fstrim, to jako pierwsza powinna pojawić się jednostka „fstrim.service” razem z czasem potrzebnym do jej wykonania.

    „Musiałbym przejrzeć logi bootowania ?”
    Logi bootowania najprawdopodobniej nic ciekawego nie pokażą, ale można sprawdzić logi z ostatniego uruchomienia poleceniem „journalctl -b”.

  48. Xyzz
    4 lipca, 2018 at 14:24

    „Trim włączony , każdego dnia się sam robi przez crona.”

    To może być problemem dłuższego startu, bo na starszych ssd-kach „manualny” trim potrafił zająć trochę czasu (sata 2 w laptopie może jeszcze to wydłużyć). Codzienny fstrim może być przesadą, jeśli np. zapisujesz/usuwasz 1/10 pojemności dysku dziennie – cotygodniowy mógłby się tutaj sprawdzić lepiej.

    Jeśli włączyłeś codzienny trim za pomocą crona, to systemd-analyze nie pokaże czasu potrzebnego na zainicjowany przez crona fstrim. W takim przypadku sprawdziłbym czas drugiego startu systemu tego samego dnia.

  49. Marek
    4 lipca, 2018 at 14:32

    systemd-analyze blame
    23.597s apt-daily.service
    6.151s fstrim.service
    1.114s networking.service
    1.007s systemd-resolved.service
    977ms apt-daily-upgrade.service
    960ms hddtemp.service
    942ms grub-common.service
    934ms speech-dispatcher.service
    847ms udisks2.service
    722ms dev-sdc1.device
    540ms NetworkManager.service
    370ms ubuntu-system-adjustments.service
    362ms systemd-journal-flush.service
    311ms ModemManager.service
    303ms networkd-dispatcher.service
    270ms accounts-daemon.service
    247ms lightdm.service
    245ms plymouth-quit-wait.service
    213ms upower.service
    210ms systemd-udevd.service
    207ms systemd-logind.service
    203ms avahi-daemon.service
    190ms apport.service
    186ms keyboard-setup.service
    180ms apparmor.service
    160ms systemd-modules-load.service
    156ms wpa_supplicant.service
    134ms lvm2-monitor.service
    99ms systemd-udev-trigger.service
    92ms nvidia-persistenced.service
    88ms gpu-manager.service
    85ms thermald.service
    83ms lm-sensors.service
    75ms colord.service
    72ms user@1000.service
    71ms systemd-journald.service
    64ms alsa-restore.service
    63ms polkit.service
    62ms rsyslog.service
    61ms dns-clean.service
    52ms systemd-tmpfiles-setup-dev.service
    51ms packagekit.service
    43ms pppd-dns.service
    36ms dev-disk-byx2duuid-5976caefx2d0f66x2d4001x2d9933x2d0d193b9
    34ms systemd-sysctl.service
    33ms rtkit-daemon.service
    25ms dev-mqueue.mount
    25ms blk-availability.service
    270ms accounts-daemon.service
    247ms lightdm.service
    245ms plymouth-quit-wait.service
    213ms upower.service
    210ms systemd-udevd.service
    207ms systemd-logind.service
    203ms avahi-daemon.service
    190ms apport.service
    186ms keyboard-setup.service
    180ms apparmor.service
    160ms systemd-modules-load.service
    156ms wpa_supplicant.service
    134ms lvm2-monitor.service
    99ms systemd-udev-trigger.service
    92ms nvidia-persistenced.service
    88ms gpu-manager.service
    85ms thermald.service
    83ms lm-sensors.service
    75ms colord.service
    72ms user@1000.service
    71ms systemd-journald.service
    64ms alsa-restore.service
    63ms polkit.service
    270ms accounts-daemon.service
    247ms lightdm.service
    245ms plymouth-quit-wait.service
    213ms upower.service
    210ms systemd-udevd.service
    207ms systemd-logind.service
    203ms avahi-daemon.service
    190ms apport.service
    186ms keyboard-setup.service
    180ms apparmor.service
    160ms systemd-modules-load.service
    156ms wpa_supplicant.service
    134ms lvm2-monitor.service
    99ms systemd-udev-trigger.service
    92ms nvidia-persistenced.service
    88ms gpu-manager.service
    85ms thermald.service
    83ms lm-sensors.service
    75ms colord.service
    72ms user@1000.service
    71ms systemd-journald.service
    64ms alsa-restore.service
    63ms polkit.service
    62ms rsyslog.service
    61ms dns-clean.service
    52ms systemd-tmpfiles-setup-dev.service
    51ms packagekit.service
    43ms pppd-dns.service
    36ms dev-disk-byx2duuid-5976caefx2d0f66x2d4001x2d9933x2d0d193b9f1937.swap
    34ms systemd-sysctl.service
    33ms rtkit-daemon.service
    25ms dev-mqueue.mount
    25ms blk-availability.service
    24ms kmod-static-nodes.service
    24ms flatpak-system-helper.service
    23ms systemd-tmpfiles-setup.service
    22ms ufw.service
    20ms kerneloops.service
    20ms plymouth-start.service
    18ms sys-kernel-debug.mount
    15ms systemd-rfkill.service
    15ms dev-hugepages.mount
    14ms systemd-remount-fs.service
    13ms systemd-random-seed.service
    12ms systemd-update-utmp.service
    12ms plymouth-read-write.service
    12ms console-setup.service
    10ms systemd-user-sessions.service
    9ms sys-fs-fuse-connections.mount
    9ms systemd-update-utmp-runlevel.service
    7ms ureadahead-stop.service
    4ms openvpn.service
    3ms sys-kernel-config.mount
    3ms tmp.mount
    3ms motd-news.service
    2ms setvtrgb.service

  50. pavbaranov
    4 lipca, 2018 at 15:42

    Pierwszym nie przejmuj się. Dziwi mnie ponad 6 sek. fstrim. Ponad sekunda podnoszenia sieci wynika prawdopodobnie z faktu, że to połączenie WIFI.
    Nie mam systemu z APT, ale popracowałbym nad wszelkimi jego (i tfu, bo to świństwo, packagekit) serwisami. Raz, że – IMO – to w ogóle nie ma prawa być uruchamiane bez zgody roota (ale cóż, to Mint), dwa, że nie jest to potrzebne przy każdym starcie systemu.
    Reszta zależy już od tego z czego korzystasz (np. korzystasz z modemu „komórkowego”?).
    Tak, czy inaczej – owe 31 sek do DE prawdopodobnie jest wynikiem podnoszenia samego DE. Samo polecenie systemd-analyze pokaże Ci realny czas ładowania systemu do userspace.

  51. pavbaranov
    4 lipca, 2018 at 15:45

    Xyzz – zwróć uwagę, że u Marka ta usługa chyba jest podnoszona 2x (nie mam SSD nie znam się na tym – przeanalizuj jego „blame”).

  52. Marek
    4 lipca, 2018 at 16:58

    systemd-analyze
    Startup finished in 18.729s (kernel) + 2.568s (userspace) = 21.297s
    graphical.target reached after 2.555s in userspace

    Coś mi ten trim nie pasuje. Nie usuwam wcale plików a teraz tuż po starcie systemu po sudo fstrim -v / :

    /: obcięto 206,6 GiB (bajtów: 221830623232)

    Po analizie szybkości w tym samym terminalu :

    /: obcięto 801 MiB (bajtów: 839876608)

    Może trzeba zostawić jaką przestrzeń wolną unallocated na overprovisioning ? na moim dysku SSD żeby nie trzeba było trimować 206 GB ?

  53. JanuszBezZiemi
    4 lipca, 2018 at 17:05

    16.04 miał już systemd.
    ostatni z upstart ( „poprawionym” initem od cannonicala) to 14.04

  54. pavbaranov
    4 lipca, 2018 at 17:06

    Jak na SSD długo. Coś pewnie możesz jeszcze popracować. Na SHDD czasy jakie miałem, to od 8 do 13 sek. 21-22sek to czasy dobrego HDD, a nie SSD. Popracowałbym zatem nad usługami i usunął to co zbędne. Chyba, że wystarcza Ci to. Wówczas niczego nie zmieniać. Lepsze jest wrogiem dobrego.

  55. Marek
    4 lipca, 2018 at 17:26

    Ma jeszcze pytanie gdzie ustawia się adres swapa ? Tylko w fstab ? bo zmieniłem niechcący jego rozmiar i system teraz bootuje 3 min. 🙁 Trzeba chyba poprawić adres montowania swapa ?

  56. Xyzz
    4 lipca, 2018 at 19:45

    „Nie mam systemu z APT, ale popracowałbym nad wszelkimi jego (i tfu, bo to świństwo, packagekit) serwisami. Raz, że – IMO – to w ogóle nie ma prawa być uruchamiane bez zgody roota (ale cóż, to Mint)”

    Mint „odziedziczył” apt-daily.service po Ubuntu. „Wymagane” jest to po to, aby manager aktualizacji pokazywał dostępne aktualizacje bez ręcznego sprawdzania.
    https://404.g-net.pl/2017/03/zgin-przepadnij-apt-daily-service/

    „Xyzz – zwróć uwagę, że u Marka ta usługa chyba jest podnoszona 2x (nie mam SSD nie znam się na tym – przeanalizuj jego „blame”).”

    fstrim.service tam wykonuje się tylko raz. Całe te powtarzanie się niektórych unitów wynika albo z błędu przy kopiowaniu albo z błędu podczas edycji komentarza w Disqs (widać powtarzające się fragmenty oraz unity nie są posortowane względem czasu – blame zwraca wyniki posortowane względem czasu malejąco).

  57. Marek
    4 lipca, 2018 at 20:45

    Zrobiłem według instrukcji i wszystko poszło ok. Chociaż instalacja de novo jest szybsza… 😉

  58. Marek
    4 lipca, 2018 at 20:56

    Zrobiłem resize głównej partycji /ext4 i wykasowałem starego swapa , następnie utworzyłem nowego , zostawiając ok. 24 GB unallocated . Następnie poddałem edycji fstab zmieniając UID swapa na nowe mimo to start systemu wydłużył się do 3 min. ! System ma jakiś problem ? Bo start dramatycznie się wydłużył , jak można to naprawić ? Nie chce mi się instalować systemu na nowo 🙁

    Startup finished in 3min 18.991s (kernel) + 2.577s (userspace) = 3min 21.568s
    graphical.target reached after 2.568s in userspace

  59. pavbaranov
    4 lipca, 2018 at 21:37

    Masz Minta, a zatem Ubuntu – jeśli nic nie zmieniałeś, to jest tu swap-file. O reszcie można jedynie domniemywać.

  60. pavbaranov
    4 lipca, 2018 at 21:39

    Nie rób niczego na łapu-capu. IMO – jeśli nic nie stoi na przeszkodzie – postaw tego wariackiego Minta od nowa (skoro to już musi być Mint). Dopiero później zacznijmy to dostosowywać.

  61. Xyzz
    4 lipca, 2018 at 21:44

    Teoretycznie powinno to działać (zakładając wklejenie nowego, poprawnego UUID – po przesunięciu partycji UUID zmienia się i trzeba wkleić nowy, skopiowany dla odpowiedniej partycji. UUID można podejrzeć za pomocą „lsblk -f”).

    1 – można sprawdzić, czy nowy swap jest rzeczywiście wykrywany jako swap.
    „swapon –show” powinno pokazywać coś w tym stylu:
    NAME TYPE SIZE USED PRIO
    /dev/sda5 partition 4G 5.1M -1
    2 – można przejrzeć logi kernela z ostatniego startu systemu za pomocą „journalctl -b -k” w poszukiwaniu błędów/ostrzeżeń

  62. Marek
    4 lipca, 2018 at 22:03

    Dzięki , problem naprawiony dzięki tej stronie :

    https://ubuntu-andrzej001.blogspot.com/2011/07/montowanie-partycji-swap.html

    Następnie przechodzimy do /etc/initramfs-tools/conf.d/resume i wpisujemy aktualny UUID.

    RESUME=UUID=4183e74e-f986-473e-8d97-8dde1973cab7

    Jeszcze aktualizacja iniramfs:

    sudo update-initramfs -k all -u

    Powinno to także naprawić „hibernację systemu”.

    Wszystko 😉

    Startup finished in 18.679s (kernel) + 7.792s (userspace) = 26.472s
    graphical.target reached after 2.617s in userspace

  63. Dario
    4 lipca, 2018 at 22:03

    Witam, u mnie też aktualizacja przeszła bez problemów. Mam zachowane wszystkie ustawienia systemu i programów z wersji 18.3. Jest tylko jedno ale: w przypadku Virtual Box trzeba było zainstalować z repozytorium aktualną wersję Extension Pack (dla wersji ubuntu 18.04).

  64. Arek P
    5 lipca, 2018 at 6:48

    Poleci ktoś do cinnamona aplikację w stylu „gnome do” do uruchamiania aplikacji i wyszukiwania plików/folderów (+ewentualnie przeszukującej zawartość zakładek i poczty)?

  65. Xyzz
    5 lipca, 2018 at 18:33

    Ja mogę polecić „Albert” – https://github.com/albertlauncher

    Indeksuje pliki z wybranych lokalizacji, wyszukuje programy, zakładki z firefoxa/chromium/chrome, ma opcję wyszukiwania w sieci uruchamiającą domyślną przeglądarkę (np. wpisując „gh albert” przeszukam githuba pod kątem repozytoriów zawierających „albert”). Do wyboru ~30 wbudowanych motywów, skrót klawiszowy jest konfigurowalny.
    Są też do tego dostępne zewnętrzne wtyczki – https://github.com/albertlauncher/python

  66. Dario
    5 lipca, 2018 at 20:22

    A jednak pojawiło się i drugie ale: Kiedy próbuję wysyłać dokumenty z Libreoffice za pomocą email nic się nie dzieje mimo tego, że wszystko jest ustawione tak, jak w Mincie Cinnamon 18.3. Też tak macie? Jakaś rada?

  67. Arek P
    6 lipca, 2018 at 7:56

    Dzięki, przetestuję po weekendzie 😉

  68. Martina Neumayer
    6 lipca, 2018 at 8:21

    Uważajcie na nowe jajko w mięcie! Lepiej do tej wersji nie uaktualniać.
    https://bugs.launchpad.net/ubuntu/bionic/+source/linux/+bug/1779827

  69. Marek
    10 lipca, 2018 at 21:41

    Mi działa stabilnie od ponad tygodnia 😉 Aktualizuję na bieżąco i zero problemów , jedynie wifi tp-link czasem się potrafi zwiesić bez żadnego ostrzeżenia. Poza tym super system 😉

  70. Martina Neumayer
    10 lipca, 2018 at 23:53

    Jedynie.. No to jak można mówić o działaniu stabilnym, skoro coś się zwiesza?

  71. Marek
    11 lipca, 2018 at 7:14

    W zasadzie masz rację ale sam nie wiem czyja to wina. Mój sprzęt ma swoje lata i jest nieco wysłużony a ta karta wifi na usb pod Windows XP też czasem potrafi się nieprawidłowo zainicjować i pomaga jedynie wpięcie i wypięcie z portu USB. Gdyby użyć innej karty wifi może wszystko byłoby ok. ?

  72. Martina Neumayer
    11 lipca, 2018 at 7:35

    Nie wiem.. nie wróżę z fusów 😉 Prawdopodobnie jest to karta typu combo, a z tymi są cyrki w linuksach.

  73. Marek
    11 lipca, 2018 at 7:49

    Nie bądźmy drobiazgowi 😉 To PC i konfiguracji sprzętowych mogą być tysiące , trudno żeby wszystko działało idealnie bez grzebania w systemie ? Kliknięcie na wyłącz / włączą komunikację bezprzewodową jestem w stanie zaakceptować o ile nie będzie ono wymagane zbyt często 🙂

  74. Marek
    13 lipca, 2018 at 7:17

    Taka ciekawostka dla wszystkich. Montując dysk SSD wymonotowałem napęd FDD ale nie wyłączyłem jego wykrywania i obecności w BIOS komputera. Dziś użyłem opcji disabled w BIOS i to wręcz dramatycznie skróciło czas bootowania systemu :

    Startup finished in 6.059s (kernel) + 2.503s (userspace) = 8.563s
    graphical.target reached after 2.493s in userspace

    Start systemu Linux Mint 19 jest mniej więcej 2 x szybszy ! Przypadek ? 😉

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Translate »