- A hozzászóláshoz be kell jelentkezni
Hozzászólások
popcorn elő
“Luck Is What Happens When Preparation Meets Opportunity" - Seneca
- A hozzászóláshoz be kell jelentkezni
mindig megy a sírás ha valamit régi , oldschool stabil dolgot kivesznek a kernelből. de most úgy látom nincs semmi . kár , csalódtam , már a hup sem a régi.
“Luck Is What Happens When Preparation Meets Opportunity" - Seneca
- A hozzászóláshoz be kell jelentkezni
Úgy tudom, az ext4 driver tudja az ext2, ext3, ext4-et kezelni, így dedikált ext2 driverre akkor sincs szükség, ha valaki használ ext2-t.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
már a hup sem a régi
A megállapítás majdnem helyes. De nem a HUP változott, hanem a közönsége.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Hogy repül az idő - és változnak a preferenciák:
- "...A Hungarian Unix Portal, röviden HUP[1] a legnagyobb magyar nyelvű Unix, Linux, BSD és egyéb Unix-szerű operációs rendszerekkel foglalkozó weboldal, amely körülbelül 2000 óta szolgálja a magyar UNIX közösséget..."
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
- A hozzászóláshoz be kell jelentkezni
ooo....te tudod egyaltalan mi a fajlrendszer es pont az ext hogyan is mukodik? Mert akkor nem mondanal ilyen kis butus dolgokat :D
- A hozzászóláshoz be kell jelentkezni
tudom, úgy 1996-7 óta linuxozom. de örülök hogy most - kivételesen - nem siránkozik senki hogy valami régi dolgot kivesznek.
“Luck Is What Happens When Preparation Meets Opportunity" - Seneca
- A hozzászóláshoz be kell jelentkezni
Majd idővel kiveszik, amit kénytelenek a timestamp kérdés miatt. Most még deprecated státuszú, de lehet használni.
Van amúgy valami előnye az ext4-el szemben?
- A hozzászóláshoz be kell jelentkezni
a notebookomon a /boot ext2 brühühühü :))
- A hozzászóláshoz be kell jelentkezni
ext4 driver kezeli, erről jó pár éve már volt cikk is asszem
- A hozzászóláshoz be kell jelentkezni
Amúgy ha ez így van, miért nem került előbb ki? Kisebb a mérete/rendszerigénye és ez beágyazott cuccoknál pont jól jött?
- A hozzászóláshoz be kell jelentkezni
Azert mert nem verziofetisisztak, hogy azonnal kivagjanak valamit. De az ext2 az ugyanaz mint az ext3 csak journaling nelkul (leegyszerusitve, mert azert van meg jo sok feature es hozzaadott ertek az ext3-ban) az ext4 meg ugyanaz mint az ext3, csak meg tobb feature-el (multiblock allocation, delayed allocation, journal checksum. fast fsck, stb stb). Szoval inkabb arrol van szo hogy tenyleg nincs szukseg az ext2-ra ha ki tudod kapcsolni az ext4-ben a nem kello feature-oket hogy ext2-nek mondja magat
Amugy is van a kernelben jo sok dolog ami vagy 30+ eves technologia es szinte senki sem hasznalja es megis benne van. Majd egyszer kiszedik ha valakit zavar. Ha meg nem akkor elfer ott a sok-sok module kozott amig van aki gondozza es utanahuzza a dolgokat benne (lehget hot pont csak neki kell egy embernek, de ez az opensource szabadsaga).
- A hozzászóláshoz be kell jelentkezni
Bevallom őszintén, hogy ezt én se értem. Szerintem csak elfelejtették kivenni, vagy bent hagyták egy időre, mert kisebb komplexitású, mint az ext4 driver, és beágyazott eszközökhöz meg retrósoknak azt hitték még jó lesz erőforrást spórolni. Most meg valaki rájött, hogy túl sokáig nem nyúlt hozzá senki az ext2 kódhoz, így nem tudják vállalni érte a felelősséget, hogy nincs benne valami súlyos regresszió, bug, sérülékenység, stb..
Mindegy, most ilyen világ van, mindent be akarnak szüntetni, 32 bites támogatást (több mainstream disztró már meg is lépte, és már az x86_64-level3 megkövetelését feszegetik), X szervert, ext2 és reiserfs drivereket, stb.. Ez lassan már ilyen általános soydev mánia, hogy mindent be kell tiltani, el kell avultatni, ami nem a legújabb, és csak a legújabb fejlesztéseket kell erőltetni, mindenkit kényszerrel átterelni Waylandre, Pipewire-re, ahogy az a systemd-vel is történt, meg mindent Rust-ban, JS-ben, stb. írni, mert a C, C++ nem menő, nem memory safe, életveszélyes, elvisz a mentő, ha megpróbálod. A Python 2.x-et, Gtk1-2-őt, Qt3-4-et is elavultatták már rég. Lassan már a natív csomagokat is elavultatják, mindennek Flatpak-nek meg Snap-nek kell lenni, meg mindennek konténerben, virtualizálva, meg sandboxolva, immutable disztróként kell futni.
Nem csak a Linux, a MS is már a Win11-gyel ezt a követ fújja, 32 bit kivezetése, TPM, secure boot, megemelt procikövetelmények (már az 1. genes Threadriper is elavult szerintük, mert megette a teljesítményét a Meltdown, Specre, stb. foltjai), Win7-8.1 támogatásának vége, a Win10 kivezetéséig csak másfél év van hátra, a FreeBSD is a közeljövőben szünteti meg a 32 bites x86 támogatást. Az Apple ebben még előrébb jár, ők elsők között szüntették meg a 32 bites x86 támogatását, most meg az Mx platform miatt nemsokára már az x86-64-et is elavultatják az elsők között, ők sose törekedtek túl hosszú legacy supportra.
Ezt, amit most tolnak, már nekem is kezd sok lenni, pedig én mindig is szívesen adoptáltam az új technológiákat, próbálok haladni a korral, már akkor UEFI bootot, meg Waylandet használtam, mikor sokan azt se tudták a ma divatos soydevek közül, hogy azt eszik vagy isszák, vagy bottal sem merték piszkálni. Ez a mai verzióhajhász, meg erőltetett elavultatási ütem már nekem is veri ki a biztosítékot, és nem csak hogy ez jobb nem lesz, de egyre durvulni fog szerintem, elkapta őket a gépszíj, nem tudnak leállni. Így aki nagyon konzervatív, legacy/retró cuccokhoz ragaszkodó, nehezen vált, nehezen szok meg újat, nem akar kidobni régit, ami még működik, mint pl. hajbi, az mostanában nagyon kösse fel a gatyát, mert iszonyat kemény menet lesz.
Még azt se lehet mondani, hogy csak az Usákiában ilyen mániákusok a nagy multik, meg csak a Linux kockák erőlködnek ennyire a technológiai fejlesztésekkel, de EU-s és UK-es viszonylatan meg a 3G-t vezetik ki. Ha csak magyarhont nézzük, akár csak egy olyan kisebb magánközösséget is, mint az nCore, akkor ott meg idéntől az SD tartalmakat vezették ki, tiltották ki, ráadásul úgy, hogy az x265/x266 720p méretre kiváltotta volna, de azt csak 4K-ban engedik. Azon csodálkozok, hogy nemrég egyáltalán a magyar analóg rádió kegyelmet kapott, azt se tudni meddig.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
- A hozzászóláshoz be kell jelentkezni
Azon csodálkozok, hogy nemrég egyáltalán a magyar analóg rádió kegyelmet kapott, azt se tudni meddig.
Ezen mit csodálkozol? DAB-ot elkaszálták, néphülyítésre meg kell még az analóg :D
- A hozzászóláshoz be kell jelentkezni
32 bites x86 procik mikor voltak utoljára? Rég kihalt a vas, ha megvan akkor sem akarsz olyat használni mai Linuxal, mert minek. Sok esetben a tesztelhetőség hiánya miatt is dobnak ki dolgokat, ha nincs gép amin tesztelni tudod akkor hülyeség bent tartani. A dead code mindig security risk.
- A hozzászóláshoz be kell jelentkezni
Meg előbb-utóbb úgyis eltörik. Én egyszer csináltam olyat, hogy egy mikrokontrolleres környezet kétféle kommunikációs üzemmódot tudott, de többnyire csak az egyiket használtuk. Nagy teher volt, hogy minden új feature-be beletegyem a másik üzemmódot is. Az elején teszteltem, javítottam, utána csak beleírtam a hozzátartozó kódot, de nem teszteltem, egy idő után elengedtem, már bele sem írtam a kódot. Nagy teher volt, lélekölő duplán implementálni dolgokat, amiről tudod, az egyik ágat szinte sohasem használják. Aztán új hardware-t terveztem, abban csak egyféle kommunikációs metódus volt az adott feladatra, így ledobtam magamról végleg, lelkiismeret-furdalás nélkül ezt a terhet. :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Nem ez a lényeg, nekem sem volt már sok éve 32 bit only procim, az utolsó értelmes gépet, amiben az volt, utoljára 2010-ben használtam (ami már akkor elavultnak számított, de azért használható volt még), meg volt egy átmeneti netbookos gépem 2016-ben, mikor ultramobilitás és anyagi megszorultság miatt kellett. A fő itt, hogy beindult mostanában mindenhol ez a féktelen, avultassunk el mindent hullám, aminek kezdem nem látni a végét.
Még az ext2 esete enyhébb is, mert itt még nem is szedik még ki, csak ellátják egy deprecated jelzővel, attól még évekig használható lesz talán, mindenesetre egy aggasztó tendencia része. A fele még eszembe se jut, pl. hogy pár éve pedzegetik, hogy sok régi Intel GPU-t is legacy csomagba tesznek át, kikerülnek az i915 driver alól. KI lett tiltva az SMB1, Network Discovery, NetBIOS, meg egy csomó mindent, és ezeknek jó része tényleg szutyok volt, de az összképet is nézni kell. A floppy drivert is próbálták már kinyírni. Annyi ilyet lehetne találni, ha összeszedném. Persze, mindig meg van indokolva, hogy régi technológia, dead code, secrisk, nem sokan használják, nem menő, kérdés, hogy ez az esetek hány százalékában jogos, és mekkora részben csak divat, fejlesztői kultúra, valóban elkerülhető, szükséges-e. Csak annyit mondok, hogy néha ezeket a szempontokat is át kéne gondolni, nem ész nélkül avultatni mindent, ami már nem tűnik menőnek, meg nem 4869-es verzió.
Mert érted, ma még csak az ext2, holnapra kitalálja, most a hasamra ütve, hogy a nálánál régebbi XFS, meg JFS is legacy kód, már az IBM sem veszi komolyan, meg IRIX hagyaték, rég nem volt commit, a karbantartó megunta a banánt, akkor mit csinálsz?
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
- A hozzászóláshoz be kell jelentkezni
A legtöbb distroban évek óta nincs benne ez a legacy ext2 driver. Az ext3 már korábban hasonló sorsra jutott. Bár ma már egyiket sem kéne használni. Az ext4 is elég elavult...
- A hozzászóláshoz be kell jelentkezni
Valóban el van avulva az az ext4, nagyon erősen. Lejárt a szavatossága, megpenészedett benne a non memory safe C kód. Használjon ZFS-t mindenki, azt is csak úgy, ha átírják a driverét Rust-ba, mert muszáj, RAM-ja meg úgyis van hozzá mindenkinek. A btrfs-t is dobjuk ki, jó pár éves, ott van helyette a bcachefs, az mindegy is, hogy még csak alfa állapotban, deadlockol, meg lassú, mint a szar, benchmarkokban a legutolsó helyen úgy kullog, hogy az előtte végző opció is többszörösen veri sebességben. A lényeg tényleg csak az, hogy a legújabbat kell hype-olni, mindenki torkán lenyomni, nincs ebben a soydeveknek (hajbazer ezeket babzsákfejlesztőnek hívja) választása.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
- A hozzászóláshoz be kell jelentkezni
A BTRFS bőven stabil manapság. Van helye az ext4-nek, de vannak csúnya gondjai is. Pl. nincs semmilyen checksumming. Nincs tömörítés. A klasszikus FSCK módszertana és működése egy borzalom, ne kelljen már megállítani a bootot és userspaceben szórakozni egy sima recoveryhez. Raid támogatás fájlrendszer szinten sem ártana.
- A hozzászóláshoz be kell jelentkezni
Raid támogatás fájlrendszer szinten sem ártana.
Az nem rétegek fölötti átnyúlás? Szerintem a RAID filerendszer alatti réteg, mindegy, milyen formátumban mit írsz a szektorba, a RAID-nek semmi köze hozzá. Akár saját kitalációjú fs is lehet.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
A zfs és a btrfs is tud ilyet, a lényeges része, hogy van checksum. Ha valahol eltörik akkor azt a lemezt berakja faultba. Ez azért elég hasznos tud lenni, a smart információ nem mindig tökéletes. Plusz lehet az eszköz jó, de pl. a kábele hibás, akkor nem fogja detektálni a vezérlő a hibát.
- A hozzászóláshoz be kell jelentkezni
Akkor inkább legyen egy RAID API erre, amit hívogat az fs, ezzel kommunikálva a RAID-del, vagy a RAID hívogassa az fs callback függvényeit. Így látnám értelmét.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Nem is állítottam, hogy nem az. De egy vérbeli soydev bele tud abba is kötni, pl. hogy a ZFS feleslegessé tette, meg 17 éves fs, ráadásul nem safe C-ben írva, nincs Rust-ban újraimplementálva, nekik ennyi is elég kifogásnak.
Csúnya gondja mindennek van. Az ext4-nél nem volt fontos a chechsumming, akkora fokú redundancia, tömörítés, de ezek szoftveresen pótolhatók más rétegekben. Ilyen hátrányokat bármi ellen fel tudsz hozni, pl. ha a teljesítményt nézzük, abban az ext4 eléggé veri a többi megoldást. Kinek mi fontos. Nyilván akinek olyan nagy redundancia, tömörítés kell, annak nem kötelező az ext4-et, vagy xyfs-t használni, de aki meg használná, annak ne avultassák ki a kezei közül, ilyen-olyan álindokra hivatkozással.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
- A hozzászóláshoz be kell jelentkezni
A fájlrendszer maga kerekítési hiba a sebességben. Nyilván egy checksumming fájlrendszer valamivel lassabb, de bőven megéri. Az ECC ram is lassabb mint a sima, mégis el kellene felejteni a francba már a sima ramot. (256GB DRAM esetén kb. heti egy bithibát okoz a háttérsugárzás, ma már egy sima laptop tart 32GB-nél. Legalábbis nálunk a cégnél ennyivel rendelik.) Amikor majd beüt a szar akkor Linus megmondta 2 éve https://arstechnica.com/gadgets/2021/01/linus-torvalds-blames-intel-for…. Hasonló probléma amúgy flash memóriák és HDD esetén is fennáll csak ritkább.
- A hozzászóláshoz be kell jelentkezni
Azért egy gyors keresést igazán megereszthettél volna, mielőtt hülyeségeket irogatsz.
A BTRFS bőven stabil manapság.
Annyira stabil, hogy már 7 éve deprecated.
Pl. nincs semmilyen checksumming.
Nincs tömörítés
De van, 2013 óta, csak a kutyának sem kellett, ezért nem mainline.
(A tömörítés egyébként is csak arra jó, hogy ne működjön a sparse és ne tudj pozícionálni nagy fájlokban (csak rohadt sok RAM és CPU erőforrás elpazarlásának árán), meg hogy feleslegesen belassítsd a fájlrendszert ha sok már eleve tömörített fájlod van. Majd azt én eldöntöm, hogy melyik fájlt akarom tömöríteni és melyiket nem!)
Raid támogatás fájlrendszer szinten sem ártana.
Szerinted. Tapasztalt üzemeltetők szerint meg sokkal jobb, ha független réteg, mert kevesebb a bug, függetlenül frissíthető stb. Az tök mindegy, hogy az FS modul vagy hogy a RAID modul jelzi-e a rendszergazdának, hogy winyót kell cserélni, kutyát sem érdekli, honnan jön a figyelmeztetés.
- A hozzászóláshoz be kell jelentkezni
Annyira stabil, hogy már 7 éve deprecated.
Az RHELben.
- A hozzászóláshoz be kell jelentkezni
Csak Redhatban. SUSE és Synology esetén default. Plusz a facebooknál is használják elég rendesen commitok alapján.
Érted egyáltalán mi az a metadata? ZFS-ben és BTRFS-ben mindenre van checksum adatra is.
Az, hogy valaki beküldött valamit a kernel mailing listre nem jelent semmit. Az tuti, hogy ilyen feature nem 300 sor lesz, ha rendesen meg van csinálva.
Szerinted. Tapasztalt üzemeltetők szerint meg sokkal jobb, ha független réteg, mert kevesebb a bug, függetlenül frissíthető stb. Az tök mindegy, hogy az FS modul vagy hogy a RAID modul jelzi-e a rendszergazdának, hogy winyót kell cserélni, kutyát sem érdekli, honnan jön a figyelmeztetés.
Majd a fejlesztők eldöntik mit használnak, az üzemeltetés csak végrehajt. A HW raid mint olyan teljesen halott. 2024 van, egy új storage server az NVME SSD-vel lesz megpakolva. A PCIe meg közvetlenül a prociba megy, ott nincs satas HW raid, meg hasonló proprietary marhaságok.
- A hozzászóláshoz be kell jelentkezni
Majd a fejlesztők eldöntik mit használnak...
Ugye fejlesztő vagy? Ők tudnak ennyi marhaságot leírni üzemeltetési dolgokról - tisztelet a kevés kivételnek.
- A hozzászóláshoz be kell jelentkezni
"Szabadság, szerelem, ext2 kell nekem" - mondta a költő, de akkor még ő is fiatalabb volt.
- A hozzászóláshoz be kell jelentkezni
Ennek oka leginkább, hogy meggyűlik a baja a Y2038 problémakör.
világos!
- A hozzászóláshoz be kell jelentkezni
Ha ezt most nem gúnyból írtad, akkor nagyon egyetértek. Ennek az Y2038-nak fel ne üljön senki, mert az ext2 driver épp úgy fordul 64 bitre is, meg lehetne rajta oldani a 64 bites időbélyegzőket. Írom ezt úgy, hogy nekem speciel ez az ext2 driver kivezetése tényleg nem fáj, mert amúgy sem használom már, nincs egy ext2-re formázott meghajtóm, partícióm sem évek óta, meg az ext4 driver is lekezeli, szóval alapból nem érdekelne, de ami nekem meredek, hogy ez is egy ilyen mondvacsinált kifogásokkal megindokolt elavultatási hullám része.
Mert oké, van helyette más, működik az is, meg lusták fenntartani a régit, akkor mondják azt, ne találják ki az Y2038-at, meg hogy ízé, nem memsafe, stb.. Vallják be, hogy ezen spórolnak most fejlesztői pénzt, időt, és akkor legalább nem beszéltek mellé. Azt is megértem, hogy ingyenes kód, a legtöbben, akik használjuk, nem fizetünk érte, ezért elvárás sem lehet, hogy valamit még x ideig, meg a végtelenségig támogassanak, csak kényelmetlen már a sok kifogás. Sőt, még azt is megértem, hogy a Linux kernel az egy dinamikusan növekvő valami, benne rengeteg legacy dolog, ha mindent benne hagynának a végtelenségig, csak nőne-nőne a mérete, és a végén kezelhetetlen lenne az egész, így kénytelenek belőle időnként ezt-azt kimetszegetni, elengedni, szanálni.
Ma még csak az ext2 driver megy a levesbe, de holnap mit találnak ki? Lassan már nem csak a soydevek avultatnak el, már őket is elavultatja az AI, majd az ír meg minden kódot, az lesz csak a jó világ, akkor már őket is visszasírjuk, meg a Rust-ot.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
- A hozzászóláshoz be kell jelentkezni
Az lehet, hogy lefordul 64 bitre, csak kérdés, a metaadat formátumban hova teszed a felső 32 bitet. Számolhatsz te akármilyen felbontással, ha a filerendszerben ott van, hogy mondjuk 8, 9, 10, 11. byte pozíció a timestamp. És akkor hogyan tovább? Ez persze akkor is igaz, ha ext4 driver piszkálja az ext2-t. Gondolom, az a megfejtés, hogy újabban formázott ext2-nek más a metaadat formátuma, s gondolom, van a filerendszernek verziószáma is épp ezért.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni