Aktív fórumtémák

Tárgy Válaszok Legutóbbi beküldés Fórum Szerző
  22V váltófeszültség okozhat kellemetlen bizsergést? 39  2025-04-22T11:01:31+0200 Elektronika, Elektromos eszközök kikepzo
  Ubiquiti UACC-LRE furcsaságok és PoE leválasztása 2025-04-22T10:32:43+0200 Hálózati eszközök djtacee
  /MEGOLDVA/ Androidos élelmiszer lejárat figyelő app 49  2025-04-22T10:03:54+0200 Android kikepzo
  "Bill Gates azt mondja, az AI 10 éven belül lecseréli a tanárokat és az orvosokat" 45  2025-04-22T09:52:06+0200 HUP cikkturkáló trey
  Köszi AI, hogy elvetted a munkámat! 59  2025-04-22T09:31:18+0200 Mesterséges Intelligencia: Prolog, Lisp trey
  MBH Bank számla feltörés 225  2025-04-22T09:27:53+0200 Security-all Joejszaka
  Ragozó program 13  2025-04-22T07:18:21+0200 Segédprogramok uzsolt
  Román postától meg (nem) kapott levelek 21  2025-04-21T20:09:53+0200 Web, mail, IRC, IM, hálózatok Luckye
  Fizetések nyilvánossága 56  2025-04-21T17:46:03+0200 HUP cikkturkáló Friczy
  "Súlyosan hibás informatikai rendszert szállítottak a NEAK-nak a NER-es cégek, de még a bűncselekmény gyanúja sincs meg" 142  2025-04-21T16:31:01+0200 HUP cikkturkáló zitev
  Nem megy egyszerre a wifi és a lan [megoldva] 2025-04-21T14:18:39+0200 Red Hat, Fedora, CentOS msandor
  One IPv6 hiba kezelés 40  2025-04-21T14:12:16+0200 Hálózatok általános gerendas
  Shelly Gen 4 70  2025-04-21T13:52:48+0200 Hálózatok egyéb x-daemon
  Angoltanulás 109  2025-04-20T17:43:56+0200 Multimédia ng123
  Internet szolgáltatók vs. Társasház (szerelési mód, minőség) 11  2025-04-19T22:59:57+0200 Hálózatok általános junior013
  óNE - ohNE - one nem működik 2025-04-19T20:33:11+0200 Hálózatok egyéb vfero
  Kompozit video jel előállítása korlátozott TTL alkatrészekből 120  2025-04-18T19:36:41+0200 Elektronika, Elektromos eszközök plt
  Hiteles elektronikus aláírás okostelefon nélkül (2025-) 339  2025-04-18T15:23:13+0200 Security-all hajbazer
  Egy nanométer vastag CPU 46  2025-04-18T15:21:47+0200 HUP cikkturkáló bzt
  Ajánljatok Home Assistant kompatibilis eszközöket 41  2025-04-18T10:05:38+0200 Hálózati eszközök WG

PewDiePie végül Linuxra váltott!

Címkék

Y és Z generációs híreink következnek! PewDiePie - az egyik legnagyobb követőtáborral rendelkező YouTube tartalomkészítő/influencer - az egyik friss videójában felfedte, hogy nemrég Linuxra váltott! Ugyan ez és ehhez hasonló hírek nem vetnek nagy hullámokat az olyan boomer közösségben, mint a HUP, de az újabb generációk által használt platformokon - úgy mint Reddit stb. - igazán nagyot ment a hír ...

Ha mindjárt a releváns részhez ugornál:

Greg Kroah-Hartman kiállt a Rust-ban írt illesztőprogramok mellett

Címkék

A Linux második számú "parancsnoka", Greg Kroah-Hartman szintén nagy támogatója a Rust kernelkódnak. Ma újabb LKML levelet írt, amelyben felvázolja a Rust előnyeit, és arra ösztönöz, hogy az új kernelkódok/illesztőprogramok C helyett Rust nyelven legyenek:

Mivel olyasvalaki vagyok, aki látott szinte MINDEN kernelhiba-javítást és biztonsági problémát az elmúlt 15+ évben (nos, remélhetőleg mindegyik bekerült a stabil ágakba, bár néha kihagyunk néhányat, amikor a karbantartók vagy fejlesztők elfelejtik megjelölni őket hibajavításként), és mint aki látja az összes kiadott kernel CVE-t, úgy gondolom, hogy tudok beszélni erről a témáról.

A legtöbb hiba (mennyiségben, nem minőségben vagy súlyosságban), amivel találkozunk, a C-ben lévő apró, bosszantó, speciális esetek miatt keletkeznek – ezek a Rustban teljesen eltűnnek. Olyan dolgokról van szó, mint az egyszerű memóriafelülírások (nem mintha a Rust mindet képes lenne elkapni), a hibakezelési takarítások, az error értékek ellenőrzésének elmulasztása és a use-after-free hibák. Ezért szeretném, ha a Rust bekerülne a kernelbe, mert ezek a problémák egyszerűen megszűnnek, így a fejlesztők és karbantartók több időt fordíthatnak a VALÓDI hibákra (például logikai hibákra, versenyhelyzetekre stb.).

Teljes mértékben támogatom, hogy a C kódbázisunkat olyan irányba mozdítsuk, amely lehetetlenné teszi ezeknek a problémáknak a felmerülését. Az, amit Kees, Gustavo és mások ezen a téren végeznek, csodálatos és teljesen szükséges munka. 30 millió sor C kódunk van, amely a közeljövőben nem fog eltűnni. Ez egy értékes erőfeszítés, amely nem fog leállni, és nem is szabad, hogy leálljon.

De az új kódok és driverek esetében, ha Rustban írjuk őket, ahol ezek a hibák egyszerűen nem fordulhatnak elő (vagy sokkal ritkábban), az mindenki számára előnyös – miért ne tennénk ezt? A C++ ebből semmit sem ad nekünk a következő évtizedben sem, és a C++ nyelvi bizottság problémái arra utalnak, hogy aki fenntartható kódbázist akar hosszú távon, az jobban teszi, ha minél hamarabb elhagyja ezt a nyelvet.

A Rust lehetőséget ad arra is, hogy az in-kernel API-jainkat úgy definiáljuk, hogy szinte lehetetlen legyen rosszul használni őket. Túl sok bonyolult és trükkös API-nk van, amelyek túl sok karbantartói átvizsgálást igényelnek csak azért, hogy „biztosak lehessünk benne, hogy jól használtad”. Ez részben abból fakad, ahogy az API-jaink az évek során fejlődtek (hány különböző módon lehet egy struct cdev-et biztonságosan használni?), és abból, hogy a C nem teszi lehetővé az API-k olyan formában történő kifejezését, amely biztonságosabbá és könnyebben használhatóvá teszi őket. Az, hogy minket, ezen API-k karbantartóit újragondolásra kényszerít, JÓ dolog, mert ezáltal mindenki számára – már a C felhasználók számára is – tisztábbá és jobbá tesszük őket, így a Linux összességében is jobb lesz.

És igen, a Rust kötései varázslatnak tűnnek számomra egyes helyeken, mivel nagyon kevés Rust-tapasztalatom van, de hajlandó vagyok tanulni és együtt dolgozni azokkal a fejlesztőkkel, akik hajlandóak segíteni ebben. Nem tanulni és nem változtatni az új bizonyítékok alapján (lásd a megjegyzésemet arról, hogy minden kernelhibát elolvasok) egyszerűen ostobaság lenne.

A Rust nem „ezüstgolyó”, amely minden problémánkat megoldja, de rengeteg helyen hatalmas segítség lesz, így ha új dolgokról van szó, miért ne akarnánk ezt?

A Linux egy eszköz, amelyet mindenki más használ a saját problémáinak megoldására, és itt vannak fejlesztők, akik azt mondják: „Hé, a mi problémánk az, hogy olyan kódot akarunk írni a hardverünkhöz, amelyben ezek a hibák automatikusan nem fordulhatnak elő.”

Miért hagynánk ezt figyelmen kívül?

Igen, tisztában vagyok a túlterhelt karbantartói problémával (mivel én is egy vagyok közülük), de itt vannak emberek, akik valóban elvégzik a munkát!

Igen, a kevert nyelvű kódbázisok nehezen kezelhetők és fenntarthatók, de mi kernelfejlesztők vagyunk, az isten szerelmére! Már régóta fenntartjuk és erősítjük a Linuxot, sokkal hosszabban, mint bárki valaha is gondolta volna, hogy lehetséges lesz. A fejlesztési modellünket egy jól működő mérnöki csodává alakítottuk, olyasmivé, amit senki más nem tudott elérni. Egy új nyelv hozzáadása igazán nem kellene, hogy problémát jelentsen – ennél sokkal rosszabb dolgokat is kezeltünk már, és most sem szabad feladnunk, ha a projektünk sikerét akarjuk biztosítani a következő 20+ évre. Amikor új, jó ötletekkel találkozunk, előre kell lépnünk, és támogatnunk kell azokat az embereket, akik ténylegesen elvégzik a munkát annak érdekében, hogy mindannyian együtt sikerrel járjunk.

Köszönettel,

Greg K-H

(A cikk nyomokban Mesterséges Intelligencia által szolgáltatott adatokat tartalmaz, így a tartalmát érdemes duplán ellenőrizni!)

Óraátállítás - mik a preferenciáid?

Címkék

Magyarországon mik a preferenciáid óraállítgatás tekintetében?

Előzmények:

Korábbi kevésbé lefedő szavazás.

Sokszor kemény viták alakulnak ki arról, hogy a téli időszámítást vagy a nyári időszámítást kéne megtartani. De arról ritkán esik szó, hogy aki kardoskodik az egyik mellett, az az állítgatás megtartásának, vagy az általa kevésbé kedvelt időszámításra permanensen átállásnak örülne-e jobban.

Fedjük le az összes preferenciát ezúttal, hogy végre meg tudjuk állapítani, hogy van-e olyan konkrét stratégia, ami határozottan népszerűbb az állítgatásnál.

Egyformán örülnék a téli és a nyári időszámítás megtartásának. A lényeg, hogy eltöröljék az állítgatást
21% (204 szavazat)
A nyári időszámítást kéne megtartani. De a téli időszámítás megtartásának is jobban örülök, mint a további állítgatásnak
15% (149 szavazat)
A téli időszámítást kéne megtartani. De a nyári időszámítás megtartásának is jobban örülök, mint a további állítgatásnak
14% (137 szavazat)
A nyári időszámítást kéne megtartani. De inkább az állítgatás, mint az egész éves téli időszámítás
21% (207 szavazat)
A téli időszámítást kéne megtartani. De inkább az állítgatás, mint az egész éves nyári időszámítás
8% (76 szavazat)
Meg kéne tartani a félévenkénti állítgatást. De ha már azt nem lehet, inkább maradjon a téli időszámítás egész évben
2% (22 szavazat)
Meg kéne tartani a félévenkénti állítgatást. De ha már azt nem lehet, inkább maradjon a nyári időszámítás egész évben
2% (16 szavazat)
Meg kéne tartani a félévenkénti állítgatást. Egyformán rossz ötlet a téli időszámítás és a nyári időszámítás megtartása
7% (72 szavazat)
Teljesen mindegy nekem, hogy állítgatni kell, vagy téli időszámítás lesz egész évben, vagy nyári időszámítás lesz egész évben
9% (92 szavazat)
Összes szavazat: 975

Folytatódik a Rust-dráma az LKML-en, most éppen Christoph Hellwig fakadt ki

Címkék

Hellwig szerint Linus privátban jelezte, hogy beolvasztana Rust kernel kódot az érintett alrendszer karbantartójának kifogásainak ellenére is. Hellwig szerint nincs baja a Rust-tal önmagában, de mint írta, "egy irányítatlan, többnyelvű kódbázis kezelése biztos módja annak, hogy inkább mással töltsem a szabadidőmet" ... :

Duke lesz a Debian 15 kódneve

Címkék
Duke Caboom egy karakter a Toy Story 4-ben. Ő egy kanadai akciófigura, akit a 70-es években készítettek. A figura egy motorkerékpáros sztár, aki híres a merész mutatványairól, de a filmben kiderül, hogy a reklámok által felnagyított kép nem teljesen fedi a valóságot. Duke Caboom hangját Keanu Reeves adja. A karakter egyfajta "nem teljesített ígéret", aki végül segít a többi játéknak a kalandjaik során.

A Debian bejelentette a Trixie tervezett freeze dátumait

Címkék

Márciusban kezdődik a freeze, és egy pár hónapig eltart, lásd lent. Ezen kívül bejelentették, hogy a Debian 15 kódneve Duke lesz.

Hi,

Trying to follow our release cadence, we are going to start freezing
trixie in March. As usual, it is our intention to have a short freeze,
though with the short notice that may be hard. We apologize for not
coordinating this way earlier, and ask everyone to help fix release
critical bugs in order to achieve that.

2025-03-15      - Milestone 1 - Transition and toolchain freeze
2025-04-15      - Milestone 2 - Soft Freeze
2025-05-15      - Milestone 3 - Hard Freeze - for key packages and
                                packages without autopkgtests
To be announced - Milestone 4 - Full Freeze

Újabb karbantartó hagyta el a Linux kernelfejlesztői közösséget

Címkék

Karol Herbst bejelentette, hogy lemond az upstream Nouveau kernelmeghajtó egyik karbantartói szerepéről. Ez néhány nappal azután történt, hogy Hector Martin lemondott az upstream Apple Silicon karbantartói pozíciójáról a kernel fejlesztői közösséggel való nézetkülönbségek miatt.

"Ideje volt már eldöntenem, hogy hivatalosan is bejelentem: nem vagyok többé aktív tagja a kernel közösségnek, sem mint reviewer, sem mint maintainer.

Eddig mindig azzal nyugtattam magam, hogy „ha valami sürgős történik, még mindig be tudok segíteni”. Lyude és Danilo kiváló munkát végeznek, és teljes mértékben megbízom bennük.

Van azonban valami, amit nem tudok elfogadni, és ami a legjobban fáj: meggyőződésem, sőt, alapelvem, hogy az inkluzivitás, a tisztelet és az egyenlő partnerként való együttműködés az egyetlen helyes út a szabad és nyílt forráskódú közösségekben. Nem férnek bele hatalmi játszmák.

Megértem, hogy a maintainereknek tanulniuk kell, hogy technikai kérdésekben lehetnek aggályaik. Mindenkinek jár az idő, hogy megértse a dolgokat és fejlődjön. Hiszek abban, hogy a legtöbb ember képes a változásra, és hogy a közösség belülről is képes jobbá válni. De ez nem egy könnyű folyamat.

A döntésem akkor született meg, amikor egy maintainer a következő szavakat írta a kernel közösségen belül:

„We are the thin blue line.”

Ez nincs rendben. Ez nem egy inkluzív közeg. Ez a mondat a jelenlegi politikai helyzetben, különösen az Egyesült Államokban, egyszerűen vállalhatatlan. Egy maintainer, aki ezt mondja, nem maradhat a helyén. Nem számít, mennyire fontos, kritikus vagy nélkülözhetetlen. Addig nem lehet megtartani, amíg meg nem tanulja, mit jelentenek ezek a szavak rengeteg marginalizált ember számára, milyen borzalmakat idéznek fel bennük.

Nem tudok jó lelkiismerettel egy olyan projekt és közösség tagja maradni, ahol az ilyen kijelentéseket tolerálják. Ezek a szavak nem technikai jellegűek, hanem politikai üzenetet hordoznak. Akkor is, ha nem szándékosan mondják őket, hatással vannak másokra, és ezzel együtt felelősség is jár. Óriási károkat tudnak okozni.

További sok sikert kívánok mindenkinek, aki belülről próbálja jobbá tenni a közösséget. Teljes mértékben támogatom őket, és senkit sem hibáztatok, aki vállalja ezt a hálátlan és kimerítő munkát. Az emberek újra és újra kiégnek ebben.

Én is kiégtem. Sokáig próbáltam gondoskodni azokról a részekről, amelyeket karbantartottam, de végül be kellett látnom a saját korlátaimat. Az elvárás, amit magammal szemben támasztottam, belülről emésztett fel. Egy ponton már nem volt élvezetes, és eljutottam oda, hogy egyszerűen nem tudtam folytatni azt a munkát, amit az elején még teljes lelkesedéssel végeztem.

Kérlek, tartsátok tiszteletben a kérésemet, és ezt a nyilatkozatot változtatás nélkül tegyétek közzé a fában. Ha bármit kihagytok, az teljesen megváltoztatja a jelentését.

Tisztelettel,
Karol
"

Lyude Paul és Danilo Krummrich, mindketten a Red Hat munkatársai, továbbra is a Nouveau kernelmeghajtó karbantartói maradnak.

Részletek itt.

(A cikk nyomokban Mesterséges Intelligencia által szolgáltatott adatokat tartalmaz, így a tartalmát érdemes duplán ellenőrizni!)

Bérezés, trendezés, 50-es lötyögés

Címkék

A friss adásban rugóztunk egyet a 2025-ös informatikai fizetéseken, aztán Dévényi Tibi bácsisat játszottunk az 50. kraftie alkalmából.

Kijött a Hays Salary Guide 2025, így átfutottuk mi változott, mi nem változott, mit fognak a hazai szakemberek elhinni vagy éppen nem elhinni a legnépszerűbb hazai bérmankó adataiból. Átfutottunk pár friss trendet is, aztán a jubileumi adás alkalmából megnéztük hány évesek vagytok, mit gondoltok rólunk, milyen kívánságaitok vannak. Sőt, még a kraftie nyunyó is feltűnik a YouTube verzióban.

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.

Folytatódik az Asahi Linux dráma: Hector Martin lemondott

Címkék

Előzmények:

Hector Martin, az "Apple Siliconra Linuxot", azaz az Asahi Linux projekt vezetője és elindítója váratlanul lemondott. A projekt tagjai maradtak: Alyssa Rosenzweig, chaos_princess, Davide Cavalca, Neal Gompa, James Calligeros, Janne Grunau és Sven Peter.

Részletek itt.

A Google Calendar eltávolította az olyan eseményeket, mint a Pride és a BHM, mert az ünneplistájuk fenntarthatatlan

Címkék

Valami oknál fogva a Google most jött rá, hogy az eddig általuk karbantartott és a Google Calendar-ban szerepeltetett egyik ünneplista karbantartása már oly mértékű tehet ró rájuk, hogy az emiatt fenntarthatatlan. Ezért az olyan ünnepeket mint a Pride Hónap, Fekete Történelem Hónapja stb. - ezentúl nem lehet majd követni a Google Calendar-ban:

Egyes Google Naptár-felhasználók dühösen bírálják a vállalatot, miután észrevették, hogy bizonyos események, például a Pride hónap, már nem jelennek meg alapértelmezés szerint. Egy Google-termékszakértő szerint a Black History Month, az Őslakosok Hónapja, a Zsidó Örökség, a Holokauszt Emléknap és a Spanyolajkú Örökség Hónapja szintén eltávolításra került.

Egy felhasználó „szégyenteljesnek” nevezte a lépést, és azt mondta, hogy a platformot arra használják, hogy „megadja magát a fasizmusnak.” Az elmúlt években több komment és médiajelentés is panaszkodott ezeknek a bejegyzéseknek a jelenlétére, de mostanra eltűntek.

A Google megerősítette, hogy változtatásokat hajtott végre az alapértelmezett Naptár-eseményeken, de eltérő magyarázatot adott arra, hogy mikor és miért történt ez. Íme a vállalat hivatalos magyarázata Madison Cushman Veld szóvivőtől:

Több mint egy évtizeden át együttműködtünk a timeanddate.com-mal, hogy a Google Naptárban megjelenítsük az állami ünnepeket és nemzeti megemlékezéseket. Néhány évvel ezelőtt a Naptár csapata manuálisan kezdett hozzáadni egy szélesebb körű kulturális eseménylistát számos országban világszerte. Visszajelzéseket kaptunk arról, hogy egyes események és országok kimaradtak – és több száz esemény manuális, következetes globális kezelése nem volt skálázható vagy fenntartható. [...]

Részletek itt.

Kubernetes LTS - 12 évnyi támogatást jelentett be az Ubuntu a Kubernetes 1.32-től kezdve

Címkék

Az Ubuntu bejelentette Kubernetes LTS kezdeményezését, aminek keretében 12 évnyi biztonsági karbantartási támogatást és enterprise supportot kínál a Kubernetes csomagjaihoz és a kapcsolódó ökoszisztéma konténer image-ekhez. A támogatás a Kubernetes 1.32-től kezdve indul és bare metal-on, public cloud-ok, OpenStack-en, Canonical MicroCloud-on és VMware-en értelmezhető.

Részletek bejelentésben.

Aktívan kihasznált 0day sérülékenységet javít az Apple soron kívül kiadott iPhone/iPad frissítése

Címkék
A physical attack may disable USB Restricted Mode on a locked device. Apple is aware of a report that this issue may have been exploited in an extremely sophisticated attack against specific targeted individuals.

CVE-2025-24200: Bill Marczak of The Citizen Lab at The University of Toronto’s Munk School

[...]

A hibát felfedező Bill Marczak arra figyelmeztet, hogy érdemes mielőbb frissíteni az iPhone készülékeket az Apple soron kívül kiadott OTA frissítésével, ami befoltozza azt a 0day sebezhetőséget, amelyet a vállalat szerint célzott és "rendkívül kifinomult" támadások során használtak ki.

Linkek:

Az Apple Watch viselése a bokán? Egy új jelentés magyarázza a trendet.

Címkék
  • A kis csuklóval rendelkező emberek úgy találják, hogy az Apple Watch túl laza, és nem tudja megfelelően érzékelni a pulzust.
  • Egyesek, akik csukló tetoválással rendelkeznek, úgy vélik, hogy a tinta zavarhatja a pulzusmérő érzékelést, amit az Apple is elismer egy támogatói dokumentumban. Az Apple szerint bizonyos tetoválások "blokkolhatják a fényt" a hátoldali pulzusmérő szenzor számára, így "nehéz megbízható adatokat kapni".
  • Vannak, akik szerint az Apple Watch pontosabban mérheti a lépéseket, ha a bokán viselik, nem pedig a csuklón.
  • Egyesek bőrfelületi problémák miatt inkább a bokájukra helyezik az Apple Watch-t.
  • Néhány orvosi szakember nem viselhet semmit a csuklóján, így nekik is alternatívát jelenthet a bokán való viselés.
Részletek itt.

Új trend az okostelefon-gyártóknál: minél vékonyabbat

Megfigyelhető, hogy az okostelefon-gyártók rendre bizonyos trendek mentén haladnak, egymásra ráígérve. Az okostelefonok piacának formálóit mostanában a vékonyság érdekli. Az OPPO a napokban mutatta be extravékony - állítólag mindössze 4 mm vastag - összehajtható telefonját, de a hírek szerint az Apple is készül az iPhone 17 Air-rel, ami a legvékonyabb pontján mindössze 5.5mm "vastag" lesz.

👍‍
15% (52 szavazat)
👎
58% (199 szavazat)
🤷‍♂️
27% (94 szavazat)
Összes szavazat: 345

Új Apple Silicon társkarbantartó lépett elő a Linux kernel fejlesztői közösségében

Címkék

Ha valaki azt tervezte, hogy megszaggatja ruháit és hamut szór a fejére, ne tegye! Ugyan Hector Martin nemrég bejelentette, hogy lemond a mainline Linux kernel Apple Silicon-ért felelős kódjainak karbantartói pozíciójáról, de máris egy két fős csapat lépett a helyére. Az eddigi társkarbantartó Sven Peter mellé jelentkezett munkára Janne Grunau is, így most párban tartják karban a karbantartani valót. Janne Grunau egy meglévő Asahi Linux / Apple Silicon közreműködő, aki tavaly április óta dolgozik a downstream Asahi kernelfán, valamint több illesztőprogramon is. Janne Grunau Sven Peter és Hector Martin támogatását is élvezi.

Részletek itt.

OSX-Proxmox - script, ami macOS-t telepít Proxmox-ra

Címkék

Nagy hörgést okozott a "ki akar Linuxot futtatni Mac-en" cikk, így ismertek, jöjjön akkor a fordítottja: futtassatok macOS-t bármely Intel/AMD gépen a Proxmox segítségével! Ehhez nyújt segítséget az OSX-Proxmox script, ami fellapátolja az Appel operációs rendszerét Proxmox virtuális környezetbe.

"De minek??!?!!!!!!"

🍿 😉

Támogatott verziók:

Lemondott az Asahi Linux vezető fejlesztője a Linux kernel "Apple Silicon" karbantartói pozíciójáról

Címkék

A Linux kernel levelezőlistáján az elmúlt néhány napban folytatott viták nyomán, amelyekben néhány Linux kernel karbantartó ellenezte a Rust kód használatát a fő ágban, és próbálta azt elkerülni, valamint nagyon szenvedélyes vélemények hangzottak el a Linux kernel fejlesztési folyamata kapcsán, az Asahi Linux vezető fejlesztője, Hector Martin eltávolította magát az ARM Apple kódjának upstream karbantartói szerepéből.

[...]
Már nincs bennem semmi bizalom a kernel fejlesztési folyamatában vagy a közösségi menedzsment megközelítésében.

Az Apple/ARM platform fejlesztése továbbra is lefelé, azaz a downstream-ben folytatódik. Ha úgy érzem, hogy a jövőben bárminemű alrendszerhez szeretnék upstream változtatásokat küldeni, megtehetem, de lehet, hogy nem fogom. Bárki, aki úgy érzi, hogy szeretne részt venni az upstream küzdelemben, nyugodtan megteheti.

[...]

Linus a döntést tudomásul vette a patch beolvasztásával.

Részletek itt.

LibreOffice 25.2

Új major kiadással jelentkezett a szabad szoftveres, multiplatformos (Windows (Intel, AMD és ARM), macOS (Apple Silicon és Intel) és Linux) irodai programcsomag, a LibreOffice projekt.

Bejelentés itt.