- A hozzászóláshoz be kell jelentkezni
- 3103 megtekintés
Hozzászólások
A szokásos rusztafári ömlengés és bullshitelés mindenféle konkrétum nélkül.
amivel találkozunk, a C-ben lévő apró, bosszantó, speciális esetek miatt keletkeznek – ezek a Rustban teljesen eltűnnek.
Dehogy tűnnek el. Ez konkrétan bullshit, amit konkrét példák milliói cáfolnak.
ha Rustban írjuk őket, ahol ezek a hibák egyszerűen nem fordulhatnak elő (vagy sokkal ritkábban)
Dehogynem fordulnak elő. Arról nem is beszélve, hogy a kernel legtipikusabb memóriastruktúrái (láncolt listák és gráfok) a borrow checker miatt eleve MEG SEM VALÓSÍTHATÓak Rust-ban, szóval az egész kernelt át kéne írni hozzá.
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.
Hazugság. Mivel C-vel is illeszteni kell, ezért unsafe nélkül nem is lehetséges. Ráadásul az FFI további biztonsági problémákat okoz.
És igen, a Rust kötései varázslatnak tűnnek számomra egyes helyeken, mivel nagyon kevés Rust-tapasztalatom van
Na tessék, saját maga ismeri be, hogy NEM IS ÉRT HOZZÁ, úgy próbálja meg osztani itt az észt.
Hogy én mennyire ki nem állhatom az ilyen álszakértő faszkalapokat, rengeteg kárt okoznak az IT-ban! Én inkább hallgatnék a megbecsült, nagy múltú C kernel fejlesztőkre, semmint egy olyanra, aki nem is ért a Rust-hoz!
- A hozzászóláshoz be kell jelentkezni
"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."
A linkelt "ellenpélda" egy másik hibáról, a memory leak-ről szól.
Bár nem szeretem a Rust-ot, de azért ismerjük el, hogy a borrow-checker sok egyszerű alap hibát kiküszöböl.
- A hozzászóláshoz be kell jelentkezni
A linkelt "ellenpélda" egy másik hibáról, a memory leak-ről szól.
Nem igaz. Van ott szó bőven memory vulnerability-ről is! De egy pár perces kereseséssel te is bőven találsz ellenpéldákat, konkrét esettanulmányokkal. Nem nehéz, mert baromi sok van. Nyilván memleak-es ellenpélda is akad bőven, de memory vulnaribility ellen sem ér fabatkát sem.
Bár nem szeretem a Rust-ot, de azért ismerjük el, hogy a borrow-checker sok egyszerű alap hibát kiküszöböl.
...és egy csomó, a kernel által jelenleg használt struktúrát meg lehetetlenné tesz! Ha nulláról indulnának, az egy dolog lenne, de itt már meglévő C kódhoz való illesztésről van szó, ami ég és föld. Ez utóbbi unsafe nélkül lehetetlen, így az összes fennen hangoztatott Rust "előny" megy élből a kukába!
- A hozzászóláshoz be kell jelentkezni
Tényleg nem értem, hogy a Rust-afárik miért nem írják meg nulláról a kernelt.
Ha ennyire egyszerű™ és hatékony™ ez a nyelv, elvileg kevesebb idő alatt újraírnák benne a kernelt, mint amennyi ideje a Red Hat a Waylandot gányolgatja (úgy 16 éve). Tök jó lenne, ha az ilyen szélsőséges indealizmusok, trendbuziskodások nem a Linuxot basznák szét, forgatnák fel, hanem legalább elkülönülnének. Mivel ezt a szutykot is leginkább a multik nyomják meg hátszéllel (Microsoft, Google, Amazon), csinálhatnának is egy OS-t, amit csak és kizárólag Rust-ban írnak. Nem, azt nem. Inkább felforgatjuk a Linux-világot, hogy az ingyenfejlesztőknek ne legyen más választásuk, mint a mi idealizmusaink szerint fejleszteni.
- A hozzászóláshoz be kell jelentkezni
Van. Redox OS-nek hívják: https://redox-os.org/
Csak - ahogy azt sejteni lehet - kevés hardverhez van driver benne (https://gitlab.redox-os.org/redox-os/drivers/-/tree/master).
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
Át kell csoportosítani a Linux-ot szétgányolni akaró humán erőforrásokat, és lesznek driverek.
- A hozzászóláshoz be kell jelentkezni
Történetesen - főleg az emberi aspektusai miatt - hajlok rá hogy ez lett volna jobb választás.
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
Nyilván. Már többször mondtam, hogy itt most a Linux kernel szándékos szétbarmolásának vagyunk a szemtanúi. Nagy multi felvásárolta a konkurenciát és elsorvasztja alkalmazza Linus-t, majd letol a torkán mindenfélét.
- A hozzászóláshoz be kell jelentkezni
Szerintem nem szándékos szétbarmolás folyik.
Onnantól, hogy beszáll a tőke, az elvek helyett az igények kerülnek előtérbe. Ha nem tetszik, lehet menni BSD-zni. Aztán nézni, mire megy a community lóvé nélkül az elveivel, 30 év alatt.
- A hozzászóláshoz be kell jelentkezni
De tényleg mit erőlködnek a Linux kernelben?
Ha annyira fasza a Rust, akkor írjanak egy saját kernelt/oprendszert és mutassák meg, hogy miben jobb, mint a jelenlegi. Senkinek nincs szüksége sem a felhajtásra, amit ezzel a szituációval generálnak, meg a plussz körökre, amit a Rust bevezetése miatt meg kell futni.
Szerinted akik idáig csinálták és teljesen jól megvannak a jelenlegi környezetükben, most azok menjenek BSD-zni, mert a kékhajú (újfiúk | lányok | delfinek | *) beleszartak a homokozóba?
A Redox kernel ki tudja váltani egy az egyben a Linux kernelt? Nem. Akkor hajrá! Lehet azt reszelgetni.
szerk.: nem a Rust-ot utálom. Anno tetszett nekem is, neki is álltam, hogy megtanuljam.
- A hozzászóláshoz be kell jelentkezni
Szerintük a Rust egy jó és hasznos dolog a Linux kernelben, és nem egy másik OS-t akarnak írni.
Aki másikat akart írni, az más OS-t ír. Sokan egyetértenek velük, mások nem, megint mások elvben igen, de másképp csinálnák.
Ebből (egyébként hasznos) viták alakulnak ki, amiket valamilyen formában fel kell oldani, és ami nem mindig egyszerű dolog, ennek a folyamatát látjuk most.
- A hozzászóláshoz be kell jelentkezni
Már megbocsáss, de ez nem professzionális hozzáállás, hanem hiszti.
Nem a Rust-osok jönnek, és főleg nem a kékhajúak miatt történik mindez.
Olyan, mintha egy gödör aljáról szemlélnéd a világot.
Nem akar senki új OS-t csinálni, ez az egész nem a Rust-ról szól. Hanem a Linux kernel jövőjéről.
Vannak olyan igények az ipar oldaláról, amiket a jelenlegi fejlesztési folyamat nem tudott megugrani. Hozzáteszem, ez nem csak a Linux kernelre igaz.
Ezeknek a problémáknak egy részére kapóra jön, amit a Rust ígér. Hogy beválik-e, azt nem lehet előre teljes bizonyossággal megmondani. Ellenben az egyre nyilvánvalóbb, hogy a jelenlegi toolchain és folyamat nem fog ezekre a problémákra megoldást hozni.
El kell tudni fogadni, hogy változnak a dolgok.
A Linux mára egy ipari OS lett. Ha kemény vonalas communityzés kell, szerencsére még mindig ott van a BSD.
- A hozzászóláshoz be kell jelentkezni
Hiszti?
Ebben a sztoriban ki hisztizik?
Olyan, mintha egy gödör aljáról szemlélnéd a világot.
Olyan, mintha magas lóról beszélnél. Ahogy a peronos hasonlatodban, amit tán kétszer is elsütöttél!
De ha már a vonatozásnál tartunk: szerintem a kernel fejlesztőknek teljesen megfelel a szokásos fél nyolcas, menetrend szerinti gyorsvonat. Nem akarnak felszállni a hájpvonatra, ami lehet a következő kanyarban kisiklik.
...a Rust igér...
Nekünk bizonyíték kell! Nem ígéret! Ahogy az oldszpájsz reklámban is megénekelték...
Ha kemény vonalas communityzés kell, szerencsére még mindig ott van a BSD.
Ennek így kicsit másabb a csengése. Az előző említéskor mintha azt sugalltad volna, hogy amelyik fejlesztőnek/karbantartónak nem tetszik a Rust a Linux kernelben, az mehet a BSD-hez. Hogy is van ez? A vendég kidobja a házigazdát? Vagy mit akart kifejezni?
- A hozzászóláshoz be kell jelentkezni
Onnantól, hogy beszáll a tőke, az elvek helyett az igények kerülnek előtérbe.
Igények vannak ott is, ahol tőke nincs. Nem az igényekkel van baj, hanem azzal, hogy a tőke bejövetele olyan arrogáns, invazív elemek megjelenésével jár, mint Lenart Pöttering és olyan szélsőséges idealizmusaik erőltetésével, mint a systemd vagy a pulseaudio.
Aztán nézni, mire megy a community lóvé nélkül az elveivel, 30 év alatt.
Linux-szal összemérhető mértékben használható, áttekinthető, rendezett, konzisztens rendszer. Erre megy mondjuk egy FreeBSD.
A tőke korlátlan beengedése az ilyen projektekbe pedig rohadtul nem egészséges azokra nézve, mert előbb-utóbb felfalja őket. Ahogy a Red Hat tette a desktop Linux-szal. Ez igazából az a kihívás, amit a GNU nem volt képes orvosolni a licenszeivel. Felszabadította a fél világot a proprietary szoftverek egyeduralma alól, de nem számolt azzal, hogy a tőkeerős multik immáron nem a kódot fogják önzőn, mohón szorongatni, hanem kisgömbőcként falják fel a nyílt forráskódú projekteket.
- A hozzászóláshoz be kell jelentkezni
Szerintem hosszú távon jobban járunk, ha megoldják azt, hogy hogyan legyen kétnyelvű (C & Rust) a Linux. Nem lesz egyszerű, lesznek akik emiatt abbahagyják a fejlesztését, de mások meg pont emiatt fogják elkezdeni. Korábban is voltak nagy drámák (CK kernelek, processzütemezők, PaX / grsecurity), amik jól - rosszul lettek kezelve. Ettől még a Linux köszöni szépen jól van.
- A hozzászóláshoz be kell jelentkezni
Ez egy nehéz dilemma. Hosszú távon szerintem is egyértelmű az előny, de addig a rövidtávon kell átvergődni valahogy. Ráadásul úgy, hogy igazából nem látod, nincs mérhető metrikád rá, hogy mi az amit még "kibír" a projekt. Rohadtul nem szívesen lennék ilyen döntéshozó pozícióban.
Ami szintén necces dolog, hogy a jövőben a céges kontribuciók csökkenő mennyiségére lehet számítani. Olyan cégek, mint az Intel, amik eddig nagyon sok kernelfejlesztőt fizettek, most éppen eléggé bukóágon vannak. Pillanatnyilag pont olyan cégeknek áll a világ, mint a Broadcom meg az Nvidia, amik hírhedtek voltak az open-source ellenes hozzáállásukról. Amazon - van saját from-scratch fejlesztett hypervisor-uk, kb annyira érdekli őket a Linux, hogy fusson AWS-en. Microsoft, dettó ugyanez Azure-rel. Apple - teljesen saját OS-ük van, leginkább abban érdekeltek, hogy minél kevésbé legyenek interoperábilisek bármivel a saját ökoszisztémájukon kívül. Google - hát amit a W3C-ben művelnek, az alapján talán jobb ha nem fejlesztenek a kernelbe...
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
Én azt gondolom (remélem :) ), hogy Linus ezeket átgondolta ... :)
Szerintem minden hardvergyártó cég főleg olyan dolgokon dolgozik, a kernelnél is, amitől azt reméli, hogy több HW-t fog tudni eladni. A Qualcomm pl. pont azért, mert ők most az "ARM világ AMD-je" (és nyilván ez az analógia sántít, mert ugye itt bőven nem 2 szereplős a piac, hanem ott van az Apple, Nvidia mellett a Samsung, Broadcom + a kínai gyártók :) ) végre elkezdte az X Elite chipsetek mainline Linux supportját csinálni, nem csak az Androidos kernelt adják ki rá.
A Google W3C ténykedését nem követtem, ha arra gondolsz, hogy mostanra a W3C = amit a Chrome tud, akkor ez szerintem nem (csak) a Google hibája, hanem kb. mindenki másé is, beleértve "minket" = az egész fejlesztői közösséget, akiket kb. nem érdekelt, hogy mi folyik a W3C-ben. Ezzel együtt a Wasm szerintem relatíve jól sikerült mostanra, bár a GC nem lett egy sikertörténet, pont Varga Zoltán (korábban Mono / Xamarin, most MS .NET VM fejlesztő) írta meg nekik Githubon, hogy amíg nem csinálják meg rendesen, addig a .NET nem fogja tudni használni. Ennek lassan 5 éve ...
Ami szerintem viszont nagyon félrement, az a WebGPU. Amikor kiderült, hogy az Apple nem megy bele, hogy SPIR-V legyen a shader formátum, akkor kellett volna beszántani az egészet, és megcsinálni a WebVulkan - WebMetal speceket, amiknek volt is PoC implementációjuk. Ez egy nagyon vékony wrapper lett volna a "rendes" Vulkan / Metal felett, néhány korlátozással, de nem kellett volna teljesen új renderer backendet írni hozzá mindenkinek, amit még a browsergyártóknak vissza kell konvertálniuk Vulkanra / Metalra, hogy biztos lassú legyen. Aki ebben a világban dolgozik, már úgyis megcsinálta a Vulkan és Metal rendererét, az a 3 ember, aki meg most kezdte volna, az megírja a Vulkant, és Metalhoz meg használja a MoltenVK-t.
Visszatérve a Google vs kernel témára: szerintem az Android kernellel elég korrekt munkát végeznek (amit persze a gyártók általában szétgányolnak, de aktívan próbálják őket terelgetni a közös kernel irányába). Pl. megcsinálták a stabil Linux kernel modul API-t az Android kernelekben, amit itt a HUP-on ~20 éve hiányoltak a Linuxból a Solaris fanok.
- A hozzászóláshoz be kell jelentkezni
Igen ahogy sejted, elsősorban pont arra gondolok, hogy ha a Google ugyanúgy egyedül marad nehézsúlyú szereplőként, mint a W3C-nél, akkor pontosan W3C == Chrome eset fog megismétlődni, csak ezúttal Linux == Android formában. Szerintem abból a szempontból cikis leginkább, hogy a webes api-kat telefosták olyan feature-ökkel, amik security és főként privacy szempontból katasztrofálisak, aztán - mikor már boldog-boldogtalan visszaél vele - eső után köpönyeg jelleggel kell agyalni rajta, hogy lehetne valahogy valami kontrollt visszaadni a felhasználó kezébe. Főleg a mikrofon-kamera-webrtc környékén ment ez, de kb minden alkalommal megismétlődött a menetrend. Abban biztos vagyok, hogyha többszereplős a játék, akkor legalább ki van kényszerítve egy diskurzus - még a feature szabványba felvétele előtt - hogy ezzel potenciálisan hogy lehet visszaélni és hogy kéne ezt megelőzni.
A stabil kernel driver API ugyanúgy egy elég problémás dilemma volt anno, mert benne van a pakliban, hogy beleragad a kernel egy állapotba és onnan nem lehet változtatni. Szerintem az elmúlt 20 év azt igazolja, hogy az volt a helyes irány, hogy nem csináltak ilyet. Ha a kernel dominánsan a Google kezébe kerül, akkor szinte biztos átnyomja ezt is, ami hosszú távon többet is árthat, mintha csak a "C" nyelv maradna fixen.
Amúgy teljesen off jelleggel, érdekes amit mondasz a WASM-ről. Nem követtem ezt a részét, most kezdtem utánaolvasni, nem volt meg, hogy ennyire gáz a helyzet.
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
Igen, ezt mondtam én is. Írják meg a rust-osok a saját kernelüket a 0-ról. Nem kicseszésképpen, vagy szarkazmusból mondva, hanem ha tényleg az alapoktól felépítik saját maguk, a saját fejlesztési metodikájukra, és a Rust képességeire alapozva, akkor nem lesznek kötve egy C-s projekt korlátaihoz, nem lesz kivel súrlódjanak. Ez nekik is tényleg jó lenne, egy jó alkalom, hogy megmutassák mit tudnak, ha nem gáncsolja őket senki.
Azt meg ne higgye ám senki, hogy képzett fejlesztőnek unixlike kernelt írni annyira nehéz, van rá már egy csomó opensource példa, az eredeti-kiadott unixos és BSD-s kódoktól kezdve a Linuxon át, a Redox OS-ig, GNU Hurd-ig (igen, ez egy vicc, de működik, kódot lehet belőle nyúlkálni). Tehát nem kell saját kútfőből nekimenni, vannak rá dokumentált rendszerhívások, megírt példakódok, sőt, az AI is itt jöhet be, hogy API-kból gyorsan tud boilerplate kódot gyártani. Az AI hülye, megbízhatatlan, de ilyen sablonfeladatban segíthet, megmenthet egy csomó gépeléstől, stb..
Nem is kis munka, azt nem mondom, de nem is egyfejlesztős projektként indulna, ahogy anno Torvlads egy floppy-s egyetemista projektje. A rust-osoknak lépéselőnye lenne, jobb fejlesztői gépek, jobb IDE-k, virtualizáció, több tesztelési lehetőség, mindjárt több fejlesztő megy neki, nagy multik szponzorálják.
Igazából még nekünk begyöpösödött linuxosoknak is jó lenne, mert ha pl. a Linuxszal történik valami, akkor nem csak a BSD-k lesznek ott, meg az Illumos alapú cuccok, hanem lenne még egy alternatív FOSS platform, akár szeretjük a Rust-ot, akár nem, akkor is plusz alternatíva. Ezen rendszerek között úgyis van átjárás, mert ugye a unixos szabványok (POSIX, SUS, libc, stb.) garantálnak valamilyen mértékű átjárhatóságot, még ha adott esetben van is némi különbség a rendszerek között, pl. más initrendszer, más csomagkezelő, más virtualizáció, más konténerizáció, eltérő alapokon nyugvó (nem X11 alapú) felület.
Igazából egy tisztán Rust-os unixlike OS-re már van kész egy csomó Rust-kód, átportolták a GNU coreutils-t is már, uutils a neve, meg van egy csomó újraírt klónutasítás (bat, fd, ripgrep, stb.). Redox OS-ből is lehet egy csomót nyúlni. Van már pár kész Linux kernel driver is Rust-ban, jó, azokat át kell írni, de akkor se 0-ról indulás.
Szerk.: jó párhuzam erre a Google Chrome. Annak idején is úgy tartották, hogy böngészőt nehéz írni, túl sok munka, túl sok optimalizáció, nem éri meg senkinek. Aztán jött a Google, és a semmiből, 2009-ben előállt a Chrome-mal, ami mindjárt kezdetben is gyorsan sikeres lett, 10 év múlva meg egyeduralkodó, 10 millió kódsorossá hízott már akkor, pedig nem is dolgozott rajta annyi fejlesztő, mint a kernelen. Még 6 évre rá, mára meg 45 millió kódsoros már, veri a kernelt is. Az is igaz, hogy a Google milliárdokat ölt bele, de akkor is szépen mutatja, hogy nem kell hozzá 35 év, hogy utolérjék a Linux kernelt.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
- A hozzászóláshoz be kell jelentkezni
Neked nem teljesen mindegy miben írják?
Már megint összetéveszted a lehetőséget a kötelezettséggel.
- A hozzászóláshoz be kell jelentkezni
Egyelőre lehet, hogy unsafe-fel indul a buli, de ez változni fog.
Az nem érv, hogy valamire van ellenpélda. A világon mindenre van ellenpélda.
Valójában teljesen mindegy, hogy mi itt mit gondolunk. Nem a mi - többé vagy kevésbé szakmai - érveinken fog ez eldőlni. Engem különösen zavar, hogy sokan érvelnek érzelmi, mintsem tudományos alapon.
- A hozzászóláshoz be kell jelentkezni
Én inkább hallgatnék a megbecsült, nagy múltú C kernel fejlesztőkre, semmint egy olyanra, aki nem is ért a Rust-hoz!
Greg Kroah-Hartman:
As of April 2013, he is the Linux kernel maintainer for the -stable branch,[2] the staging subsystem,[2] USB,[2] driver core, debugfs, kref, kobject, and the sysfs kernel subsystems,[2] Userspace I/O (with Hans J. Koch),[2] and TTY layer.
Kik lennének a „megbecsült, nagy múltú C kernel fejlesztők”?
- A hozzászóláshoz be kell jelentkezni
És én még azt hittem, annál nem lehet jobb, mint amikor paxot próbálta osztani exploit ügyben :D :D :D :D
- A hozzászóláshoz be kell jelentkezni
linket plz
- A hozzászóláshoz be kell jelentkezni
valamelyik korábbiban linkelte valaki. Akkor ugyan más néven volt jelen a kolléga, de elég egyértelmű volt. Megpróbálom majd előszedni.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
:D zseniális, köszönöm
- A hozzászóláshoz be kell jelentkezni
Linus?
- A hozzászóláshoz be kell jelentkezni
Az már rég csak egy manager, fingja nincs semmiről, és egyébként is becsicskult a woke izé tanfolyamon...
- A hozzászóláshoz be kell jelentkezni
Vélemény olyan mint a fing, mindenkinek van, csak kellemetlen ha mindenki mások orra alá tolja.
- A hozzászóláshoz be kell jelentkezni
Iróniadetektor elromlott?
- A hozzászóláshoz be kell jelentkezni
Kedves therion, bedőltél a parasztvakításnak. Ez a Greg hosszasan sorolja és öntömjénezi magát, hogy ért az A-hoz, majd pedig véleményt mond B-ről. Te meg simán, gondolkodás nélkül bedőltél ennek az átlátszó olcsó szemfényvesztésnek. Erről ennyit.
Kiemelem MÉGEGYSZER: Greg Kroah-Hartman:
nagyon kevés Rust-tapasztalatom van
Ezt saját maga ismerte be, persze csak a végén, mert azt már úgysem olvassák el egyesek!
Kik lennének a „megbecsült, nagy múltú C kernel fejlesztők”?
Azok, akik marketing bullshit helyett szakmai érvekkel állnak elő. Greg részéről NULLA szakmai érv hangzott el, csak a szokásos rusztafári mantrákat tolja, amik egyébként konkrét hazugságok, erről bárki meggyőződhet egy pár perces webes kereséssel.
- A hozzászóláshoz be kell jelentkezni
Kiemelem MÉGEGYSZER: Greg Kroah-Hartman: nagyon kevés Rust-tapasztalatom van
Ezt saját maga ismerte be, persze csak a végén, mert azt már úgysem olvassák el egyesek!
Ilyeneket szerénységből szoktak írni. Van rá egy 6pack-em, hogy sokan örülnének annak a kevés Rust-tapasztalatnak...
- A hozzászóláshoz be kell jelentkezni
+1, tavaly jött egy contractor a csapatunkba, bemutatkozáskor azt mondta, hogy "somewhat experienced in Azure". Kiderült, hogy amikor 2010 februrár 1-én kijött az Azure, ő másnap regisztrált, és azóta nyomja.
- A hozzászóláshoz be kell jelentkezni
"Hogy én mennyire ki nem állhatom az ilyen álszakértő faszkalapokat, rengeteg kárt okoznak az IT-ban!"
El sem tudod képzelni, hogy ez mennyire találó mondat volt részedről... :)
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
Igen, ez a Greg nem tud rust-ul, bár ez az én szememben még erény is. Nem is állította sehol, hogy szakértője a témának, bár tény, hogy nem kéne védenie.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
- A hozzászóláshoz be kell jelentkezni
Mivel felelős/döntési pozícióban van a témát illetően, így inkább meg se kellett volna szólalnia.
- A hozzászóláshoz be kell jelentkezni
Ezt inkább pszichológiai, politikai fogásnak szánta, mivel ő a második legnagyobb vezető a kernelben, azt hitte, hogy ha a rust-osok mellé áll, akkor sikerül lenyugtatnia a kedélyeket, és látják rajta, hogy nem minden fő C-s fejlesztő gecizik. Tény, hogy ha nem ért hozzá, akkor nem kellett volna szakmai részletekbe mennie vele, elég lett volna csak annyit mondania, hogy nincs ellene a Rust-nak, és ő a részéről mindent megtesz, hogy együtt tudjanak dolgozni a rust-osokkal.
Egyébként a Rust-nak én se lennék ellene, én a hájpnak vagyok nagy ellenzője. Sajnos több évtizede nyomom már a PC, meg hobbi programozós mókát, tanultam már mindenfélét, a legtöbb cucc, ahogy lement körülötte a hájp, szépen elavult tudás lett, ment pocsékba, felesleges erőlködésnek bizonyult. Ezért én 10× is meggondolnám, hogy Rust-ot tanuljak-e. Anno a Java-ról, PHP-ről, Ruby-ról, Go-ról, meg mindenféléről úgy gondolták, hogy a világot megváltja, aztán csak nem úgy lett. Közben meg C, unixos dolgok, vi/vim, stb. örök maradt, átálltam inkább az ilyenekre az évek folyamán, nincs nekem erőm, hogy mindenki hülye hájpjának szaladgáljak utána.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
- A hozzászóláshoz be kell jelentkezni
Egyébként a Rust-nak én se lennék ellene, én a hájpnak vagyok nagy ellenzője.
Egy dolgon gondolkodj el: Kellene neki ekkora hype, ha tényleg annyival jobb lenne a C-nél, mint amennyire hype-olják? Onnan lehet megismerni a legjobban a kamuinnovációt és a szemfényvesztést, hogy túltolják a hype vonalat és majdhogynem már vallást csinálnak belőle. Mindezzel azt kompenzálják, hogy a Rust távolról sem tud minden szempontból jobb lenni a C-nél. Így manipulációval, a tudatok megerőszakolásával akarják elterjleszteni, mert ezzel néhány milliárdos multi valamennyit spórol™.
- A hozzászóláshoz be kell jelentkezni
Honnan tudod, hogy IT influenszer bullshitet olvastál? Onnan, hogy a szöveg önmagának is ellentmond.
"nem fordulhatnak elő (vagy sokkal ritkábban)"
Tehát előfordulhatnak.
"szinte lehetetlen"
Ami szinte lehetetlen, az nem lehetetlen, tehát lehetséges.
Én inkább hallgatnék a megbecsült, nagy múltú C kernel fejlesztőkre, semmint egy olyanra, aki nem is ért a Rust-hoz!
Hamarosan eljutunk oda, hogy a C-ben kódoló kernel-fejlesztőket nyilvánosan megalázzák, laggardoknak, dinoszauruszoknak állítják be az ottani Raynes-ek, dorsykák és Zeller Mérnök Urak, valamint "bezzeg, ha Rust-ban írtad volna" alapon teszik őket felelőssé a hibákért, miközben a Rust-ban elkövetett gányolások felett természetesen szemet húnynak és mélyen kussolnak.
Különszám, hogy egy lapon említi a fenntarthatóságot és a Rust-ot. Vajon állandó netkapcsolatot igénylő cargo-t látott már közelről? Esetleg üzemeltetett ilyen registryt annak minden járulékos bloat posványával együtt? Ja nem, mert nem ért hozzá, csak influenszerkedik.
- A hozzászóláshoz be kell jelentkezni
A kernelben nem lehet Cargot hasznalni. Most sem. Csak olyan kodot hasznalhatsz, ami a kernelfaban vagy a standard libraryban van.
- A hozzászóláshoz be kell jelentkezni
Még nem. Aztán néhány influenszer majd influenszerkedik egy sort, multis hátszéllel és kiapadhatatlan motivációval, és már azt is lehet majd. Végül kötelező lesz használni.
- A hozzászóláshoz be kell jelentkezni
Ez azert nem igy megy. Volt szerencsem ott lenni a Rust Nation UK-n par napja. Meg nincsenek fent a videok, ugyhogy belinkelni nem tudom, de Alice Ryhl a Google-tol tartott egy eloadast arrol, hogy hol tart a rust a kernelben. Sok mindent bele kellett / kell tenni a Rustba ahhoz, hogy a kernelben tamogatott legyen. Tehat elsosorban a Rust igazodik a kernelhez, es nem forditva. Es nem influenszerek hajtjak a projectet, es nem is lobogo haju free software hackerek, hanem a nagy halak, e.g. Google, MS, RedHat etc.
https://www.rustnationuk.com/schedule
- A hozzászóláshoz be kell jelentkezni
Ezalapjan a "Rust kernel eve" vagy "kernelkepes Rust eve" ugyanolyan Godot-ra varas, mint a "Linux desktop eve" - ertem mar :)
Nezzuk meg mi a szituacio 10 ev mulva. :)
- A hozzászóláshoz be kell jelentkezni
A fo kulonbseg az, hogy a nagy cegek igenis motivaltak, ugyhogy szerintem ez haladni fog. A hianyzo nyelvi funkciokat bele fogjak rakni a Rustba, legfobb ellenero inkabb az, hogy a Rust nem standardizalt, mig a C ISO standard. A kernelfejlesztoknek kellenek garanciak, hogy x-y feature nem fog eltunni a nyelvbol / stdlibbol.
- A hozzászóláshoz be kell jelentkezni
legfobb ellenero inkabb az, hogy a Rust nem standardizalt, mig a C ISO standard.
Semennyire nem releváns a kernelfejlesztés szempontjából, hogy a C-nek van ISO által sztenderdizált változata, mivel nem azt használják, tele van a kernel forrása olyan dolgokkal, ami nem része a szabványnak.
The kernel is written using GNU C and the GNU toolchain. While it adheres to the ISO C89 standard, it uses a number of extensions that are not featured in the standard. The kernel is a freestanding C environment, with no reliance on the standard C library, so some portions of the C standard are not supported.
Lehet neked akármilyen standard compliant C fordítód, nem fogod tudni vele a kernelt lefordítani.
- A hozzászóláshoz be kell jelentkezni
Igaz. Az egyik pelda arra, hogy miket kell tamogatni a Rust-nak, az a "goto label", amikor assembly-bol ugrasz ki C kodra. Valszeg ez sem ISO standard.
A lenyeg, ami nekem lejott az eloadasbol, hogy fenntartas van azzal kapcsolatban, hogy a nyelvbol ki is kerulhetnek dolgok vagy megvaltozhatnak, es ez ellen akarnak valamilyen garanciat. Gondolom, a GNU project eleg garancia arra, hogy a GNU C-vel nem fog ez tortenni. A GNU Rust compiler (gccrs) nem egy kiforrott project.
- A hozzászóláshoz be kell jelentkezni
Asszem errol az RFC-rol beszelt:
https://rust-lang.github.io/rfcs/2873-inline-asm.html#asm-goto
De van meg egy rakas RFC, amiben a GCC konkretan meg van nevezve.
https://rust-lang.github.io/rfcs/?search=gcc
Hogy ezek kozul mennyi relevans a kernel szempontjabol, azt nem tudom.
- A hozzászóláshoz be kell jelentkezni
> tele van a kernel forrása olyan dolgokkal, ami nem része a szabványnak.
Mondjuk, feltételezve, hogy csak indokolt esetben használnak nem-szabvány C feature-ket, a kód nagyobbik felére igaz lehet ettől még, hogy építenek a standard C feature-kre. Én nem érzem itt az ellentmondást,
- A hozzászóláshoz be kell jelentkezni
A Red Hat is 16 éve motivált a Wayland-ra, mégse sikerült minden szempontból jobbat csinálnia belőle, mint az X11, de mivel ezt a presztízsveszteségtől tartva nem hajlandó elismerni, így erővel, korporatokrata felhatalmazással fogja lenyomni a Linux-világ torkán a szutykát. Pont úgy, ahogy a multik fogják a Rust-idealizmust a kernelen. Semmi gond, ha lesz egy szarul-húgyul implementált, bloated fos instabil kernelünk, de legalább ráragaszthatjuk a biztonságos™ címkét, hiszen nincs benne memóriakezelésből adódó exploit. 🤡
- A hozzászóláshoz be kell jelentkezni
Lehet, hogy meglepo, de ezek profit-orientalt cegek, amik *merik* a projektek sikeresseget, es nem fixa ideak alapjan dontenek. A zaro keynote-ot Mark Russinovich (CTO, MS Azure) tartotta. A legtobb projektnel, amit migraltak, 10-15% koruli teljesitmenyjavulast is mertek, nem mindenhol, de teljesitmenyromlast viszont sehol sem.
- A hozzászóláshoz be kell jelentkezni
Volt olyan előadás, amit mindenképpen ajánlanál utólagos megnézésre?
- A hozzászóláshoz be kell jelentkezni
Ezeket emelnem ki:
- Alice Ryhl: Rust project goals 2024: Stabilizing Rust in the Linux Kernel
- Mark Russinovich: Microsoft is Getting Rusty: A Review of Successes and Challenges
- Victor Ciura: ABI Resilience
Utobbit inkabb azert mert erdekes figura, a C++ kozossegbol jott, rendszeres eloado a CppCon-on is, most meg a Rust csapatban van (MS).
A parhuzamos programozasosat en is ujra akarom nezni, mert tul kis terembe raktak, es az ajtobol nem sok mindent lehetett erteni...
- Evgenii Seliverstov: Parallel Programming in Rust: Techniques for Blazing Speed
- A hozzászóláshoz be kell jelentkezni
*merik* a projektek sikeresseget, es nem fixa ideak alapjan dontenek
Ott elég nagy probléma lehet a metrikákkal, ahol egy 10 év alatt stabilitást elérni nem képes komponenst életben hagytak. Olyat, ami az elődjének a szintjét, stabilitását, kompatíbilitását még 16 év után sem képes hozni. Vagy, a másik lehetőség, hogy csakazértis alapon, ők akarják leuralni a desktop Linuxot és újból felforgatni, hogy semmi ne maradjon a nem Red Hat által összetapicskolt technológiákból.
Persze, ugye soha nem láttunk még olyat se, hogy egy piacvezető milliárdos multi szórja a pénzt egy senki által nem kért, "legyen nekünk is sajátunk" idealizmusra. 🤡 Nem láttuk pl. a Google-t sem a Facebook-ot Google+ néven sikermajmolni, aztán bedőlni vele. 🤡 Nem láttuk az iWiW-et a Telekom irányítása alatt sem a Facebook-ot elkezdeni majmolni, majd bedőlni vele. 🤡
A legtobb projektnel, amit migraltak, 10-15% koruli teljesitmenyjavulast is mertek, nem mindenhol, de teljesitmenyromlast viszont sehol sem.
Vajon majd jövőre és az után is fennáll majd ez a százalék? Vagy utána már bloatabb lesz, csak már senkit nem fog érdekelni, mert mindenkit áterőltettek és nem lesz visszaút, inkább vesznek új gépet? A kérdés költői. Mindannyian tudjuk a választ.
- A hozzászóláshoz be kell jelentkezni
ők akarják leuralni a desktop Linuxot
Bocs, nem nagyon tudom kovetni a csapongo gondolatmenetedet, ki beszelt desktop Linuxrol? Linux kerneltol indult a szal, es az Azure-os CTO sem arrol beszelt amugy, hogy a Windowsban mindent lecserelnenek. Apro proof-of-concept project-ekkel indult, az egyik a HyperLight:
https://opensource.microsoft.com/blog/2024/11/07/introducing-hyperlight…
Aztan kis csapatok nehany honapos munkaval kisebb library-kat atmigraltak, amik biztonsagi szempontbol kritikusak, viszont nincs fuggoseguk (vagy minimalis), es nyilvan megneztek, hogy nem romlott-e a teljesitmeny, allitolag nem. UEFI, crypto, felsorolt egy rakas projektet.
Szoval az egyik fajta statisztika, amiket mutogatott az az volt, hogy a sebezhetosegek hany szazaleka vezetheto vissza olyan hibakra, amiket a Rust mar forditaskor kiszur, es hat a helyzet az, hogy az arany eleg magas, es evtizedeken keresztul szinte allando.
A masik fajta statisztika meg az volt, a C/C++ vs. Rust implementaciokat hasonlitottak ossze, sebesseg, memoriaigeny stb.
Szoval ezek utan jutottak el oda, hogy uj projekt mar csak Rustban indulhat, es nem C/C++-ban (ahol garbage collection kizart).
Nyilvan egy CTO fenyezni fogja a sajat eredmenyeiket, de nem tennenek bele a Rust Foundation-be evi 1m dollart, ha ez nem fizetodne ki nekik.
- A hozzászóláshoz be kell jelentkezni
Bocs, nem nagyon tudom kovetni a csapongo gondolatmenetedet
Szerintem csak akkor van így, amikor nem értesz egyet.
ki beszelt desktop Linuxrol?
Én beszéltem. Reagáltál is rá. Tehát felvetted a fonalat és még példálóztál is.
Szoval az egyik fajta statisztika, amiket mutogatott az az volt, hogy a sebezhetosegek hany szazaleka vezetheto vissza olyan hibakra, amiket a Rust mar forditaskor kiszur, es hat a helyzet az, hogy az arany eleg magas, es evtizedeken keresztul szinte allando.
Meg amit eddig is kiszúrtak más analyzerek is C kódból, csak azt elfelejtették megmérni, gondolom véletlenül™. Nem mellesleg azt is elfelejtették megmérni, hogy az átírkálással hány új bugot, sebezhetőséget stb. gyártottak.
Önmagában a Rust fejlesztési metodikája nagyobb kockázat, mint a memory corruption bugok lehetősége. Hogy a legegyszerűbb feladat elvégzésére is ott a netről húzigált library és erre van az egész ökoszisztéma berendezkedve. Csak ezt illik elfelejteni és mélyen kussolni róla, hiszen most egy trendet kell elterjeszteni, mivel mással, mint a divatdiktatúra eszközeivel.
Nyilvan egy CTO fenyezni fogja a sajat eredmenyeiket
Még csak fényezni sem kell, ha amit nem akarsz látni, azt egyszerűen nem méred meg.
- A hozzászóláshoz be kell jelentkezni
Szerintem csak akkor van így, amikor nem értesz egyet.
Koszonom, hogy megosztottad a gondolatodat arrol, hogy szerinted en mit gondolok akkor, amikor azt irom, hogy nem tudom, kovetni, mit gondolsz. Eleg meta. Pedig nem. Csak szimplan nem tudom kovetni.
Én beszéltem. Reagáltál is rá. Tehát felvetted a fonalat és még példálóztál is.
Nem. Abban a kommentben azt irtad, hogy a Waylandet akarja a RedHat beletolni a Linuxba. Ez valoban desktop linux, bar nem latom, hogy fugg ossze a Rusttal.
Innen jutottal el oda (ha jol ertelmeztem), hogy mar a Rust jelenlete a kernelben is tonkreteszi a desktop (!) linuxot, sot, az is a cel.
netrol huzigal library
Asszem mar tisztaztuk, hogy kernelfa es stdlib van, nincs cargo.
Nem trendet akarnak kovetni, hanem pont forditva. Van egy technologia (programnyelv, nevezd ahogy akarod), amivel penzt tudnak sporolni, es beallnak moge, gyakorlatilag fenntartani a trendet. Erdekuk, hogy ne doljon be.
Még csak fényezni sem kell, ha amit nem akarsz látni, azt egyszerűen nem méred meg.
Biztos lehetsz benne, hogy megmerik, nem hulyek, es nem erzelmi alapon dontenek. Legfeljebb nem mutatjak meg, ami nekik nem kedves.
- A hozzászóláshoz be kell jelentkezni
Ez valoban desktop linux, bar nem latom, hogy fugg ossze a Rusttal.
Az erőltetés módjában függ össze. Mind a Wayland, mind a Rust egy premature tákolmány összehasonlítva a már 30 éve létező, bevált megoldásokkal. Mindkettő erőltetésének a jelenlegi ökoszisztéma konzisztenciája, stabilitása, időtállósága látja kárát. A probléma nem a Rust-tal van, hanem azzal, hogy olyan területekre akarják relatíve rövid idő alatt beerőltetni, ahová jelenleg nem való és ezzel felforgatnak egy évtizedek óta koherens ökoszisztémát.
Innen jutottal el oda (ha jol ertelmeztem), hogy mar a Rust jelenlete a kernelben is tonkreteszi a desktop (!) linuxot, sot, az is a cel.
A Rustafárik és a mögé állt arrogáns tech-multikák úgy teszik tönkre a kernelt, ahogy a Red Hat tönkretette a desktop Linuxot.
Asszem mar tisztaztuk, hogy kernelfa es stdlib van, nincs cargo.
Még nincs.
Van egy technologia (programnyelv, nevezd ahogy akarod), amivel penzt tudnak sporolni, es beallnak moge, gyakorlatilag fenntartani a trendet. Erdekuk, hogy ne doljon be.
Amit ezek a multik megspórolnak, mások ezerszeres árat fizetnek érte, még ha ez elsődlegesen nem is pénzösszegekben realizálódik. Pont úgy, ahogy ez lenni szokott. Tipikus eset: húzzunk be még egy bloated framework-öt, mert olcsóbb lesz tőle a fejlesztés, cserébe százmillióknál jön elő a bloated framework CPU- és memória overheadje. Ezek egyoldalú "kompromisszumok".
Biztos lehetsz benne, hogy megmerik, nem hulyek, es nem erzelmi alapon dontenek. Legfeljebb nem mutatjak meg, ami nekik nem kedves.
Végeredményben ugyanaz: részrehajló mérések, egyoldalú marketing bullshit.
- A hozzászóláshoz be kell jelentkezni
Linux kapcsán az "évtizedek óta koherens ökoszisztáma" egy mítosz. Akármelyik alrendszert nézed, a változás volt állandó egyedül.
Audio alrendszer: OSS, ALSA, PulseAudio, Pipewire
Eszközkezelés : devfsd, hotplug, HAL, udev
Video alrendszer: X11R6.4, Xfree86, Xorg, Mir, Wayland
Init rendszer: sysvinit, openrc, systemd, initng, runit, upstart
Tűzfal-frontend Netfilterhez: ipchains, iptables, nftables meg ezerféle CLI eszköz (firewalld, ufw stb.)
Fordító: gcc (eredeti), egcs, gcc (egcs merge után), clang
CLI Shell: na ebből aztán van sok
Grafikus shell: ebből meg még több
Csomagkezelők: deb, rpm, apk és az újhullámos Flatpak, Appimage, Snap
Az olyan apróságokat, mint a Python2/Python3, Perl5/Perl6 (Raku) támogatás, meg hasonlók, azt hagyjuk is.
Nem véletlenül létezik a Filesystem Hierarchy Standard sem, meg a Linux Standards Base (amiknek a fejlesztése 10 éve megállt, és abandoned projekt már), egész egyszerűen nincs semmilyen koherens koncepció az egyes disztribúció- és alkalmazásfejlesztők számára, hogy mit hogyan illik csinálni egy Linux rendszerben.
Ami meg crossplatform, és támogat BSD-t is, meg Macet is, ott meg aztán alapvető, hogy az alkalmazásnak saját konvenciója van arra, hogy milyen formátumban, hol tárolja a konfigot meg egyéb fájljait.
Például amúgy jó kérdés, hogy egy 3rd party bináris (mondjuk példaként az Apache Mavent), az hova települjön? A /opt/apache/maven alatt legyenek a fájljai? Legyen-e symlink a /usr/bin-ben a /opt/apache/maven/bin/mvn-re vagy ne? Nem egyszerű kérdések ezek, és ahány ház, annyi szokás.
Ugyebár a GNU projekt lett volna az a projekt, ami szállít egy teljes értékű nyílt forrású operációs rendszert, ők 40 év alatt kernelt sem voltak képesek csinálni, illetve rengeteg dolgot képtelenek voltak szállítani, emiatt kell nagyon sok 3rd party dologhoz nyúlni, mert nincs más. Nincs komplett nyílt operációs rendszer a GNU/Linux szoftvereknél, ami koherensen lenne fejlesztve. Ez nem BSD.
Az ezerféle Linux-disztribúció meg szabadon választhat, hogy a sok-sok opensource projektből mit válogat be, mely komponensekből csinál rendszert magának. Ami állandó, az a változás, meg az inkoherens működés - projektek jönnek-mennek, kiszállnak a fejlesztők, megunják a hobbijukat stb. Hosszú távon ez nem tartható, és rengeteg erőforrást emészt fel.
Open-source komponensekből csak akkor lehet stabil dolgot csinálni, ha emögött vállalatok vannak, akik akkor is finanszírozzák a fejlesztést, karbantartást, ha amúgy a projekt maintainer megunta a dolgot. Állandság kell a projektek mögé, villamoskompatibilitás, mert máskülönben nem működik igazán hosszú távon a dolog, a nagy disztribúciók fejlesztői ezt megtanulták (meg megunták állandóan lecserélni az X dolgot Y-ra, mert az nem támogatott lett, és van helyette új shiny félkész projekt). Inkább csinálnak egy teljes oprendszert, amit ők támogatnak, nem véletlenül létezik a systemd például a Red Hat által támogatva.
- A hozzászóláshoz be kell jelentkezni
Linux kapcsán az "évtizedek óta koherens ökoszisztáma" egy mítosz. Akármelyik alrendszert nézed, a változás volt állandó egyedül.
Desktop Linuxról volt szó, ami egy elég jól körülhatárolható valami. Kernelről volt szó, ami szintén egy elég jól körülhatárolható valami. Ha a Red Hat invazív szutykait kiszeded a listából, fele annyi elem lesz rajta. Ha a többi multi szutykát is kiveszed, fele annyi se. Az X11R6.4, Xfree86, Xorg vehető egy kalap alá, mert az Xfree86 alá írt program köszöni szépen, 100% kompatíbilis az Xorg-gal. Nem igaz ez a szarul-húgyul implementált XWayland-os megoldásokra.
Azt se felejtsd el, hogy míg az ALSA lecserélte az OSS-t, addig a PipeWire, Pulseaudio már ráépülnek az ALSÁ-ra, ráadásul a PipeWire PulseAudio interface-t is megvalósít. Pont ugyanígy igaz ez a senki által nem kért firewalld-re.
GCC-vel mit nem tudsz lefordítani az egcs merge után?
CLI Shell: na ebből aztán van sok
Van olyan, amire a fél világ dependál és ez kizárja az alternatívákat? Nincs. A bash-re a fél világ dependál, de ettől még használhatsz bármilyen shell-t. Xorg-ot fogsz tudni használni, miután a Red Hat beerőltette a Wayland-szutykát, és az egész desktop Linuxot rádependáltatta? Nem fogsz.
Az olyan apróságokat, mint a Python2/Python3, Perl5/Perl6 (Raku) támogatás, meg hasonlók, azt hagyjuk is.
Nem kell hagyni, a Python2->Python3 átállás hasonló erőltetett menet volt. A mai napig létező és akár production-ben is futó Python2 kódok jól mutatják, hogy igény egyértelműen a Python2 további támogatására volt, nem annak deprekálására. 2020. január 1-jén deprekálták. A 2 évvel később kiadott (2027-ig támogatott) Ubuntu Jammy pedig szállította a python2 csomagot default repoban.
Az ezerféle Linux-disztribúció meg szabadon választhat, hogy a sok-sok opensource projektből mit válogat be
Már amíg a dependencialáncok ezt lehetővé teszik. Az a fajta beerőltetés, felforgatás stb. amit a multik csinálnak a Linux-szal (élen a Red Hat-tal) éppen ezt a szabadságot veszi el.
Open-source komponensekből csak akkor lehet stabil dolgot csinálni, ha emögött vállalatok vannak
Ez a legorbitálisabb tévedés, amit open-source vonalon elkövethetsz.
akik akkor is finanszírozzák a fejlesztést, karbantartást, ha amúgy a projekt maintainer megunta a dolgot
Ez azt feltételezi, hogy mindenre csak egy maintainer van, ami egy kellően nagy open-source közösség esetén nem igaz.
Állandság kell a projektek mögé, villamoskompatibilitás, mert máskülönben nem működik igazán hosszú távon a dolog
Ezt majd magyarázd el kérlek a Wayland-ot erőltetőknek. :) Nem, az XWayland továbbra sem ad teljes kompatíbilitást és egy instabil bloat szutyok.
Inkább csinálnak egy teljes oprendszert, amit ők támogatnak, nem véletlenül létezik a systemd például a Red Hat által támogatva.
Csináljanak, csak ne forgassák fel vele a Linux-világot. Látsz YaST-ot bármelyik disztróban? Látsz rádependáló desktop környezeteket? Nem. Mert a SuSE tudott úgy, már a Red Hat előtt is működni, hogy ne forgassa fel a Linux-világot. Nem azzal van baj, hogy enterprise minőségű Linuxot nagyvállalatok csinálnak. Azzal van, hogy mindent, ami oda bemegy, beerőltetnek máshova is. Ez hosszú távon a Linux teljes felforgatásához vezet. Csináljanak saját, Linux-alapú oprendszert, legyen benne systemd, pulseaudio, pipewire, meg amit akarnak, csak ne erőltessék rá a Linux-világra invazív módon, dependenciákon keresztül.
- A hozzászóláshoz be kell jelentkezni
Azzal van, hogy mindent, ami oda bemegy, beerőltetnek máshova is. Ez hosszú távon a Linux teljes felforgatásához vezet.
Senki nincs kötelezve, hogy ezeket a cuccokat használja. Bármelyik disztró szállítója dönthet úgy, hogy kihagyja a dolgokat. Ahogyan kihagyták a Yastot, a zyppert, az ezerféle más projektet, úgy lehet kihagyni a Red Hat többi projektjét is, senkit nem köteleznek, hogy használja. A közösség eddig is bármit és bármikor forkolt, ha úgy látták jónak.
Nem kell használni pipewire-t, nem kell használni systemd-t, nem kell használni semmilyen Red Hatos dolgot, senki nem kötelez erre.
- A hozzászóláshoz be kell jelentkezni
Senki nincs kötelezve, hogy ezeket a cuccokat használja.
Még nincs.
Bármelyik disztró szállítója dönthet úgy, hogy kihagyja a dolgokat.
Egészen addig, amíg nem kell emiatt saját kernel-kódbázist karbantartania.
Ahogyan kihagyták a Yastot, a zyppert, az ezerféle más projektet
Az ne zavarja Persics Mérnök Urat, hogy ezek kihagyható projektek, mert nem dependál rájuk a fél világ. 🤡 Tehát amíg egy nem invazív YaST kihagyása triviális bármelyik disztróból, addig pl. az invazív Red Hat szutykok (systemd, pulseaudio, pipewire), vagy egy Rust-idealizmussal megerőszakolt kernel nem lesz az.
Nem kell használni pipewire-t, nem kell használni systemd-t, nem kell használni semmilyen Red Hatos dolgot, senki nem kötelez erre.
Az a projekt kötelez erre, ami nem ad más választási lehetőséget, mert nem hajlandó natívan ALSÁ-val vagy systemd nélkül működni. Pedig adott projektet se kötelezte senki a systemd adoptálására. Próbáld meg felismerni az invazív projekteket, hogy mitől invazívak. Ha sikerül felismerned, akkor meg fogod érteni, hogy a systemd (sajnos) miért nem YaST, és hogy a SuSE miért jóval kevésbé arrogánsabb multi, mint a Red Hat.
- A hozzászóláshoz be kell jelentkezni
Ja, pont ezt akartam írni.
"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"
Szóval nem ismeri a Rust-ot, de lelkesedik érte. Majd elmúlik.
Azok a C hibák, amiket említett, elég tipikusak. De Rust-ban meg majd lesznek mások. Illetve ott van az a use-after-free. Az nem úgy szokott történni, hogy hívok egy kfree-t, majd használom a struktúrát ugyanabban a rutinban. Hanem inkább úgy, hogy megvolt a kfree(), de aztán jön még egy callback, és az fogja használni azt a bizonyos változót. Az ilyenek ellen semmilyen programnyelv nem fog megvédeni.
- A hozzászóláshoz be kell jelentkezni
Öhm... Kedves bzt, minden tisztelettel, de te most tényleg le álszakértő faszkalapoztad Greg KH -t? Ez azért egy kicsit erős, és ha belegondolsz, kontraproduktív is, mert aki ilyet ír, annak az egyébként valid érveit hajlamos az ember kevésbé végiggondolni, mert úgy véli, hogy csak indulatból ír, azzal meg tele a bulvár, úgyhogy skip.
- A hozzászóláshoz be kell jelentkezni
Kedves bzt, minden tisztelettel, de te most tényleg le álszakértő faszkalapoztad Greg KH -t?
Kedves YieGreg, te most tényleg ennyire gyatra vagy magyar nyelvű szövegértésből?
Nem is én állítottam, hogy Greg nem ért a Rust-hoz, hanem saját maga. De neked olvasni finnugrot nem megyen, igaz-é? És igen, ha valaki úgy nyilatkozik, hogy tudja, nem is ért hozzá, az biza' kontraproduktív és faszkalap, akárcsak az itteni szánalmas TROLLok.
- A hozzászóláshoz be kell jelentkezni
Nem azt írta, hogy nem ért hozzá, hanem hogy "And yes, the Rust bindings look like magic to me in places, someone with very little Rust experience, but I'm willing to learn and work with the developers who have stepped up to help out here.".
Az ő múltjával én úgy vélem, hogy ami nála "very little Rust experience" az egy olyan magasra tett léchez képest very little mint a C tudása. Vagyis egy sima Rust programozó aki csak a Rust -hoz ért, az azt hiszi, hogy már milyen sokat tud, de aki egy más nyelvet kívül-belül az utolsó szögig ismer, az az egyébként erős Rust tudásáról simán úgy vélekedhet, hogy "de hiszen alig ismerem, még csak pár éve használom...".
Lehet, hogy én felülbecsülöm GKH tudását, de az alapján amit eddig letett az asztalra, szerintem eléggé végiggondolta amit mondott, és ha a C tudásához képest úgy is érzi, hogy még kevés a tapasztalata a Rust -al, szerintem annyira biztosan beleásta magát, hogy megbízható véleményt tudjon alkotni. Én bízom az értékítéletében.
- A hozzászóláshoz be kell jelentkezni
Szerintem Greg látnok. Mondom ezt keményvonalas C-sként.
Számomra egyre nyilvánvalóbb, hogy mainstream-ben a Rust lesz az új C.
Nyilván van egy csomó kiöregedő fejlesztő, aki egész életében C-ben fejlesztett, talán még hexadecimális szorzótáblával kezdett, és minden emléke, élménye ehhez az ökoszisztémához kötődik, nem tudja ezt elfogadni. Szerintem ők a peronon fognak maradni.
Ez nem azért lesz így, mert szar a C. Hanem mert változtak az igények.
- A hozzászóláshoz be kell jelentkezni
Olyan jó volt az első mondatod!
De aztán rájöttem, hogy nem rólam beszélsz... :,-(
- A hozzászóláshoz be kell jelentkezni
:D ಠ_ರೃ
- A hozzászóláshoz be kell jelentkezni
Egy új nyelv hozzáadása igazán nem kellene, hogy problémát jelentsen
Ez még felkerülhet a híres utolsó mondatok közé ;)
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.
Ha jól értem, most éppen ezen a jól működő modellen akarnak változtatni?! Akkor mi jelentősége annak, hogy eddig jól működött. A C-hez, Rust-hoz nem értek, de általában a a komplexitás növekedésével, a hiba lehetősége is növekedni szokott. A hibafaktor eddig is az ember volt, aki nem írt megfelelő C kódot, most ezt cserélik le, egy másik emberi hibára lehetőséget adó dologra, a kevert nyelvű kódbázisra.
- A hozzászóláshoz be kell jelentkezni
Sőt én továbbmegyek. Értem, hogy GKH igyekszik lelkesítő lenni, de az a mérnöki csoda a válságát éli. Ezt a válságot pedig az utápótlás nélküli; hálátlan feladatba belefásuló, kiégéshatáron lévő maintainerek jelentik (vagy ahogy tetszik, ők a fő tünetei). Hogy valójában mekkora válság, azt nem tudom hogy meg tudjuk-e ítélni kívülről.
De az biztos, hogy az utolsó dolog, amit a szerettek volna a nyakukba kapni, az a projekt kétnyelvűsítése, amiben az átjárást biztosító binding-ok integritása felett is nekik kell őrködniük. Úgy, hogy a napi kb 1000 pull request átnézése mellett kéne felszedniük a rust-ot, ráadásul olyan mélységben, amilyenben a legtöbb napi szinten rust-ban kódoló fejlesztő sem érti.
Biztos vagyok benne, hogy ez még sok maintainernek fogja megadni a végső lökést, hogy otthagyja a projektet. Ami - mint változtatás - nem a válságból kilábalás irányába viszi a dolgokat.
(Ettől függetlenül értem azt is, hogy miért nyomatják a Rust-ot. Könnyen lehet, hogy az elutasítása ugyanúgy a projekt hosszabbtávú megrekedését eredményezné. Ez egy baromi nehéz kérdés, amire szerintem nincs egyértelműen jó megoldás.)
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
Értem, hogy GKH igyekszik lelkesítő lenni, de az a mérnöki csoda a válságát éli.
GKH egyetlen mérnöki vagy szakmai érvet sem hozott fel, csak a szokásos bullshitet puffogtatta.
ráadásul olyan mélységben, amilyenben a legtöbb napi szinten rust-ban kódoló fejlesztő sem érti.
Azért tudsz te okosat is mondani, ha akarsz. Pontosan erről van szó. És még tegyük hozzá azt is, hogy a Rust nincs rendesen specifikálva, a fordító napi szinten változik.
Biztos vagyok benne, hogy ez még sok maintainernek fogja megadni a végső lökést, hogy otthagyja a projektet. Ami - mint változtatás - nem a válságból kilábalás irányába viszi a dolgokat.
Szerintem pontosan ez a cél, a Microsoft így akarja belülről szétbomlasztani az egyetlen épkézláb konkurenciáját. A Linux Foundation már a kezükben van, ezzel befogták Linus száját.
Ettől függetlenül értem azt is, hogy miért nyomatják a Rust-ot. Könnyen lehet, hogy az elutasítása ugyanúgy a projekt hosszabbtávú megrekedését eredményezné.
Ezzel vitatkoznék. Hosszú távon mindig könnyebb egy unilanguage projektet továbbvinni.
- A hozzászóláshoz be kell jelentkezni
"Azért tudsz te okosat is mondani, ha akarsz."
s/ha akarsz/ha az történetesen egyezik a véleményemmel/ - jól gondolom?! :)
"Microsoft így akarja belülről szétbomlasztani az egyetlen épkézláb konkurenciáját" - hagyjuk már ezt, jó? Nem a 2000-es évek elején vagyunk. Apple, Google, Meta. Ők például konkurenciák. Nem a Linux eltiprásán múlik a Microsoft jövője.
"GKH egyetlen mérnöki vagy szakmai érvet sem hozott fel," - azért elég sokan elmondták már a szakmai érveket. Mert megold egy problémát, amit eddig más nyelv nem tudott megoldani: memóriabiztosságot adni garbage collector és mindenféle memory manager runtime nélkül. Ez utóbbiak lényegében ellehetetlenítették a memóriabiztos programnyelvek használatát kernel-fejlesztésre (néhány nagyon ezoterikus próbálkozástól eltekintve, ahol pl Java-ban próbáltak kernelt írni).
Igen, valóban találtak benne egy olyan speciális esetet, ahol a memory leaket elvileg sem tudja fordítási időben kivédeni. Más kérdés, hogy eléggé szándékosan akarni kell azt a helyzetet (ciklikus Rc referenciák) előidézni. Ez nem egy olyan dolog, amit csak úgy könnyen "benéz" egy fejlesztő, pláne ha hallott is róla, hogy ez kerülendő.
Kérdés: meg se próbálkozzunk vele, mert nem 100%-os (csak 99)?
Kérdés 2: meg se próbálkozzunk vele, mert a fordító változik (mint ahogy a gcc is elég sokat változott az évek alatt, főleg a korai időkben, aztán meg jött az llvm/clang)?
Kérdés 3: meg se próbálkozzunk vele, mert agytorzító benne programozni? Különösen annak aki C-származék nyelvekhez szokott
Kérdés 4: meg se próbálkozzunk vele, mert a felfoghatatlanul nagy C-ben megírt kódbázis miatt esélytelen belátható idő alatt átírni az egészet?
Én is hajlok arra, hogy ez nem volt jó döntés, de teljesen más okból, mint amiket te próbálsz felhozni. És hajlok arra is, hogy az elutasítás sem lett volna jó döntés, mert hosszú távon bezárja a Linuxot egy idővel egyre inkább elavuló programozási környezetbe. Ami nem most azonnal fog kiütközni, hanem 10 év múlva (ha még lesz akkor elő ember). Erre nem volt jó válasz. Illetve hát lehetett volna még húzni az időt a döntéssel (dolgoztam olyan cégnél ahol ez volt a hozzáállás, na ők pl már nem konkurenciái se a Microsoftnak, se Apple-nek, se Google-nek...). Csak kérdés, hogy mi az az információ amire Linus-nak várnia kellett volna, ami alapján jobban tudna dönteni a jövőben?
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
s/ha akarsz/ha az történetesen egyezik a véleményemmel/ - jól gondolom?! :)
Rosszul gondolod.
azért elég sokan elmondták már a szakmai érveket.
Citation needed. Én még egyetlen konkrét szakmai érvet sem hallottam a Rust mellett, csak bullshitelést. A topiknyitóban sem szerepel egy komoly érv sem, csak a szokásos bullshit (ráadásul amiket ellenpéldák cáfolnak, keress csak rá, egyik Rust állítás sem állja meg a helyét a gyakorlatban).
Ellenben a Rust ellen érvelők nagyon is konkrét szakmai érveket hoznak fel, lásd másik topik.
Igen, valóban találtak benne egy olyan speciális esetet, ahol a memory leaket elvileg sem tudja fordítási időben kivédeni.
Legalább olvasd el, amit linkeltem, mielőtt írsz. Memory vulnerability-ről van leginkább szó (bár a memleak ellen sem véd, tény).
Más kérdés, hogy eléggé szándékosan akarni kell azt a helyzetet (ciklikus Rc referenciák) előidézni. Ez nem egy olyan dolog, amit csak úgy könnyen "benéz" egy fejlesztő, pláne ha hallott is róla, hogy ez kerülendő.
Ébresztő, a Linux kernel tele van kettős láncolt listával, ami pont ilyen! És nem, nem a kernel fejlesztők nézték be, szándékosan van így implementálva, méghozzá okkal.
- A hozzászóláshoz be kell jelentkezni
Az a baj, hogy már megint azonnal nagyon sommás véleményed van valamiről aminek a darabaji nem kerültek a helyükre nálad.
"Legalább olvasd el, amit linkeltem, mielőtt írsz. Memory vulnerability-ről van leginkább szó"
Az FFIChecker-esről beszélsz? Elolvastad, vagy csak az abstractig jutottál? Segítek: ha nem a Springer felől akarod elérni, akkor nincs paywall: https://zhuohua.me/assets/ESORICS2022-FFIChecker.pdf Ahogy olvasom egyetlen konkrét vulnerability-t sem talált. Talált leak lehetőséget, talált undefined behavoir-t, és exception kezelési hibát. Meg talált egy szakajtónyi fals pozitívat. Nem írnak a cikkben arról, hogy bármelyik talált hiba önmagában kihasználható lett volna. Végig "may lead to potential vulnerabilities" a megfogalmazás.
És ez nem a Rust problémája, hanem a kétnyelvűség problémája. És a cikk lényegében pont arról szól hogyan lehet statikus checkert fejleszteni az ilyen hibák megfogására -> a jövőben ezek jobban szűrhetőek lesznek.
" tele van kettős láncolt listával, ami pont ilyen"
A kettős láncolt lista egy másik probléma, mint a Rc körbehivatkozás. Én anno végigcsináltam ezt a tutorialt: https://rust-unofficial.github.io/too-many-lists/ ami a láncolt lista különféle lehetséges implementációin - mint állatorvosi lovon - keresztül mutatja be az egész nyelvet, a borrow checker összes corner case-ével együtt. Egyébként javaslom, mert helyrerak sokmindent (ugyanakkor nem is hozta a kedvemet, hogy rust programozó legyek...). Persze *lehet* úgy is csinálni, hogy a ciklikus Rc problémába belefuss. De a javasolt módszer, hogy a visszirányba kell egy unsafe raw pointer, ha nem akarsz gyenge referenciákat használni.
Azt kell megértened, hogy a generics támogatás miatt ezt az unsafe részletet egyszer kell a kernelben jól megcsinálni, és nagyon alaposan reviewzni. Onnantól mindig lehet ugyanazt újrahasználni. C-ben a reuse nem ilyen tiszta.
(Edit: typo fix)
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
Az a baj, hogy már megint azonnal nagyon sommás véleményed van valamiről
Az a baj, hogy már megint azonnal nagyon sommás véleményed van valakiről, miközben nem is ismered.
Elárulom, én ha állítok valamit itt a HUP-on, akkor biztos lehetsz benne, hogy alaposan utánajártam a témának. Ezért van az, hogy nekem van igazam, a TROLLok meg tévednek. Nem azért, mert tévedhetetlen szupermen lennék, hanem mert posztolás előtt én elvégzem a házi feladatot, míg ők nem. Ennyi.
Itt most történetesen Rust-C illesztés ügyben ráadásul nemcsak elméleti, hanem többéves gyakorlatom és saját tapasztalatom is van. Tömören: nem jó.
- A hozzászóláshoz be kell jelentkezni
Ms így akarja belülről szétbomlasztani az egyetlen épkézláb konkurenciáját
Ugyan a rust programnyelvet nem ismerem, de amit az Ablakok 11-el leműveltek, hogy még a saját, addig valahogy elműködgető rendszereiket - xp, Ablak 7 - is teljesen szétcseszik, pont elég bizonyíték arra, hogy bzt-nek és Hajbinak van igaza.
Az Ablakok 10 is már baromi idegesítő, hogy ha tegnapra kész kellene lenni valaminek, bekapcsolom és elkezd frissíteni, több ujraidulással - mikor már 18 éve megígérték, hogy mellőzik az állandó ujraindulásokat - pedig gpedit-ben be van állítva hogy 2 és az aktív időszakban teszi mindezt.
"A Windows 10 rendszer folyamatosan frissíti magát, hogy biztosítsa a legújabb biztonsági javításokat és funkciókat."
nem b..eg, ha valamit AKAROK azonnal csinálni, akkor ne bíráljon felül egy sz@r op rendszer.
Raynes- írta, hogy ez adta meg neki a végső lökést a Linuxra való rugalmas átmenethez.
- A hozzászóláshoz be kell jelentkezni
Régóta mondom, hogy az a legjobb operációs rendszer, amiről nem is tudja az ember, hogy létezik. Ha az oprendszer soha nem hátráltat, láthatatlanul a kezem alá dolgozik, és hagyja, hogy a munkámmal törődjek, akkor pont azt teszi, amit várok tőle.
Ez linuxnál többnyire megvan, mert csendes, nem nagyon kér enni, nem kér buksisimit, néha tol neki az ember egy apt/dnf/whatewer upgrade -et, de nagyjából ennyi.
Windowsnál meg próbálom kimozogni a hülyeségeit, én dolgozok vele, pedig én vagyok a fizető vendég, hát akkor miért nem én vagyok a főnök?! Miért nekem kell a sz4rt lapátolnom, és igazodnom az olyan hülyeségeihez, ami pár verzióval korábban még nem volt kötelező? Jó, hát ez valójában nem kérdőjel, mind tudjuk, hogy a pénz miatt. Kár, hogy nincs olyan Windows verzió, hogy oké, duplába kerül, de hagyjon békén a baromságaival, alapból kussol és tud annyit az ablakkezelő gyárilag, mint egy évtizedes KDE.
Az LTSC nagyjából az egyetlen ami még használható agykárosodás nélkül.
- A hozzászóláshoz be kell jelentkezni
Ezt ugatom én is! Az operációs rendszer azért van, hogy a rendszer erőforrásait kezelje és ne felzabálja a felhasználói programok és a felhasználó elől!
- A hozzászóláshoz be kell jelentkezni
nem b..eg, ha valamit AKAROK azonnal csinálni, akkor ne bíráljon felül egy sz@r op rendszer.
Soha még nem fordult velem olyan elő, hogy csináltam valamit a gépen, és ezt megszakította egy windows update. Legalábbis az elmúlt 10 évből nem rémlik ilyesmi. Illetve de, egy céges gépen a központi management megoldás küldött ki valami zeroday patchet úgy, hogy 15 percem volt befejezni a futó munkát, de ezt a céges IT csinálta, nem a Microsoft.
Nálatok ez hogy működik? 4 hétig tologatjátok az update-eket (asszem ennyi a default limit), és pont 3 hét, 6 nap, 23 óra 55 percnél kezdtek nekiállni valami Nagyon Kritikus feladatnak, természetesen a beállított aktivitási időablakon kívül, mondjuk hajnali négykor?
- A hozzászóláshoz be kell jelentkezni
Nem szoktam halogatni, de rendszeresen előfordul, hogy előveszem a táskámból a gépet, bekapcsolom és várnom kell, mert frissítéseket telepít. Volt, hogy hatósági átadáson kellett rá várni, volt hogy prezentáció előtt.
Természetesen ki tudom várni, de bassza már meg az öreg ördög. Nem azért vettem a gépet, hogy a Microsoft használja!
Kicsit elszaladt a ló! Ahogy írtam más témáknál is: az operációs rendszer feladata az erőforrások kezelése/elosztása és nem a felzabálása a felhasználó programok és a felhasználó elől!
szerk.: kellett nekem emlegetni. Ma oktatást/prezentációt tartottam. Egy órával előtte bekapcsoltam a gépem, elmentem reggelizni/kávézni (nem, még nem munkaidő). Visszaérve a gép elé: a windows frissít éppen. Én meg éppen oktatást tartanék... Egy jó 20 percet kellett várni rá!
- A hozzászóláshoz be kell jelentkezni
Nálam is éjjelre/hajnalra van téve az inaktivitási ablak, és ez így többnyire jó is, de volt egy olyan éjjeli meló, amikor hajnali kettő körül kicsit hátradőltem míg vártam a kolléga munkájára, és amikor kinyitottam a szemem, azt láttam, hogy ne kapcsolja ki a gépet... Anyád.
A másik az részben céges policy utálat is, hogy jön hogy újra kell indítani a gépet, mer csak. Na, nnálam többnyire nem csak egy mail kliens meg egy excel van nyitva, hanem jó pár SSH ablak, meg minden ami létezik, mindig kell két két sor a tálcán az ablakok gombjainak. Na, ilyenkor nagy öröm ám újra beállítani a munkakörnyezetet, belépni mindenhova, csak mert ez a hipermodern gép képtelen lecserélni egy futó processzt egy másikra reboot nélkül, mert nem engedi el a filerendszerben a telepítés idejéig. A GUI lebutítása helyett inkább törődnének azzal, hogy az update miatt ne kelljen reboot. 2025 van csesszék meg, mióta tudta ezt már a legkreténebb egy floppys linux is? De legalább van virtuális desktop, azzal csak két évtizedet késtek...
A Windowsról ordít, hogy a MS sem veszi komolyan. Csak muszájból gányolja újra szét, ami az előző verzióban már kezdett jó lenni.
- A hozzászóláshoz be kell jelentkezni
A céges policyk mindig tudnak érdekesek lenni. Nálunk pl. az (is) volt, hogy kitalálták, egy héten legalább egyszer újra kell indítani a gépet, ha valaki nem szokta lekapcsolgatni naponta. Ezt - hogy ne legyen nagyon zavaró, valamikor hétfő hajnalra tették. Ez csak akkor kellemetlen (de akkor nagyon), ha valamely okból vasárnap éjfélkorra kap az ember időpontot egy hosszabb release-re, és a release kellős közepén a gép minden értesítés nélkül újraindul. Ha esetleg többen voltunk benn egy release-ben, akkor némi időeltolódással, hol az egyik gépe indul újra, hol a másik, és így tovább.
- A hozzászóláshoz be kell jelentkezni
Ez az ún. fileless-malware-ek miatt lett bevezetve, amik nem perzisztáják magukat, hanem végig teljesen memóriában maradnak.
Gondolom egyszer bekerült valamelyik compliance-követelményrendszerbe és onnantól ez egy kötelezően implementálandó endpoint security szabály lett mindenhol. Ha nem csinálod, elbukod az auditot. Nálunk is a Macbook-ok lazán elmentek hetekig lecsukom-suspend, felnyitom-resume módon, de most már jön a dörgedelem, hogy nem volt x ideje restartolva, max 1-2 órával tudom elhalasztani (ráadásul olyan fos módon implementálták le a yamf-ban, hogy az szerver oldalon tárolja az uptime-ot - hol máshol - és teljesen rendszeres, hogy "nem veszi észre", hogy a gép restartolva volt és újra és újra cseszeget vele. Ilyenkor jönnek a sudo yamf recon meg kétszer restartolom restartolom meg hasonló manuális workaroundok)
Mostanában a céges telefonokra is kezdik teríteni a kötelező restart policy-t.
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
Hú, ez tetszik. Szólok is a biztonsági igazgatóságnak, hogy a termelési rendszer ezres nagyságrendű gépparkját jó lenne hetente újraindítani... aztán kurva gyorsan elmegyek szabadságra, mielőtt a munkatársak hordája rám ront fáklyával és vasvillával! :-)
- A hozzászóláshoz be kell jelentkezni
Valószínűleg nem a gyártósor vezérlésére gondolt, meg hasonlókra a kolléga, mert azoknak eleve semmi keresnivalója nincs nyilvános hálózaton, ergo az update rollout stratégia is máshogy szokott kinézni.
- A hozzászóláshoz be kell jelentkezni
Tiszta sor. Ezért volt ott a smiley.
- A hozzászóláshoz be kell jelentkezni
Ha auditor vagy...
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
Képtelen vagyok megérteni, mért kell egy frissítés miatt a rendszert újraindítani. Unix-os gépeinken nem ritkán több ezer napos uptime volt. Max. egy service-t restartolsz. De hogy mindent félbe kelljen szakítani...nonszensz.
- A hozzászóláshoz be kell jelentkezni
Az az igazi szegyen, hogy mikozbem a telefon korunk desktopja, az asztali excelezos munkaallomast gyakrabban kell ujrainditgatni mint a telefont... :-)
- A hozzászóláshoz be kell jelentkezni
Én értékelem, hogy próbál normális lenni, egy elég jó fazon ez a Greg, mindig is szimpatikus volt, nagyon jó szíve van, de itt hiába próbál rendes lenni, meg elismerő a Rust-ról, ezt a kialakult szart nem fogja tudni feloldani egy kis békítéssel, meg a Rust erősségeinek az elismerésével. Arra azért jó lehet, hogy az ő véleményére legalább ad Linus, ha már máséra nem is. Annyival mentődhet most a rust-osok helyzete, de ez megint csak egy kis haladék lesz, a következő balhé előtt, ahol már szakadni fog a cérna Torvaldsnál is, és dobni fogja ezt az egész rust-ozást kompletten, ezt előre megmondom, pár hónap múlva visszajövök a topikba, és beírom, hogy igazam lett.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
- A hozzászóláshoz be kell jelentkezni
kroozo, persicsb, snq- látom befutottak a szánalmas TROLLok, akik még csak a témához sem képesek hozzászólni, csak ócsárolni próbálják a másikat.
Kis trolldetektor úgy beriasztott rátok, hogy a fal adja a másikat, LOL!
@gabrielakos, hol vagy ilyenkor? Miért nem szólsz rá a TROLLokra? (Most már lehet érdemes lenne összeszámolni, hány olyan eset fordult elő, amikor az admin a kifejezett kérés ellenére sem tett semmit.)
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Neked hogy akadt be, hogy gabrielakos itt admin? Nem először olvasok ilyet tőled.
- A hozzászóláshoz be kell jelentkezni
bzt nem tudja kezelni az indulatait és már többször be lett neki szólva, hogy fogja vissza magát...
aztán mindig ezzel jön, hogy gabrielakos büntesse csak meg azokat a gonosz trollokathuppereket, akik nem méltóztatnak magukat összeszarni tőle :) ...
- A hozzászóláshoz be kell jelentkezni
Ez világos, de miért pont Ákos? Miért nem te vagy én? :)
- A hozzászóláshoz be kell jelentkezni
Egyszer kiderül, hogy a veterán flaget nézte admin jogosultságnak, meglep, hogy ezek után még mindig ezt hozza elő. De ha már így alakult, Ákos, igazán kidobhatnád :)
- A hozzászóláshoz be kell jelentkezni
A tévedés beismerése már régen sem szerepelt a soft skillei között.
- A hozzászóláshoz be kell jelentkezni
ő volt a "balfasz@hup" cím nyertese? 🤭
- A hozzászóláshoz be kell jelentkezni
Na várjál, várjál, bzt==turdus? Vagy nem jó a link?
- A hozzászóláshoz be kell jelentkezni
imho elég egyértelmű :)
- A hozzászóláshoz be kell jelentkezni
immár szteroidokon
- A hozzászóláshoz be kell jelentkezni
Jó a link, az egyenlőség pedig igaz.
- A hozzászóláshoz be kell jelentkezni
Én nem ócsárollak, csak röhögök rajtad. Semmi értelme veled beszélgetni, mert azt hiszed, hogy mindenkinél okosabb vagy, cserében benne vagy top 5 azonnal személyeskedő, másokat fikázóban a hupon (és igen jó fej voltam azzal az öttel), szóval tök őszintén, ha fáj, hogy ócsárolni próbálnak, hát suck it up buttercup, neked egy szavad nem lehet.
Ez a gabrielakos dolog meg, szóval vasorrú bába, meg mágnesvihar :D
- A hozzászóláshoz be kell jelentkezni
benne vagy top 5 azonnal személyeskedő, másokat fikázóban a hupon
Ugyan linkeld már be, ebben a topikban mikor személyeskedtem és fikáztam!
Egyetlen egyszer sem. A TROLLokról általánosságban beszéltem, ha magadra vetted, hát, no comment!
- A hozzászóláshoz be kell jelentkezni
Az első kommentedben alszakerto faszkalapoztad a linux kernel kb masodik legprominesebb emberét, engem meg konkrétan megneveztél te szerencsétlen, milyen általánosságban?
HAZUDSZ!!!!!!
:-D:-D:-D sírok.
ja és persze egy szóval nem mondtam, hogy ebben a topicban. Szóval TERELSZ!!! CSÚSZTATSZ!!!
- A hozzászóláshoz be kell jelentkezni
Én még mindig nem értem, miért nem lehet a C-hez ilyen ellenőrzést csinálni és a többszálúságra jobban felkészíteni. Szerintem a c++ betegesen felfúvódott.
Unsafe c -> a normál. Safe meg a többszálú ellenőrzős.
- A hozzászóláshoz be kell jelentkezni
Nemcsak lehet, hanem van. Ma már nem találsz olyan C fordítót, amiben ne lenne alapból ASAN, UBSAN, stack-check, bound-check stb. opció. Plusz rengeteg tool létezik a lefordított bináris ellenőrzésére (pl. valgrind, fuzzers stb.), amik csont nélkül ellenőrzik a többszálú programokat is.
Egyáltalán nem ördöngős jól megírni egy C programot, egy-két hónap gyakorlás után simán rutinná válik, csak hát ez nincs hypeolva.
- A hozzászóláshoz be kell jelentkezni
Na bele is nézek majd ezekbe, mert a rustnak nagyon visszataszító a kinézete.
- A hozzászóláshoz be kell jelentkezni
valgrind a kernelre?
Pl. "valgrind --leak-check=full /boot/zImage"? Vagy hogy?
- A hozzászóláshoz be kell jelentkezni
persze... s valgrind bzt bootloderétől fogja allokálni a memóriát 🤭
- A hozzászóláshoz be kell jelentkezni
valgrind a kernelre?
Nyilván nem, arra fuzzer való. Tudod, ott mindjárt a vessző után a zárójelen belül... "(pl. valgrind, fuzzers stb.)"
Legalábbis ha 3rd party toolokról beszélünk, amit úgy kiragadtál a kontextusából. Elsősorban ugyanis fordító opciókról beszéltem, amik működnek kernellel is.
- A hozzászóláshoz be kell jelentkezni
Ezt a sok picsogást itt, ha valaki olyat mond, ami nem tetszik nekik. Amúgy olvasni mindenféle hasonló kezdeményezésről, amik pl a C nyelvet reformálnák meg. Ha a Rust sz@r, miért nem lehetne helyette felkarolni valamelyik hasonló kezdeményezést és azt mondani, hogy ez jobb ezért meg azért... + még a neve sem olyan szerencsétlen :D
- A hozzászóláshoz be kell jelentkezni
Ezt a sok picsogást itt
Hát ja, csak úgy dagonyáznak itt a TROLLok, akik semmi érdemlegeset nem tesznek hozzá, csupán csak a másikat próbálják ócsárolni... persze sikertelenül, mert csak magukat járatják le.
Ha a Rust sz@r
Nem erről van szó. Az a baj, hogy a rasztafárik nem hajlandók meghallani semmiféle jogos kritikát, hanem habzó szájjal fröcsögni kezdenek, pont mint az itteni TROLLcsorda. Nyilván ebből így sosem lesz egy jó nyelv / fordító (*), hisz ahhoz elengedhetetlen lenne, hogy odafigyeljenek az építő jellegű kritikákra.
(*) - ez meg is látszik, a Rust specifikáció még mindig nem teljes, olyan alapvető dolgok, mint az ABI sincs fixálva és folyton változik, emiatt törik a visszafelé kompatíbilitiás.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Az az egy nem aggaszt, hogy nem terjed el, annyira agresszíven nyomják, az folyik a csapból is, hogy lehetetlen, hogy ne legyen végül mindenkire rátolva. Az AI után most a legmenőbb buzzword, mindent írnak újra Rust-ban.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
- A hozzászóláshoz be kell jelentkezni