Home  >  okolice

Ubuntu 18.10 Cosmic Cuttlefish dla znudzonych 18.04

To już pewne. Będzie kolejne wydanie dystrybucji Ubuntu. Ale w to raczej nikt nie powątpiewał i niewiadomymi do tej pory były bardziej takie kwestie jak nazwa kodowa i zapowiedź zmian „pod maską”. A trochę ich będzie.

Ubuntu 18.04 LTS
Ubuntu 18.04 LTS zostało przyjęte z umiarkowanym entuzjazmem. Domyślne środowisko GNOME nadal potrafi żyć własnym życiem i pożerać zasoby na swoje nieuzasadnione potrzeby, instalator nie pozwala szyfrować katalogu home, no i na dokładkę ta nieszczęsna telemetria, tak demonizowana w kręgach bojowników o prywatność. Jednak z czasem do środowiska pojawią się stosowne łatki, instalator i tak większość z nas zobaczy raz lub dwa razy w ciągu życia tego wydania, a telemetria. No cóż, bardziej transparentnie nie można chyba już jej nikomu przedstawić, niż tak jak uczyniono to w 18.04. Innymi słowy, z tym wydaniem najspokojniej doczekamy kolejnego wydania LTS. No chyba, że ktoś się ogromnie nudzi i wciąż wypatruje nowych wyzwań.

Dla takich pionierów dobrą nowiną będzie informacja o rozpoczęciu prac nad kolejnym wydaniem, tym razem Ubuntu 18.10 Cosmic Cuttlefish. Jak przystało na wydanie „przejściowe” będzie wspierane przez kolejne 9 miesięcy począwszy od października 2018 kiedy to ma mieć miejsce premiera tego systemu.

Co przyniesie nam ta wersja? Przypuszczalnie będzie to GNOME 3.30 (zapowiedziane na wrzesień bieżącego roku). Przypuszczalnie całość będzie już okraszona nowym tematem graficznym. GCC 8, OpenJDK 11, Python 3.7 to techniczne ciekawostki dla deweloperów. Zmianie ulegnie również instalator systemu, wobec którego są plany… Przepisania do HTML5 i wykorzystania Electrona.

Pomimo faktu, że pojawiły się już niemal oficjalne doniesienia o rozpoczęciu prac nad 18.10, to nadal czekamy na dedykowaną stronę temu wydaniu stronę Wiki. Tam z pewnością zostanie wyjaśnione wiele kwestii i przepowiedni.

A na zakończenie wiadomość która może zasmucić niektórych użytkowników. Prawdopodobnie wraz z pojawieniem się 18.10, wsparcia dla 32bitowego obrazu instalacyjnego zaniechają niemal wszystkie (wszystkie?) odmiany Ubuntu.
 

Tags:

22 komentarze

  1. Cyt.”Prawdopodobnie wraz z pojawieniem się 18.10, wsparcia dla 32bitowego
    obrazu instalacyjnego zaniechają niemal wszystkie (wszystkie?) odmiany
    Ubuntu.” no i prawidłowo i tak dość za długo była wspierana ta architektura.

  2. Nie podzielam entuzjazmu. Wiele osób wciąż z pełnym sukcesem używa starych laptopów np. w firmach. Sam w domu mam HP z procesorem 32 bitowym, którego z przyjemnością odpalam podczas wyjazdów. Być może trzeba będzie go rozdzielić z Xubuntu.

  3. Electron? Dlaczego? Ta zrąbana moda zawędrowała nawet tutaj? Serio jest jakiś realny powód by przepisywać intalator na chrome w innym opakowaniu?

  4. Czekam aż Ubuntu przepiszą na electrona.
    Zaczyna się robić śmietnik.

  5. Mint 19 będzie w wersji 32 bit,i jest Mint 19 XFCE.
    Witam i zapraszam:)

  6. Nie rozumiem to parcie na JavaScript, aplikacje napisane w Elektronie są w gruncie rzeczy opasłe jest tam ładowany cały ten kompilator V8 od Google/Chromium. Nie lepiej było wybrać Pythona, szybkość podobna do JavaScript. W ogóle który to standard języka JS, jest to ES5, czy ES6?

  7. Wady Electrona.
    Wynikowy rozmiar aplikacji to co najmniej ~50MB – wynika to z wagi samego Chromium i V8 oraz kodu Electrona,
    Brak ochrony kodu źródłowego – nie ma (i raczej w najbliższej przyszłości nie będzie) możliwości ukrycia kodu aplikacji przed oczami ciekawskich :),
    Bardziej złożone aplikacje mogą wymagać skompilowania modułów node.js na konkretnej platformie,
    W wypadku bardziej wymagających obliczeniowo aplikacji musimy pamiętać, że aplikacja przeglądarkowa będzie mniej wydajna niż dedykowana aplikacja desktopowa.

  8. Zapomniałeś dodatkowo o ogromnym zapotrzebowaniu na ram, dosyć sporym zapotrzebowaniu na procek, braku integracji z motywami systemowymi i kiepskiej integracji z systemem.

  9. “Brak ochrony kodu źródłowego – nie ma (i raczej w najbliższej przyszłości nie będzie) możliwości ukrycia kodu aplikacji przed oczami ciekawskich :),”
    Możesz rozwinąć?

  10. Python, ponieważ korzysta ze skompilowanych bibliotek, jest ZNACZNIE szybszy od JS, moim skromnym zdaniem. No i posiada natywne biblioteki graficzne jak GTK. Też nie rozumiem tej decyzji deweloperów…

  11. Też nie rozumiem tej decyzji deweloperów… – Canonical i wszystko jasne 🙂
    Nie wyszło z Unity8, Mir i co tam jeszcze, to znowu zaczynają wymyślać koło na nowo, ech …

  12. Ja się nawet nie pytam dlaczego Electron, ale… dlaczego w ogóle? Canonical ma tyle sił i środków? Do wyboru jest co najmniej jeden uniwersalny instalator dystrybucji, a dalszych dwu (w zasadzie jednego, ale w dwu wersjach) nie jestem w 100% pewny, czy można go przenieść do dowolnej dystrybucji; kilka jeszcze też czeka w tle. Pierwszy z nich stał się na tyle już popularny, że sięga po niego co raz więcej mniej czy bardziej popularnych dystrybucji. Zatem po co? Jeśli coś w tym instalatorze jest do zrobienia, to być może połączyć siły. No, ale do tego trzeba mieć zarząd spółki, który się zna na pomysłach przedstawianych przez jej pracowników.

  13. To jaki stary jest ten laptop? Procesory 64-bitowe są powszechne w komputerach chyba od 15 lat, jak nie dłużej…

  14. Czy czasem Gnome Shell nie jest czasem przerobionym silnikiem Electrona z efektami pisanymi w javascripcie?

  16. To jest Javascript, który ze swej natury nie ma takowej ochrony kodu bo nie jest kompilowany.
    Może jedynie zostać zaciemniony poprzez różne automatyczne procesy typu transpilacja, optymalizacja itp.
    Kod będzie wtedy niezbyt czytelny dla człowieka ale wykonywalny przez silnik js. Taki kod da się często automatycznie przywrócić do stanu względnej czytelności, nazwy funkcji i zmiennych znikną, ale struktura kodu zostanie.

    Można spróbować emscripten i kompilować z c do js. Można też użyć webAssembly żeby jeszcze bardziej zaciemnić kod w C, będzie wtedy całkowicie nieczytelny dla większości ludzi, to już prawie jak kod maszynowy.
    Czyli ogólnie da się w jakimś stopniu chronić kod źródłowy, ale może to być trudne i upierdliwe, a i skuteczność pozostawia często wiele do życzenia.

  17. Nie o to mi raczej chodziło. To, że Electron ma otwarty kod, to wiem. Wchodzę na https://github.com/electron/electron i mam. Czy jest on chroniony? W zależności od tego w jakim ujęciu. Jeśli prawnym – tak, jest chroniony przez m.in. licencję MIT (nie tylko i nie wyłącznie, bo w głównej mierze przez prawo autorskie). W innym?
    Twoja wypowiedź jakby próbuje wskazywać na to co zrobić, by ów kod nie był czytelny dla innych osób. Mniejsza o to, że nie bardzo wiem, co czytelność kodu ma wspólnego z jego ochroną, ale chciałbym po prostu wiedzieć co złego jest w… otwartym kodzie. Bo, chyba do kwestionowania sensu owej otwartości wypowiedzi te zmierzają.
    Nie wiem, zatem czekam na wypowiedź RedoxOSa.

  20. Czy aby możliwość tworzenia każdego elementu systemu według własnego pomysłu nie jest przedstawiana jako jedna z największych zalet systemów GNU/Linux?

    Oczywiście, można połączyć siły i wspólnie rozwiązać problemy trapiące jakiś komponent, choćby omawiany instalator. Po co jednak zajmować się czymś tak prozaicznym, jak porozumienie i kompromis?

  21. “instalator nie pozwala szyfrować katalogu home, no i na dokładkę ta nieszczęsna telemetria, tak demonizowana w kręgach bojowników o prywatność”
    szyfrowanie katalogu? nie lepiej całą partycję, to bezpieczniejsze. ta telemetria ma pomóc Canonical ze wsparciem. Canonical nie ukrywa jakie informacje od nas wyciąga. Mam nadzieje że będzie bardziej dopracowane niż 18.04

  22. W nextbookach były jeszcze po 2010 roku. Sam mam Eee PC z 32 bit prockiem.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Post comment

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.