A megszokott hét helyett nyolc -rc után Linus végül kiadta a 6.19-es Linux kernel végleges verzióját:

6.19: mainline Version: 6.19 (mainline) Released: 2026-02-08 Source: linux-6.19.tar.xz PGP Signature: linux-6.19.tar.sign Patch: full https://t.co/IgdwnXcVM2 #linux #kernel

— Linux Kernel Releases (@LinuxKReleases) February 9, 2026

Bejelentés:

The current estimate for Git 3.0 appears to be some time “second half of 2026” (this year).

And, with the release of Git 3.0, Rust will now be a mandatory part of the Git build process.

What this means:

- Git will have reduced platform support — including difficulty compiling… pic.twitter.com/vbIbg685g3

— The Lunduke Journal (@LundukeJournal) February 3, 2026

With Git Moving to Rust, How Long Until a Git Fork?

Git 3.0 is scheduled to ship "second half of 2026", with a mandatory requirement of Rust. Which means Git will no longer build on many platforms. Setting the stage for a successful fork. pic.twitter.com/c7REwdeNHJ

— The Lunduke Journal (@LundukeJournal) February 7, 2026

Eric S. Raymond - az nyílt forráskódú fejlesztés atyja - az LLM-mel való programozásról:

Az AI-segédlettel való programozás nagyon leleplező. Kiderül, hogy nem egészen az vagyok, akinek hittem magam.

Rengeteg programozó van odakint, akiknek az egójukból és identitásukból óriási mennyiség van befektetve a kódolás mesterségébe. Abba, hogy tudják, hogyan kell hasznos és helyes viselkedést kicsikarni egy nyelvből és rendszerkörnyezetből — vagy még jobb, sokból.

Ha egy hete megkérdeztél volna, talán azt mondtam volna, hogy én is egy vagyok ezek közül. De valami furcsa dolog történt. Az LLM-ek mostanra olyan jók, hogy rengeteg kódot tudok ellenőrizni és előállítani úgy, hogy gyakorlatilag alig írok bármit kézzel.

És kezd leesni, hogy nem is hiányzik.

Érdekes módja annak, hogy rájöjjek: én mindig is elsősorban rendszertervező voltam, és a kód csak eszköz volt, nem cél. Én... ezt magamról valójában eddig nem tudtam.

Ide illessz be egy közhelyes idézetet arról, hogy minden felfedezőút végül önmagunk felfedezésével ér véget. Ez most tényleg megtörtént.

Kissé zavarban vagyok.

Programming with AI assistance is very revealing. It turns out I'm not quite who I thought I was.

There are a lot of programmers out there who have a tremendous amount of ego and identity invested in the craft of coding. In knowing how to beat useful and correct behavior out of…

— Eric S. Raymond (@esrtweet) February 5, 2026

Elérhető a népszerű, nyílt forráskódú irodai programcsomag, a LibreOffice 26.2-es kiadása. Benne számos új funkció, hibajavítás és teljesítményjavulást célzó fejlesztés:

Big new update to #LibreOffice, the free and private office suite. Version 26.2 is here, with:

📝 Markdown support
📊 Connectors in Calc
🚀 Spreadsheet speedups

...plus many other new features, improvements and fixes. Learn more and download it: https://t.co/SKQHqZn22f pic.twitter.com/Wk6aY8Eoyy

— LibreOffice (@LibreOffice) February 4, 2026

A fejlesztő által felsorolt lehetséges okok közt első helyen szerepel, hogy a Rust nem elérhető számos olyan architektúrán, amit a NetBSD támogat:

[...]

Note that in general, NetBSD is more conservative in its technical decisions than FreeBSD or Linux. Rust in the core of NetBSD is probably a non-starter for multiple reasons:

• There are many architectures that NetBSD supports where Rust is not available. This is probably the most important argument against Rust.
• Today, even getting a Rust compiler running in the first place is hard. Keeping Rust working (in pkgsrc) is quite a bit of work, resting on the shoulders of a few developers.
• In general, the bootstrap relies on a binary package of the previous version. This is unacceptable for an otherwise source-only, self-contained distribution like the NetBSD sources.
• For Rust to be used in base or in the kernel, the compiler would also have to be part of the base system. This means adding a lot of code and maintenance. It would not be impossible though – we already have LLVM (a major dependency) in base. But again, the binary bootstrap kits are a significant hurdle.
• Finally, the release cycles of Rust are not compatible with the NetBSD ones. We support the last two major releases. Today, that’s NetBSD 9 and 10. NetBSD 9.0 was released in 2020. Rust 1.41 was the current version back then. If Rust 1.41 had been part of NetBSD 9, it would be useless for anything except compiling NetBSD itself – Rust 1.41 is so old that basically no modern code would compile with it. Not great.

[...]

Részletek itt.

Nos, ott hagytuk abba, hogy felszálltam a nosztalgiavonatra és retró szarokba kezdtem életet lehelni. Így került antiX Linux a több mint 20 éves, 1 GB (pontosabban 1 GB és 256 MB) RAM-ot tartalmazó laptopomra, ami szuperül szuperál rajta. Itt a sztori egy időre hibernálásra is kerülhetett volna, ha ... ma reggel nem láttam volna meg a blog szekcióban a "FLOPPINUX - Beágyazott Linux egyetlen floppy lemezen" bejegyzést. Ez megint csak nosztalgiával töltött el. Miért?

Mert volt olyan ügyfelem, amelyiknél több mint 10 évig a tűzfal szerepet egy 1 darab 3,5"-os floppy-ról Coyote Linux-ot bootoló Compaq Deskpro töltötte be. (Széljegyzet: abban az időben egy Cisco PIX több százezer forint volt és a VPN usereket külön kellett licencelni 🤭) És az már akkor is csodálattal töltött el.

Így kíváncsi voltam arra, hogy 2025-ben mit tudhat egy ilyen 1 floppy-s Linux ehm... disztribúció ... vagy izé ... Szóval, elővettem az USB-s floppy meghajtómat, kerestem egy 3,5"-os 1,44MB-os floppy-t és fogtam az antix Linux-ot bootoló gépemet ... 

BIOS-ban ellenőriztem a beállításokat ... boot sorrendet (SONY USB-FDU) ...

A nagyobb mainstream Linux disztribútorok már rég eldöntötték a systemd vs. egyéb init rendszerek kérdést, de az olyan hardcore "disztribúciók", mint a Linux From Scratch (LFS) még kitartottak. Eddig. Ugyanis az LFS részéről Bruce Dubbs vonakodva bejelentette, hogy befejezik a System V-t tartalmazó dokumentumaik fejlesztését. Személyes véleményként megjegyezte, hogy nem szereti, de a karbantartási overhead és az upstream irányából érkező nyomás miatt meg kellett hozniuk a döntést:

• From: Bruce Dubbs
• To: lfs-announce@lists.linuxfromscratch.org, LFS Support List <lfs-support@lists.linuxfromscratch.org>, LFS Developers Mailinglist <lfs-dev@lists.linuxfromscratch.org>, BLFS Support List <blfs-support@lists.linuxfromscratch.org>, BLFS Development List <blfs-dev@lists.linuxfromscratch.org>
• Subject: [lfs-announce] Future direction for LinuxFromScratch
• Date: Sun, 1 Feb 2026 20:08:14 -0600

With some regret, LFS/BLFS will no longer be developing the System V versions of the books.

There are two reasons for this decision. The first reason is workload. No one working on LFS is paid. We rely completely on volunteers. In LFS there are 88 packages. In BLFS there are over 1000. The volume of changes from upstream is overwhelming the editors. In this release cycle that started on the 1st of September until now, there have been 70 commits to LFS and 1155 commits to BLFS (and counting). When making package updates, many packages need to be checked for both System V and systemd. When preparing for release, all packages need to be checked for each init system. 

The second reason for dropping System V is that packages like GNOME and soon KDE's Plasma are building in requirements that require capabilities in systemd that are not in System V. This could potentially be worked around with another init system like OpenRC, but beyond the transition process it still does not address the ongoing workload problem. 

In the future, the LFS/BLFS 12.4 System V books will continue to be available. For the most part newer versions of packages in those books will be able to be built with the instructions from there, but will not be tested by the LFS editors. 

The next version of LFS/BLFS will be version 13.0 and is currently has a target release data of March 1st. 

As a personal note, I do not like this decision. To me LFS is about learning how a system works. Understanding the boot process is a big part of that. systemd is about 1678 "C" files plus many data files. System V is "22" C files plus about 50 short bash scripts and data files. Yes, systemd provides a lot of capabilities, but we will be losing some things I consider important. 

However, the decision needs to be made.

-- Bruce Dubbs
linuxfromscratch.org

Igen, -rc8. Igen, normál esetben csak hét release candidate szokott egy ciklusban, de Linus több alkalommal is jelezte, hogy az ünnepek miatt ebben a ciklusban nyolc lesz. Örült is, hogy így döntött, mert az -rc7 a szokottnál nagyobbra sikeredett. Mindenesetre, csak nem történik semmi váratlan, akkor a hét végén megérkezik a végleges 6.19-es kernel.

6.19-rc8: mainline Version: 6.19-rc8 (mainline) Released: 2026-02-01 Source: linux-6.19-rc8.tar.gz Patch: full ( incremental ) https://t.co/IgdwnXcVM2 #linux #kernel

— Linux Kernel Releases (@LinuxKReleases) February 1, 2026

Omarchy saw half a petabyte in package and ISO downloads from nearly 200,000 unique IPs last month! And in terms of new users, it looks like it's 50% Windows, 25% Mac, 25% Linux. So three quarters are conquests from commercial operating systems. Wow.

— DHH (@dhh) January 30, 2026

tl;dr: A többség nem Linux alól érdeklődik felőle. Fél petabyte csomag- és ISO-letöltés közel 200 ezer egyedi IP címről a múlt hónapban ...

Amikor a szerelem, a hivatás megélhetéssé szelídül, a billentyűzet pedig szerszám lesz. A 73. adásban az IT szakma identitásválságáról beszélgettünk.

A megélhetési informatikáról, szakemberekről mindenkinek más jut eszébe. Van, aki generációs okokat lát benne, vannak olyanok, akik cégkultúrában, kiégésben, platón ragadásban, a magas fizetésekben, az életkorban és gyerekvállalásban eredeztetik, de természetesen a nettó lustaság is pakliban van. Van, aki szerint ez probléma. Van, aki szerint ez az új normalitás, az IT tömegszakma lett, előbb-utóbb mindenki megélhetési lesz, a szerelemből szükségszerűen munka lesz, ami már nem képezi az identitásunk alapját. A problémáról nem egyszerű beszélni, főleg nem szakmán kívülieknek, hiszen nehéz azonosulni olyan munkavállalók gondjaival, akik talán mindenkinél jobban keresnek. Jammelős, terápiás adásunk, ahol nem egészen oda jutottunk, amit az adásterv alapján feltételeztünk.

Az adásban elhangzott hivatkozások a Discord csatornánkon érhetők el, ahol még beszélgetni is tudsz velünk, és a többi hallgatóval. Adásainkat megtaláljátok a SoundCloudon, a Spotify-on, az Apple Podcasten, a YouTube csatornánkon, és immár a YouTube Music-on is.

A FreeBSD Projekt kiadott egy biztonsági figyelmeztetőt - FreeBSD-SA-26:02.jail - amiben leírják, hogy egy olyan jail-ben, ami úgy van beállítva, hogy a jail-en belülről engedélyezi a nullfs(4) mountokat, a jail-be zárt root felhasználó ki tud törni a jail fájlrendszerének gyökeréből. Alapértelmezés szerint a jail-be zárt folyamatok nem tudnak fájlrendszereket mountolni, beleértve a nullfs(4)-t is.

Részletek a bejelentésben:

A Linux kernel fejlesztése erősen elosztott, de a mainline-ba történő végső beolvasztás továbbra is egy központi lépés; normál esetben ezt Linus Torvalds végzi. A forrásfában most megjelent egy rövid "project continuity" dokumentum, ami azt írja le, hogy mi történjen, ha a top-level repository fenntartói hirtelen nem tudják vagy nem akarják tovább vinni ezt a szerepet (ideértve az átmenet levezénylését is).

A dokumentum a "konklávé" eljárást rögzíti: a legutóbbi Kernel Maintainers Summit meghívottjait kell összehívni, és velük (a Linux Foundation Technical Advisory Board, TAB bevonásával) gyors döntést hozni a folytatásról.

• $ORGANIZER: alapértelmezetten a legutóbbi Maintainers Summit szervezője, tartalékként a TAB aktuális elnöke.
• 72 órán belül $ORGANIZER megnyitja a témát a legutóbbi Maintainers Summit meghívottjaival, és összehív egy online vagy személyes találkozót (TAB részvétellel) úgy, hogy a lehető legtöbben részt tudjanak venni.
• Ha 15 hónapon belül nem volt Maintainers Summit, akkor a találkozó résztvevőinek körét a TAB határozza meg.
• A meghívottak további maintainereket is bevonhatnak, ha szükséges.
• A találkozó célja: olyan megoldást választani a top-level kernel repository működtetésére, ami a projekt és a közösség hosszú távú egészségét maximalizálja.
• Két héten belül a csoport egy képviselője a ksummit@lists.linux.dev listán tájékoztatja a szélesebb közösséget a következő lépésekről.
• A Linux Foundation (a TAB iránymutatásával) vállalja a szükséges támogatást és a terv végrehajtásának segítését.

Források:

• linux / linux / kernel / git / torvalds / linux / 102606402f4f5943266160e263c450fdfe4dd981
• Linux kernel project continuity
• Succession planning

A HUP fórumban rendszeresen visszatérők szoktak lenni a címben szereplő és ahhoz hasonló kérdések. A napokban a kezembe került az egyik, 20+ éves Clevo laptopom, bekapcsoltam. 

• Intel Celeron M 1.4 GHz "Dothan" processzor
• 1,2 GB RAM
• 160 GB Western Digital Scorpio Blue EIDE merevlemez
• SIS 661/741/760 VGA adapter
• Intel Pro Wireless 2915ABG WiFi adapter 

Rajta 13.04-es Lubuntu, 3.8.0-s kernellel. Mivel az már rég nem frissül, arra gondoltam, hogy naprakész állapotra hozom. Mi baj lehet belőle? A kihívás nagyjából az, hogy a 32 bites CPU-t már alig támogatják a disztribútorok, az 1GB RAM meg elég szűkös manapság. 

Na, de mit tegyünk rá kis erőfeszítéssel, ami nagy nyereséget hoz? Vagyis egy next-next-finish jellegű telepítéssel, kb. 0 konfigolással egy, akár internetezésre is alkalmas rendszert ad: vagyis naprakész biztonsági szempontból, rendelkezik korszerű böngészővel stb. ... Ugyan valószínűleg sose fogjuk erre a célra használni, de mégis ... hátha egyszer ez szükség lesz rá. 

Kiinduló állapot:

Ahogy az a képről látszik, a választás az antiX Linux-ra esett (nem, nem írtam ki, mert csak 700MB-os írható CD volt kéznél, az 1,7 GB-os ISO meg nem fért rá, szóval USB telepítéssel mentem tovább) ... 

Miközben azt látjuk, hogy egy csomó projekt C irányból a "magasabb szintű" Rust felé mozdul, az FFmpeg azt látná üdvözítőnek, ha az alacsonyabb szintű assembly kód aránya nőne kódbázisában. Nemrég arról posztoltak, hogy a kínai Alibaba Group által küldött, kézzel írt assembly kódhozzájárulások akár 14-szer gyorsabbak a C-nél, ezért más vállalatokat is arra biztatnak, hogy kövessék a példát:

We encourage all companies to follow the recent examples of @AlibabaGroup and @TencentGlobal and submit hand-written assembly patches (or other patches) to FFmpeg. https://t.co/EpMcR0UKdY

— FFmpeg (@FFmpeg) January 21, 2026

A beküldött kódok beolvasztásra is kerülnek:

Yes

— FFmpeg (@FFmpeg) January 23, 2026

Később az FFmpeg projekt ismét az assembly-t dicsérte:

Patches with hand written ARM assembly for VVC put_luma functions.

Up to 2.5x faster than C.

The rate of assembly patches in FFmpeg is accelerating! pic.twitter.com/yGoLq6zPQ9

— FFmpeg (@FFmpeg) January 24, 2026

A Slashdot egyik cikke szerint a Microsoft kiadott az FBI részére több Bitlocker recovery kulcsot is, hogy a hatóság azok segítségével hozzáférhessen szövetségi nyomozásban érintett laptopok merevlemezén található adatokhoz:

A Forbes pénteki jelentése szerint a Microsoft egy szövetségi nyomozás részeként átadta az FBI-nak a három laptop merevlemezén található titkosított adatok feloldásához szükséges helyreállítási kulcsokat. Sok modern Windowsos számítógép teljes lemeztitkosítást, az úgynevezett BitLockert használ, amely alapértelmezés szerint engedélyezve van. Ez a technológia megakadályozza, hogy bárki, kivéve az eszköz tulajdonosát, hozzáférjen az adatokhoz, ha a számítógép zárolva van és kikapcsolt állapotban van. [...]

Alapértelmezés szerint a BitLocker helyreállítási kulcsok feltöltődnek a Microsoft felhőjébe backup céllal, lehetővé téve a techóriás – és tágabb értelemben a bűnüldöző szervek – számára, hogy hozzáférjenek ezekhez, és felhasználják azokat a BitLockerrel titkosított meghajtók visszafejtésére, ahogyan az a Forbes által jelentett esetben is történt. [...]

A Microsoft a Forbesnak elmondta, hogy a cég időnként BitLocker helyreállítási kulcsokat ad át a hatóságoknak, és évente átlagosan 20 ilyen kérést kaptak.

Microsoft Gave FBI a Set of BitLocker Encryption Keys To Unlock Suspects' Laptops https://t.co/qAuvm9IeeI

— Slashdot (@slashdot) January 23, 2026

Úgy fest, hogy azután, hogy számos projekthez  - Ubuntu, Devuan, Debian, Gentoo, Slackware, FreeBSD stb. - elérhető nem hivatalos tárolókban már felbukkant az Xlibre, az első nevesebb FLOSS disztribúcióban megjelenik alapértelmezett X szerverként. A GhostBSD projekt vezetője jelentette be, hogy a következő GhostBSD kiadásban már az Xlibre lesz az alapértelmezett display szerverük:

#XLibre will become the default Xserver on #GhostBSD in their next release after the news about the upcoming #Xorg rebase. A big thank you to @ericbsd, https://t.co/naUWk5QZsi, @malco2001, and the whole @GhostBSDproject! #BSD #FreeBSD #X11https://t.co/ndN13QvYfL

— XLibre (@XLibreDev) January 23, 2026

After the news about Xorg rebase, I made @XLibreDev the default display server on GhostBSD for the next release.https://t.co/4UhNKYtleS

— Eric Turgeon (@Ericbsd) January 23, 2026

Megérkezett egy új Windowsos telefon. A Nex Computingnak és a NexPhone-nak köszönhetően egy új okostelefon kerül piacra, amely egyszerre futtat Windowst és Androidot, sőt, dokkolva akár asztali Linuxot is képes futtatni.

[...]

Természetesen teljes Windowst futtat az Armon, mivel a Windows 11-nek nincs tényleges mobil verziója. A Nex azonban egy teljes skin-t tervezett, hogy úgy nézzen ki, mint a Windows Phone felhasználói felülete, amelyre mindannyian emlékszünk és szeretünk. Nemcsak átlátszó csempékkel van ellátva, hanem olyan ismerős funkciókat is tartalmaz, mint a balra húzás az összes alkalmazás listájának eléréséhez.

[...]

Windows Phone is so back! https://t.co/nSFqWClNin

— XDA (@xdadevelopers) January 21, 2026

A bejelentés a 2012-es koncepció videójukra hivatkozik:

Specifikáció itt. Bejelentés itt. Ára 550 dollár körül lesz, elérhetőségére pedig 2026 harmadik negyedévét jelölték meg.

Jó látni, amikor kereskedelmi szoftverek visszaadnak valamit az általuk használt vagy őket inspiráló nyílt forráskódú projekteknek. Most éppen ilyen történt: a Spotify Engineering csapat harmincezer eurós támogatást küldött az FFmpeg projektnek és emellett két másik FLOSS projektet - Mock Service Worker, Xiph.Org Foundation - is támogattak 👍‍👏

Az FFmpeg célja, hogy minden valaha készült multimédiás fájlt lejátsszon. Ennek a célnak az eredményeként széles körben használják, mind a hobbifelhasználók, akik személyes videóikat kódolják, mind a legnagyobb streaming szolgáltatások, mint például a YouTube, a Netflix, az X és a Spotify.

We're pleased to announce that @SpotifyEng has donated €30,000 to FFmpeg!

Thank you Spotify for this very generous donationhttps://t.co/34fOiO3fpv

— FFmpeg (@FFmpeg) January 22, 2026

Három évtizedes fennállását ünnepli egy visszatekintő blogposzttal a Windows helyettesítőt fejlesztő @ReactOS projekt. 30 év telt el az első commit óta. 

Today marks 30th year of #ReactOS. Happy Birthday ReactOS!
We would like to thank everyone for supporting us along our long journey of building a Windows-compatible, free and open source OS!

Read our 30th year blog post here:https://t.co/rVG1I3fq2m

— ReactOS (@reactos) January 22, 2026

Akik a projekt végére fogadtak valaha az elmúlt évtizedekben, az rosszul tette: a hozzájárulók világossá tették, hogy a projekt folytatja a ReactOS fejlesztését.

Apropó fejlesztés: több mint 10 évnyi fejlesztés eredményeként bekerült az aszinkron TCP támogatás a ReacOS-be, aminek köszönhetően a felhasználók számottevő teljesítményjavulást tapasztalhatnak minden olyan alkalmazásban, ami letöltéssel, hálózatkezeléssel kapcsolatos, így például böngészőkben, torrent- és FTP-kliensekben, letöltéskezelőkben ... 

Thanks to our contributors Peter Hater, Emanuel Gonzalez, Julio Carchi Ruiz, Thamatip Chitpong, Mikhail Tyukin; and all other people tested!

See the PR here for more information: https://t.co/ryoWfalVXH

— ReactOS (@reactos) January 18, 2026

Videó:

Raspberry Pi Flash Drive - az ígéret szerint Raspberry Pi 5-höz optimizált, stabil USB 3.0 teljesítményű, erős random és szekvenciális IO teljesítmény, SMART monitorozási lehetőség, szerény fogyasztás. Elérhető 128 GB-os és 256 GB-os méretekben.

Introducing the Raspberry Pi Flash Drive, designed to provide reliable storage capacity for Raspberry Pi and other compatible devices.

The Raspberry Pi Flash Drive is optimised for Raspberry Pi 5, offering sustained USB 3.0 performance, strong random and sequential I/O…

— Raspberry Pi (@Raspberry_Pi) January 22, 2026

Egy hosszabb cikk jelent meg az Android Headlines oldalon a OnePlus összeomlásáról és leállásáról. A OnePlus India egy közleményt adott ki, miszerint a szokásos ügymenet szerint működnek és ezt továbbra is folytatni fogják. A OnePlus Észak-Amerikai divíziója szintén jelezte, hogy működnek:

OnePlus North America continues to operate, with full guarantee of users’ after-sales support, software updates, and rights commitments.

I wanted to address some misinformation that has been circulating about OnePlus India and its operations. 
We’re operating as usual and will continue to do so.
Never Settle. pic.twitter.com/eAGA7iy3Xs

— Robin Liu (@RobinLiuOnePlus) January 21, 2026

A KDE / plasma-login-manager dobta a FreeBSD támogatást biztosító kódokat és egyértelművé tette, hogy a plasma-login-manager a systemd/logind párosra épít, ezért a FreeBSD-t mostantól nem támogatja:

We rely on systemd/logind, so FreeBSD is not supported

Egyesek ebből tévesen azt a következtetést vonták le, hogy a KDE dobta a FreeBSD támogatást:

Oh, it’s trully sad to see support of FreeBSD and other non-systemd systems dropped 😭

A kódhozzájáruló tisztázta a helyzetet: a plasma-login-manager systemd-t használó Linux rendszerekhez készült. Ha valaki nem ilyen rendszert használ, az használja az SDDM-et, azt is támogatja a KDE: 

This project is for Linux systems using systemd. If you're using a non-systemd system, use SDDM. It's still supported by KDE.

Persze, mindig vannak értetlenek:

#SRLY ? You drop #freebsd support?

Erre válaszként megerősítése került, hogy a KDE NEM dobta a FreeBSD támogatást, itt kizárólag a plasma-login-manager-ről van szó:

 We didn't drop FreeBSD support from KDE. Plasma Login Manager isn't all of KDE. It's intended to integrate with systemd features. We still recommend SDDM for everything else.

☝‍️

KDE removed FreeBSD support from Plasma login manager stating that KDE/Plasma relies systemd(1)/logind(1) Linux daemons.

FreeBSD should not waste time to work on adding KDE/Plasma desktop install button in bsdinstall(8) installer.

Use MATE/XFCE instead.https://t.co/2QaJ3jBd2z pic.twitter.com/HIOoGUFEEk

— vermaden (@vermaden) January 21, 2026

Mit lehet eddig tudni róla?

• Ki fejleszti?
  • Mirko Brombin, a Vanilla OS alapítója fejleszti
• Mi a neve?
  • Neve: Singularity DE
• Mire épül?
  • GTK4-re épül
• Egyéb?
  • Cél a memóriatakarékosság
• Letölthető?
  • Jelenleg még nem letölthető, csak a gépén létezik egyelőre
• Állapota?
  • Jelenleg még erősen fejlesztés alatt áll
• Open Source lesz?
  • Nyílt forráskódú lesz
• Ez egy GNOME Shell helyettesítő?
  • Nem GNOME Shell helyettesítő (replacement), egy teljesen más DE
• X11 támogatás?
  • Wayland-only
• Tiling mode?
  • Tiling mód támogatott
• Túl hasonló a GNOME-hoz
  • A GNOME problémája nem az, ahogy működik
• Miért hasonlít az Androidra?
  • Volt némi inspiráló hatása az Androidnak
• Hasonlít kicsit a Budgie desktop-ra
  • Olyasmi

It's not GNOME, it's not KDE, it's not the new Vanilla OS DE, it's new, uses <100M of memory, is accessible (for real) and uses GTK4 (but not libadwaita).

In case the video got ultra-compressed by X, see it in my Mastodon./social account.#Linux #Windows #OpenSource #FOSS pic.twitter.com/wxrYFNAwRo

— Mirko Brombin (@brombinmirko) January 19, 2026

A Spare Cores oldallal arra vállalkoztunk, hogy összegyűjtjük a nagyobb felhőszolgáltatók "compute" kínálatát, begyűjtünk és rendszerezünk róluk minden adatot, benchmarkokat futtatunk a gépeken, majd mindezt strukturált formában elérhetővé és összehasonlíthatóvá tesszük.

Az egyik mért adat a memóriasávszélesség, amelyre eredetileg az lmbench bw_mem programját használtuk, de a nagyobb, mélyebb memóriahierarchiával rendelkező gépek miatt úgy gondoltuk, hogy megpróbálkozunk egy saját implementációval, amely talán jobban támogatja ezeket a gépeket, illetve a mérési környezetünket.

Ennek eredménye lett az sc-membench, amely az alábbiakat tudja:

• Több platform támogatás – x86 és ARM64-on tesztelve (teljes támogatás Linuxon elérhető, de némi effort került abba is, hogy más OS-en is leforduljon :D)
• Több memória-művelet – külön-külön méri az olvasási, írási és másolási sávszélességet, valamint a memória-késleltetést
• OpenMP párhuzamosítás – multithread működés
• NUMA-támogatás – felismeri a NUMA-topológiát, és a memória/CPU kiosztást ahhoz igazítja
• Huge Pages támogatás – a késleltetés mérésénél nagyobb puffereknél jelentős lehet a TLB miss miatti veszteség, így -támogatott környezetben- ezeknél nagyobb lapokat használ a program
• Cache-érzékeny tesztméretek – a mérési méretek dinamikusan igazodnak a gépben lévő L1/L2/L3 cache-méretekhez, így jobban láthatóvá válnak a cache-határok
• Késleltetés-mérés – pointer-chasing technikával méri a késleltetést, amellyel megpróbáljuk kiküszöbölni a prefetch hatásait (valódi random access)
• Statisztikai adatok – medián és szórás a késleltetésmérésekhez
• CSV kimenet – könnyen feldolgozható, géppel olvasható formátum

Kipróbálni a README-ben leírtak szerint lehet, a legegyszerűbb módon konténerben, pld:

docker run --rm --privileged ghcr.io/sparecores/membench:main -H

A weblapon a mérési eredmények grafikus formában is megtekinthetők (jelenleg még a bw_mem mérései alapján, a gépek újbóli mérése még folyamatban van), illetve a keresőben az egyes benchmarkok pontszámaira lehet rendezni a találati listát.