Megjelent a Debian 12!

Debian

Megjelent az eddig "bookworm" kódnév alatt fejlesztett Debian Linux disztribúció végleges kiadása, elérhető letöltésre a Debian 12! Bejelentés itt. Kiadási megjegyzések dokumentum itt. Telepítési kézikönyv itt. Letölthető innen.

( Ice | 2023. 06. 11., v – 10:24 )

Szerkesztve: 2023. 06. 11., v – 10:28

Kipróbáltam a Live ISO-t: debian-live-12.0.0-amd64-gnome.iso. Szépen megy a gépemen. ventoy-1.0.91 kompatibilis .
Jó lett! :)

( uid_3194 | 2023. 06. 11., v – 11:57 )

Én telepítettem Proxmox alatt (fizikai vasként megy egy QNAP NAS-on az egész) Eddig jó.

( solt87 | 2023. 06. 11., v – 13:06 )

Tegnap este frissítettem a laptopot 11-ről 12-re. Eltartott egy jó darabig, de sikerült -- legalábbis eddig úgy néz ki. :)
Kellemes meglepetés volt látni, hogy a youtube-dl-t gyakorlatilag lecserélték yt-dlp-re, de a pip csomagok $HOME alatti
telepítésének alapértelmezett tiltása némileg meglepett.

( shyciii | 2023. 06. 11., v – 21:41 )

Valamit elkúrtak ezzel a Debian 12-essel.

Nálam:
Debian 11 - 189MB memóriafoglalás boot után
Debian 12 - 506MB memóriafoglalás boot után

Ezután kipróbáltam egy friss minimal teleptést mindennemű grafikai cucc nélkül, csak alap linux, és 360MB felett volt a memóriafoglalás, míg Debian 11 esetén ez 100MB alatt volt.

Látszik, hogy nincs sok közöd a szerverüzemltetéshez (sem). Egy virtuális mondjuk proxmox rendszeren megy úgy 36db gép, és mindegyiknek megdobja az alaprendszer foglaltságát, akkor a hirtelen 84%-os memóriafoglaltság a főgépen olyan mértékben ugrik meg, hogy az veszélyezteti a működést. De ilyen mértékű gondolkodást nyíilván tőled nem lehet elvárni.

El lehetne várni, ha a hozzászólásodból kiderült volna, hogy egy rakás virtuális gépről van szó, nem pedig egy desktop gépről. Milyen kár, hogy ezt elfelejtetted megemlíteni, ugyanakkor pontosan tudni véled, mihez értek, s mihez nem.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Van, akinek ez fontos. A memóriafogyasztás a minimalizmus fokmérője, hiszen egy kisebb memóriafoglalású rendszer kevesebb cuccot tölt be, ami nem csak a memóriafogyasztásban nyilvánul meg, de mivel nem indulnak sallangok, azokat a procinak se kell töltögetni, kevesebb prociidő megy el rá, rövidebb a betöltődési és bootidő. Természetesen RAM-ba sok minden belefér, már vagy 6 éve 16 GB RAM van minden gépemben (előtte is 8 volt, talán 9+ éve volt utoljára olyan gépem, amiben 8-nál kevesebb volt), ami az én igényeimnek overkill, de ha egyszer megfizethető, akkor miért ne. Sőt, ha legközelebb pár év múlva gépet veszek, abban min. 32 lesz, nem kell annyi, de mivel olcsóbb ma már, miért ne tömjem ki rendesen, időtállóságnak se tesz rosszat, integrált GPU-nak is adott esetben van miből foglalni, a rendszernek is nagyobb a cache/buffer-használati mozgástere, stb.. Meg nem romlik, maximum kihasználom tmpfs ramdrive-nak, vagy odaadok többet valami VM-nek, emulátornak, játékok is egyre többet esznek ugyanazon az 1080p-s felbontáson, stb..

Viszont az agyrém, érted, hogy ugyanaz a rendszer, egy újabb verziónál csak a semmiből +300 memóriafogyasztást mutat.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

a kerdes hogy csak az alaprendszer eszik-e tobbet, vagy elinditod a torrent kliens, az ujverzios zenelejatszot, az uj vlc-t, az uj libreofficet azok is tobbet esznek-e. aztan mig regen a 23. programra ranyithattal egy 24.-et, az uj debianon az "olcso memoria" elfogyott, es jon az oom kaszas... 

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

https://tizdolog.hu/2016/09/20/10-dolog-ha-te-is-nyelvtannaci-vagy/

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Magában a "free" működésében volt változás.

https://packages.debian.org/search?keywords=procps

alapján
bullseye: 3.3.17
bookworm: 4.0.2

verzió.  Ha a changelog-ot elolvasod (https://metadata.ftp-master.debian.org/changelogs//main/p/procps/procps…), akkor ezt láthatod benne:

procps (2:4.0.2-1) unstable; urgency=medium

  * New libproc2 library moved into sid
    library: total new API
    free: Used field is now Total - Available
    free: Added Comitted memory option
    [...]

 -- Craig Small <csmall@debian.org>  Mon, 05 Dec 2022 21:59:09 +1100

Feltettem virtuális gépen mindkettőt (11.7 és 12.0). Én nem látok olyan drámai különbséget:

  11.7 12 diff  
MemTotal: 987824 984164 -3660 kB
MemFree: 855868 818676 -37192 kB
MemAvailable: 821440 785052 -36388 kB
Buffers: 7788 8188 400 kB
Cached: 53392 51380 -2012 kB
SwapCached: 0 0 0 kB
Active: 26180 27980 1800 kB
Inactive: 45060 44104 -956 kB
Active(anon): 260 296 36 kB
Inactive(anon): 10288 12736 2448 kB
Active(file): 25920 27684 1764 kB
Inactive(file): 34772 31368 -3404 kB
Unevictable: 0 0 0 kB
Mlocked: 0 0 0 kB
SwapTotal: 998396 998396 0 kB
SwapFree: 998396 998396 0 kB
Zswap:   0   kB
Zswapped:   0   kB
Dirty: 0 0 0 kB
Writeback: 0 0 0 kB
AnonPages: 10100 12552 2452 kB
Mapped: 22424 20844 -1580 kB
Shmem: 488 516 28 kB
KReclaimable: 12904 16048 3144 kB
Slab: 24568 31912 7344 kB
SReclaimable: 12904 16048 3144 kB
SUnreclaim: 11664 15864 4200 kB
KernelStack: 1264 1196 -68 kB
PageTables: 728 608 -120 kB
SecPageTables:   0   kB
NFS_Unstable: 0 0 0 kB
Bounce: 0 0 0 kB
WritebackTmp: 0 0 0 kB
CommitLimit: 1492308 1490476 -1832 kB
Committed_AS: 89936 47216 -42720 kB
VmallocTotal: 34359738367 34359738367 0 kB
VmallocUsed: 30664 32828 2164 kB
VmallocChunk: 0 0 0 kB
Percpu: 424 368 -56 kB
HardwareCorrupted: 0 0 0 kB
AnonHugePages: 0 2048 2048 kB
ShmemHugePages: 0 0 0 kB
ShmemPmdMapped: 0 0 0 kB
FileHugePages: 0 0 0 kB
FilePmdMapped: 0 0 0 kB
HugePages_Total: 0 0 0  
HugePages_Free: 0 0 0  
HugePages_Rsvd: 0 0 0  
HugePages_Surp: 0 0 0  
Hugepagesize: 2048 2048 0 kB
Hugetlb: 0 0 0 kB
DirectMap4k: 67520 61376 -6144 kB
DirectMap2M: 980992 987136 6144 kB

Persze azt valaki megmagyarázhatná, hogy a MemTotal miért változott :)

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree…

MemTotal
              Total usable RAM (i.e. physical RAM minus a few reserved
              bits and the kernel binary code)

Ez alapján az új kernel foglal kicsivel többet.

Csak nem mindegy, hogy az alaprendszer foglalja le a memóriát akár több hibából kifolyólag, vagy becacheli. Jelen esetben nem a cache foglalja le, hanem az alaprendszer, ami kvázi semmivel sem lett több, és ez hiba.

Főleg hogy ha felrakok egy Arch linuxot, vagy ubuntu minimal-t, akkor nincs ez a jelenség. Nyilván majd valamikor javítják itt is, csak addig melózni kell virtuális környezetben, ahol már eleve 80% felett van a terheltség.

Oszinten szolva nem hittem el, ezert feldobtam gyorsan egy Debian 12-est.

Es valoban, bar nalam megallt ~480M korul (vm_dropcaches utan) a szuz telepites. A systemd eszi a legtobb memoriat (nem, a journal nem memoriaban van, diskre logol, mar elmeletileg). Ennel tobbet most nem tudok tesztelni, dolgozni is kell.

De ja, akkor most (se, ) en se fogok kapkodni a frissitessel (a hisztit megelozendo: az en mercemmel merve sok kontenerben futtatok debiant, es nem mindegy hogy mi mennyi).

Akkor nem vagyok egyedül ezek szerint. Közben eszembe jutott, hogy van egy alap Debian telepítés proxmox alatt tesztként. Upgradeltem azt is, és bizony ott is 367MB-al többet foglal a rendszer, úgyhogy részemről egyelőre ennyi a 12-es. Otthoni notin még elszórakozok vele, meg a telepítési scriptemet átírom, mert jópár csomag vagy nincsen benne, vagy át van nevezve, így az új telepítés is elsőnek megfeküdt.

Ebbe futottam én is bele, de Arch-on. Sokáig azt hittem, hogy ez egy 6.4 kerneles bug, közben meg az API változott. Nem csak a free parancsot, de a top, vmstat-ot is érinti. Ezzel zavarban vagyok. Most ez a valós fogyasztás, és régen voltunk átverve, hogy optimistán kevesebbet mutatott, vagy fordítva, régen mutatta a tényleges használt memóriát, és most vagyunk ezzel a megemelkedett értékkel pesszimistán becsapva?

Az is igaz, hogy ez a memóriafogyasztás iszonyat nehezen mérhető, már eleve az is, hogy egy alkalmazás mennyit fogyaszt, meg hogy az egész rendszer. Ennek a kijelzése egyébként más rendszeren is megbízhatatlan, pl. OpenBSD-n szinte ugyanaz a bspwm + polybar + st rendszer 89 MB memóriát evett, ami Arch-on akkor 200 fölött (bár Archon ott a systemd, pulseaudio volt még akkor, meg a Linux kernel, GPU driver is komplexebb, máshogy számolja a fogyasztott memóriát is). OpenBSD-n is épp úgy vmstat-tal és top-pal mérve (BSD-ken nincs free parancs, bár Vermaden csinált hozzá, nem használtam még), azonos gépen, hardveren nézve természetesen.

Már egy alkalmazásnál is vita van, hogy az rss (resident set size) = uss (unique set size, amit a program binárisa eszik egymagában) + shared (használt shared libek) értékét, meg a virtuális memóriát hogy kell figyelembe venni, meg van, aki pss (proportional set size) értéket használ, az a shared értékét szétosztja az összes futó bináris között, ami ugyanazokat a libeket használja, olyan indoklással esküdnek a pss-re, hogy az uss túl alacsony, az rss meg túl nagy, egyik sem valós érték. Linux kernel is a /proc/meminfo alatt figyelembe vesz mindenféle töredezést, pagetables veszteséget, de még slab-et is számol, meg van active, inactive memóriával is keverés (az BSD-ken is van), kész káosz, hogy akkor most melyik mi, az egész cucc tényleg mennyit eszik.

Ha nagyon igazságosak akarunk lenni, akkor a modern Windows sem pontosan jelzi ki a memóriát. Belemér mindenféle cache-t, meg memóriatöredezettséget, meg egyes folyamatok túljelentik, hogy mekkora memóriára van szükségük, így lényegében egyik rendszeren sem tudni, hogy PONTOSAN mi mennyi memóriát eszik, mennyivel éri be, mert még aszerint is változik, hogy mennyi RAM van a gépben, ha pl. 8 gigával nézzük, akkor kisebb memóriafogyasztást ír, mint ugyanazon gépen, rendszer alól 16 gigával, mivel több előre foglalást, igénybejelentést, nagyobb cache-t enged. Ez utoljára talán max. DOS alatt volt világos, hogy mi mennyi memóriát eszik.

Az is igaz, hogy nekünk sem kéne a free parancs used oszlopát fetisizálni, de ugye valamin mérni kell a az egyes szoftveres megoldások, alkalmazások, WM-ek, OS-ek foglalását, hogy össze lehessen hasonlítani, hogy melyik mennyire bloat a másikhoz képest. Ezért én sima processeknél az rss-t veszem figyelembe, kernelnél meg a slab-et. Nyilván a saját rendszeremen, mivel nálam nincs se swap, se zswap, se más extra trükközés (se komplex fájlrendszerek, mint btrfs, ZFS, csak sima ext4 megy, alapbeállításokkal, semmi tömörítés vagy szoftveres titkosítás). A buffers/cache-t sem számolom bele, mert azt bármikor eldobja a rendszer, ha kell a memória, illetve free shared oszlopát sem, mert azt meg a tmpfs-ek foglalják főként, és nem az alkalmazások mérőfoka.

Mindenesetre, ami engem illet, írok magamnak saját free implementációt, ami /proc/meminfo-ból a régi módszerrel számolja, used = total - ( free + shared + buff/cache ) alapon, és nem az új used = total - available módszerrel. Csak a konzekvens számolás miatt, hogy a régi mérésekkel összehasonlítható legyen. Úgyis akartam már ilyet írni, hogy BSD-ken is használni tudjam, ahol csak vmstat/top van.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Teszteltem most már hosszútávon, de ez az utolsó bekezdésben említett implementációm sem az igazi. Boot utáni idle-ben azt mutatja, amit a a free mutatott régen, az API változás előtt. De ahogy használom a rendszert, nő a memóriafogyasztás, akkor az új API-val működő free már visszaegyenlít, és az mutat kevesebbet used memórát, pedig többet kéne neki mutatnia. A htop meg mindkettőnél kevesebbet mutat, mikor a régi rendszerben meg az mutatta a legnagyobb memóriahasználatot.

Szóval nem teljesen nyertem vissza a régi rendszert, de közel van. Mindenesetre csúnyán szétkutyulták az egészet, nem értem, hogy mire volt ez jó akárkinek is. Főleg, hogy shycii kollégát és engem leszámítva senkit se érdekel, akkor viszont már maradhatott volna a régi számolás.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Nekem bootolás után ugyanúgy magasabb maradt az idle így hosszútávon is. Most lefrissítettem Debian 12.1-re, de láthatóan ez már így fog maradni. Ahogy olvastam Archon mindenhol megnőtt ezen felfogás szerint, miszerint máshogy számolják, plusz még a kernel 6.1-es változat is megnövelte. Úgy látszik a linux is kezd elhízni, mint a Windows. Egyre jobban telepakolják már.

Igen, hízik, de nem azért mutat ennyivel többet, hanem máshogy számol, és igen, ez így fog működni, minden 6.4.x-es kernelen, meg a korábbi kernelágakba is vissza van ez portolva, így nem is nagyon függ attól, hogy most 6.1, 5.19 vagy milyen kernelről beszélünk. Én írtam magamnak egy saját megoldást, ami a /proc/meminfo fájlból kiszedi sed és grep parancsokkal a MemTotal, MemFree, Buffers, Cached értékét, és kivonja őket egymásból sorban, ezzel a régi számolási módszer felé konvergál, de mint írtam, nem teljesen sajnos. Közel van, de épp csak annyira nem, hogy idegesítő legyen.

Persze ennek ellenére igen, nő a memóriafogyasztás, bloatosodik a Linux, kernel és systemd hízik, a Pipewire + Pipewire pulse + Wireplumber is jóval többet foglal, mint előtte a pulseaudió, a legújabb grafikus toolkitek, Gtk, Qt legújabb verziói és a rájuk épülő alkalmazások is egyre jobban híznak, X.org, grafikus drájverek is híznak. Sajnos.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Én maradtam a free paranbcsnál, de már az új számolási eljárással:

free -m | grep "Mem" | awk '{print $2-$4-$6}'

De most megcsináltam az általad leírtakar, és kiiratom live annak az értékét is a dwmbar-ra, így akkor össze tudom hasonlítani, hogy melyik mennyit mutat.

numfmt --from=iec --to-unit=1K $(echo "$(($(cat /proc/meminfo | grep "MemTotal" | awk '{print $2}')-$(cat /proc/meminfo | grep "MemFree" | awk '{print $2}')-$(cat /proc/meminfo | grep "Buffers" | awk '{print $2}')-$(cat /proc/meminfo | grep -E "^Cached" | awk '{print $2}')))")

Első blikkre a free parancs konstans kevesebbert mutat az új számolással, mint a meminfo-s.
Amúgy igen tudom, eléggé csúnya a megoldás, biztos lehet szebben és rövidebben megoldani a meminfos számolást, de ez így gyors volt :D

A te megoldásod még elég elegáns, az enyém sokkal gányolósabban ki:

#!/bin/sh
memdata=$(cat /proc/meminfo | sed 5q | grep -E -o "[0-9]+")
set -- $memdata
used_kib=$(expr $1 - $2 - $4 - $5)
used_mib=$(expr $used_kib / 1024)
echo "Used memory: $used_mib MiB"

Kicsit körülményes, mert szándékosan POSIX kompatibilisre írtam, hogy ne dependeljen Bash-re. Bár így is Linuxhoz van kötve, mivel /proc/akármi és /sys/akármi csak Linuxon van, BSD-ken az alábbi módszer alkalmazom, azokon nincs változás:

top -b -n1 | sed -n 4p

Próbálkoztam vmstat-tal is, mert az még univerzálisabb az unix/unixlike rendszerek között, de még nehezebben parse-olható.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Á, azt hiszem megvan a vmstat-os módszer, a vmstat -s segítségével:

#!/bin/sh
memdata=$(vmstat -s | sed 7q | grep -E -o "[0-9]+")
set -- $memdata
used_kib=$(expr $1 - $5 - $6 - $7)
used_mib=$(expr $used_kib / 1024)
echo "Used memory: $used_mib MiB"

Ez egy kicsit még kevesebbet mutat, mint az előző megoldás, már a htop-pal van párban. Az eltérés oka az, hogy a /proc/meminfo és a vmstat más cache-méretet jelez ki. Viszont ennek a vmstat-os módszernek működnie kell BSD-ken is, és így nem kell a top-pal ökörködni.

Így sem az igazi, mert így már kevesebb used memory-t mutat, mint korábban, az API változása előtt a free. Mindenesetre ez a megoldás van a legközelebb a régi állapothoz, annak ellenére, hogy nem tökéletes.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Igen, valóban. Ez a free + awk pár megával többet mutat, mint a vmstat, szóval lehet tökéletesen ugyanazt mutatja, mint a régi free. Én viszont nem bánom a különbséget, a vmstat alapján 1-3 MB-tal kevesebb used memory jön ki, de legalább BSD-ken is működik.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

A kernel hízik? Megszűnt a fordítás előtti konfigurálhatósága? Routeremen is Linux fut.

A pipewire működik, mindezt a pulseaudioról nem lehet elmondani, de ettől függetlenül szabad használni, ha jobban tetszik.

FYI, már nem 4118-as (4801) SRAM-ért (1k x 8 bit) megyünk a Kruzslák Béla utcába, szóval a hardware is vastagodik, amin a software fut.

Vagy mit vársz? Menjenek a programozók előbb nyaralni, utána kiflit sütni, s álljon meg a software-ek fejlesztése, elértük minden idők legfejlettebb állapotát?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Kódsorra hízik, meg a generic disztrók generic kernelei is. Nincs mindenkinek meg az ideje és/vagy tudás, hogy saját kernelt forgasson, optimalizáljon magának. Akinek megvan, az meg úgyis Gentoo-t használ.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Persze, mert a gyártók kitalálnak új hardware-eket, a kernelnek meg ezzel is kellene valamit kezdeni. Ha nem hízok, akkor meg sírás van, hogy jaj, milyen rossz a linux hardware támogatása. Egyébként ezen a téren sokat fejlődött a linux, kb. egy bármilyen véletlenszerűen kiválasztott vasra fel lehet tenni gond nélkül.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( locsemege v | 2023. 06. 11., v – 22:44 )

Ebben már van legalább 2.6.1325-ös kernel, vagy még 2.4-essel szállították? :P

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem meglepő annyira. A Debian azért fejlődött ezen a téren, annyira nincsenek lemaradva vészesen a verziókkal, mint 5-10 éve voltak. Nem azt mondom, most se a frissesség fellegvára, csak az elmaradásuk nem olyan durva, hogy viccet lehessen belőle csinálni.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( hyperborg | 2023. 06. 12., h – 06:32 )

A g++-t és egyéb compilációd cuccokat is felrak by default, vagy csak a szemem káprázott?