Ubuntu 18.04 LTS Bionic Beaver

[Eesaurus]

https://feaneron.com/2018/04/20/the-infamous-gnome-shell-memory-leak/
Nyt on ainakin yksi korjaus muistivuotoon olemassa ja suorituskykyparannuksia tiedossa. Mukavaa.

Joo, muistivuoto-ongelmat ovat ainakin minulla poissa 18:04:ssä. Nytkin ollut kone aamusta asti päällä ja gnome-shell -prosessin muistinkulutus on luokkaa 350Mt.

[mrl586]

Aakkosjärjestys on eräs asia, joka määrittää pakettien tuoreuden apt:n näkökulmasta, mutta ovatkohan Ubuntun kehittäjät ottaneet tätä huomioon lainkaan Ubuntun koodinimiä määritellessään?

[jekku]

Aakkosjärjestys on eräs asia, joka määrittää pakettien tuoreuden apt:n näkökulmasta, mutta ovatkohan Ubuntun kehittäjät ottaneet tätä huomioon lainkaan Ubuntun koodinimiä määritellessään?

Kerros lisää, miten (ja mihin) se vaikuttaa?

[Eesaurus]

author=juhisi link=topic=52613.msg407172#msg407172 date=1524376975]
Joo, muistivuoto-ongelmat ovat ainakin minulla poissa 18:04:ssä. Nytkin ollut kone aamusta asti päällä ja gnome-shell -prosessin muistinkulutus on luokkaa 350Mt.

Itsellä näyttää gnome-shell:in muistinkulutukseksi vähän yli 260 megaa, sama oli illalla kun sammutin koneen.

Ok. Ennen korjausta meni minulla varmaan 2-3 gigaa pelkästään ko. prosessille, jos kone oli ollut koko päivän päällä. Sitten jos oli vaikka Chrome päällä ja useita välilehtiä auki, niin kokonaiskulutus saattoi olla luokkaa 6-7 gigaa.

[Tomin]

Ubuntun kehittäjiltä ihmeellistä pelle touhua noissa päivityksissä. Jo hyvän aikaa sitten Gnomesta tuli 3.29 versio, mutta julkaisu päätetty tehdä 3.28:lla.

3.28 on uusin vakaa. 3.29 on kehitysversio 3.30:ä varten. Gnomen versionumeroinnissa nuo parittomat versiot ovat kehitysversioita.

[nm]

Ubuntun kehittäjiltä ihmeellistä pelle touhua noissa päivityksissä. Jo hyvän aikaa sitten Gnomesta tuli 3.29 versio, mutta julkaisu päätetty tehdä 3.28:lla.

3.28 on uusin vakaa. 3.29 on kehitysversio 3.30:ä varten. Gnomen versionumeroinnissa nuo parittomat versiot ovat kehitysversioita.

Tiedän. Pointti on siinä että tuo vakauden tavoittelu on viety jo korvia hivelevälle tasolle 

Ubuntussa vakauden tavoittelu ja varmistaminen ei kyllä ole läheskään samalla tasolla kuin mitä se on vakavasti otettavissa kaupallisissa jakeluissa, kuten Red Hat Enterprise Linuxissa. Nytkin siellä mennään edelleen kernelin versiossa 3.10.  GNOME sentään päivittyi RHEL 7.5:ssä tuoreeseen 3.26-versioon.

[Hajakenttä]

Tuanoinnii, pitääkö olla huolissaan? Bionic päivittyy runsaasti joka päivä ja välillä siivoaa jälkiäänkin. Tänään huomasin hassun jutun: Päivitys poisti vanhan kernelin headerin ja imagen ja jotain muutakin ja / osion tilavuus pieneni 7,7 GiB:sta 7, 28 GiB:uun. Ei siinä mitään, mutta sain päähäni ajaa vielä siivouksen päätteessä ja tilavuus pieneni 7,0 GiB:uun. Siis mielestäni 280 MiB lähti, vai enkö osaa laskea? Nimittäin pääte kertoi poistavansa 283 kt (kilotavuako) näin:

Koodia: [Valitse]

vtwin@vtwin:~$ siivoalevy
[sudo] salasana henkilölle vtwin:
Luetaan pakettiluetteloita... Valmis
Muodostetaan riippuvuussuhteiden puu       
Luetaan tilatiedot... Valmis       
Seuraavat paketit POISTETAAN:
  libnfs8*
0 päivitetty, 0 uutta asennusta, 1 poistettavaa ja 0 päivittämätöntä.
Toiminnon jälkeen vapautuu 283 k t levytilaa.
Haluatko jatkaa? [K/e] k
(Luetaan tietokantaa... 210322 tiedostoa ja hakemistoa asennettu tällä hetkellä.)
Poistetaan libnfs8:i386 (1.11.0-3)...
Käsitellään paketin libc-bin (2.27-3ubuntu1) liipaisimia...
Luetaan pakettiluetteloita... Valmis
Muodostetaan riippuvuussuhteiden puu       
Luetaan tilatiedot... Valmis       
Del command-not-found 18.04.2 [5 184 B]
Del libnautilus-extension1a 1:3.26.3-0ubuntu1 [15,3 kB]

Ja niin edelleen hyvin pitkä rimpsu, jota en kokonaan kopioi, mutta siellä on useita parin kymmenen megan osia joukossa.

Tuo "siivoalevy" on alias, kun en koskaan muista ulkoa koko loitsua, se on näin:

Koodia: [Valitse]

alias siivoalevy='sudo apt-get autoremove --purge && sudo apt-get autoclean'
Onkohan kysymyksessä bugi, vai olenko ymmärtänyt asian jotenkin väärin?




Ja jos passaa niin kysyn toistakin asiaa samalla:

Jos vanhaan koneeseen pitää asentaa Bionic ja päättää: laittaako 32-bit vai 64-bit jakelun, ja kysyy nyt olevalta 16.04 Ubuntulta näin:

Koodia: [Valitse]

uname -m
ja se vastaa joko 'i686' tai 'X86_64' niin tarkoittaako se laitteen rautojen bittisyyttä vai nyt sisällä olevan Ubuntun jakelun bittisyyttä?

Kyllähän sen tietysti voi koittaa, asentuuko 64 bittinen, mutta pääsisi vähemmällä jos tietäisi kumman lataa ja valmistelee asennuksen yli 10 vuotta vanhaan laitteeseen.

[Hajakenttä]

Ubuntu 18.04 julkaistaan vain 64-bittisenä. Kubuntu, Xubuntu jne... edelleen saatavana myös 32-bittisinä.

Sikäli helppoa, mutta haluaisin silti tietää: mitä tuo päätekomento oikeasti tarkoittaa.

Tuohon tuttavan koneeseen menee Xubuntu. On niin vanha, mutta kuitenkin kelpo laite. En pääse siihen nyt käsiksi ja omistaja pelkää mustaa ikkunaa. Olisin sitten valmiimpi kun kaveri tulee läppärinsä kanssa kylään.

Kuitenkin hyvä tietää, että Ubuntua siihen ei saa kuten hän tahtoisi, jos se on 32-bit laite. Laittaisin ilman muuta jonkin kevyemmän noin vanhaan laitteeseen. Ennakkotietojen mukaan siinä on 3 GB keskusmuistia. (Voi olla kuitenkin enemmän muistia ja 32-bit Ubuntu, joka ei osoita sitä enempää kuin 3.)

[Tomin]

Ja jos passaa niin kysyn toistakin asiaa samalla:

Jos vanhaan koneeseen pitää asentaa Bionic ja päättää: laittaako 32-bit vai 64-bit jakelun, ja kysyy nyt olevalta 16.04 Ubuntulta näin:

Koodia: [Valitse]

uname -m
ja se vastaa joko 'i686' tai 'X86_64' niin tarkoittaako se laitteen rautojen bittisyyttä vai nyt sisällä olevan Ubuntun jakelun bittisyyttä?

Kyllähän sen tietysti voi koittaa, asentuuko 64 bittinen, mutta pääsisi vähemmällä jos tietäisi kumman lataa ja valmistelee asennuksen yli 10 vuotta vanhaan laitteeseen.

Tuo on käyttöjärjestelmän bittisyys. Laitteiston bittisyyden (PC:llä) näkee siitä onko suorittimen lipuissa (flags-rivi /proc/cpuinfo-tiedostossa) lippu "lm" (long mode) ja se toimii riippumatta siitä onko käytössä 64- vai 32-bittinen käyttöjärjestelmä. Sen voi siis tarkastaa vaikkapa näin:

Koodia: [Valitse]

grep -G '^flags' /proc/cpuinfo |grep -qw lm && echo "64-bittinen" || echo "32-bittinen"

[Hajakenttä]

Koodia: [Valitse]

uname -m


ja se vastaa joko 'i686' tai 'X86_64' niin tarkoittaako se laitteen rautojen bittisyyttä vai nyt sisällä olevan Ubuntun jakelun bittisyyttä?

Kysyin kyllä tätä. Siis jompaa vai kumpaa, laitetta vai käyttöjärjestelmääkö hän vastauksessaan tarkoittaa? Sitten kun sitä tuolla käskyllä häneltä utelen, jotta voin sen uuden sitten asentaa oikein ja vähemmällä sekoilulla.

Niin... ja onko Ubuntu Mate ehkä saatavana myös 32-bit jakeluna tällä 18.04:llä? Sekin saattaisi kelvata Ubuntu Unityyn tottuneelle, kun kuitenkin joku uusi pitää oppia Unityn nyt puuttuessa joukosta.


Jaahas. Tomin ehtikin vastata tuohon. Asia tuli selväksi siltä osin. Kokeilin ja toimii. Kiitos.

Koodia: [Valitse]

vtwin@vtwin:~$ grep -G '^flags' /proc/cpuinfo |grep -qw lm && echo "64-bittinen" || echo "32-bittinen"
32-bittinen
vtwin@vtwin:~$


[Tomin]

Mikähän tässä oikeasti maksaa, ettei 4.16 Kernel päivitystä saada tehtyä vaan pitää vielä tuhlata aikaa ja kikkailla 4.15 Kernelin kanssa... https://lists.ubuntu.com/archives/bionic-changes/2018-April/014349.html

Freeze mennyt jo? Ubuntussa muutenkin ollaan muistaakseni aika konservatiivisia ytimen suhteen, jos vaikka vertaa Fedoraan, jossa se päivitetään uudempaan julkaisujen välilläkin.

https://wiki.ubuntu.com/BionicBeaver/ReleaseSchedule

[nm]

Juu kernel freeze jo ollut ja 4.16 päivitetään varmastikkin pian julkaisun jälkeen. Pointti asiassa on se, että miksi nyt tehdään tälläistä näpertely päivityksiä 4.15 kerneliin, joka on jo kolmas tälle viikolle ja käytetään aikaa täysin turhaan kikkailuun jolla loppupeleissä ole mitään merkitystä.

18.04:n kerneliksi on päätetty versio 4.15, eikä suunnitelmiin ole tietääkseni tulossa muutoksia. Sen kanssa näperrellään siis seuraavat viisi vuotta, joskin helmikuussa 2019 julkaistavasta 18.04.2:sta lähtien rinnalle tulee myös uudempia versioita vaihtoehtoina.

Julkaisusuunnitelma on wikissä, kuten ennenkin: https://wiki.ubuntu.com/Kernel/Support#A18.04.x_Ubuntu_Kernel_Support

[nm]

Okkei, tuo selvensi asioita. Kernelissä on edelleen Spectre ja Meadow problematiikkansa, joita paikkaillaan / korjaillaan vieläkin nyt kehityksen alla olevassa 4.17 versiossa. 4.16 kerneliin jo jotain saivat korjattua ja on siellä tietysti muutakin. Mutta kylläpä nuo kernel tiimin porukat tietää mitä tekevät, vaikka vähän vaikea sitä on ymmärtää 

Kriittiset korjaukset backportataan jakelun virallisiin ytimiin. Sitähän nämä jakelujen kernelitiimit pääasiassa tekevät.

[kamara]

Joka kertainen tyhmä kysymys, milloin tämä julkaistaan.

http://cdimage.ubuntu.com/lubuntu/releases/

Viimeisin Daily-live on eiliseltä. Se taitaa olla varsin sama kuin virallinen, mutta monelta se virallistetaan ?

.. ja virallistetaanko Lubuntu myöhemmin kuin Ubuntu ?

[tikola]

Tuossa on keskustelu edelliseltä kerralta.

https://forum.ubuntu-fi.org/index.php?topic=49564.msg387085#msg387085

Tiivistäen voisi todeta

Lataussivu päivittyy lähitunteina - meidän iltapäivän mittaan

Koneet ryhtyvät kertomaan päivittyneestä versiosta daily liven aikataulun mukaan, eli joskus iltasella meidän aikaa.

Jos menee jotenkin toisin, niin sitten käsitykseni on väärä ja sitä saa oikaista

[raimo]

Siellä on http://releases.ubuntu.com/bionic/

[LMJ2368]

Kuinkahan tähän pitäisi suhtautua tuollaisen erittäin suorituskykykriittisen 12 vuotiaan koneen kanssa, kun miettii vaihtaako 16.04:stä 18.04:ään?
(On niin monen näköisiä pylväitä, enkä ehdi pariin päivään perehtyä niihin.)

https://www.phoronix.com/scan.php?page=article&item=ubuntu-1004-1804&num=1

[jekku]

Mihin kannattaisi olla yhteydessä kun edelleen muuan prosessi sieppää prosessoritehoa:
Eli systemd-udevd

Kun koetan tappaa nuo,

Koodia: [Valitse]

killall systemd-udevd

Niin nousee uudellen

Tosin, mahtaako Ubuntu-projekti tuolle mitään osata tehdä, sama 'tauti' Debian Testingissäkin.

Toistaiseksi olen kokeillut vain Dellin läppäreissä, E5400 ja E5500.
Jos keksin joutilasta rautaa niin pitänee kokeilla muidenkin kokoamissa laitteissa.

Edit:
Löytyi Lenovo T60 jonka Debianin päivitin  busteriin.
Siinä ei tuo systemd-udevd kiukuttele.

No, kyseessä 32-bittinen, eri merkkinen kone joten todistusvoima lienee vähäinen.

[nm]

Mihin kannattaisi olla yhteydessä kun edelleen muuan prosessi sieppää prosessoritehoa:
Eli systemd-udevd

Kokeile kytkeä bluetooth pois päältä.

[jekku]

Nyt en olekaan varma onnistuinko.
Kun kysyn statusta niin vastaa jottas

Koodia: [Valitse]

... disabled; vendor preset: enabled
Active: inactive (dead)
Mutta merkkivalo palaa ja tuo systemd-udevd yhtä ahkerana kuin aieeminkin.