Marcelo Tosatti: 2.4.28-pre4

biztonsági szempontból max annyit érnek, mint egy mostani legújabb 2.6.8.1 kernel

Ehh. Nem tudom, hogy Oscon kernelei milyenek, de hogy egy 2.6.x-es kernel biztonságosabb, mint egy 2.4-es security patchekkel, azért ez elég nevetséges kijelentés...

én mondjuk nem emléxem mikor volt utoljára 2.2.x-et érintő kernel bug. én mondjuk local gondra se emléxem, de javítsatok ki.

Eh, erről inkább ne beszéljünk. Ha csak a publikus és csak a "híres" isec [www.isec.pl] által felfedezett bugokat nézzük, akkor is kapásból eszembe jut a ptrace/kmod [downloads.securityfocus.com], a d_path() és a do_mremap (VMA) bug. És ezek csak az utoljára kijött és csak a publikus bugok, a 2.2 első kiadásai szintén gázosak voltak, mint minden kernel szériánál. Az hogy nem jött ki minden bugra exploit nem jelent semmit.

Isten Veled 2.4.x ...

Jó kis kernelsorozat volt, mármint az aktív, fejlesztett idejében. Bár az indulása kissé hányattatott volt, de elég jól rendbeszedte magát. És sok új dolgot hozott, méltó volt önmagának.

Köszönöm az összes fejlesztőnek azt az áldozatos munkát, amit belefektettek... :)

Azért ne tartsunk temetési hangulatot, arról van szó ha jól értem, hogy új ficsőr már egyáltalán nem kerül bele a kernelbe, tehát csak "karbantartják".

nem túrják fel különféle újdonatúj extra ütemezőkkel, nem dobálnak ki belőle cuccosokat, itt most nem a devfs-re, hanem inkább a cryptoloop-ra gondolok.

A jelenlegi állapotában a 2.4 szerintem egész jól használható / tudom ez nagyon szubjektív / (főleg hogy SATA is van [valamennyire]), és azért tizedannyi gond nincs vele, mint mondjuk a 2.6.x szériával.

Hogy mást ne mondjak, pl. jelenleg 2.6osban viszonylag legmegfelelőbb kernel 2.6.9-rc3 - 2.6.8.1. azért bugos ám, pl. "audio cd-t írjunk" bug ha jól emléxem benne van -?

Azért hogy rc státuszú kernel legyen a legmegfelelőbb egy szériában, azért az szerintem eléggé gázos.

huh, a sok időm lenne, most leállnék flamelni. so az agyonpatchelt 2.4.18as woodys kerneled, meg a saját gányolásaid (most ezen meg ne sértődjél :)) biztonsági szempontból max annyit érnek, mint egy mostani legújabb 2.6.8.1 kernel. aki meg saját kernelt használ, az úgyis tudja, h mit csinál

a másik meg, h ha neked is lenne olyan hardvered, amit csak a 2.6 támogat (pl a gépemet se win se linux nem tudta kikapcsolni 2.6.8 előtt, 2.4essel másik gépemen nincs framebufferem), akkor te se nyomogatnád a halott hasát :)

persze, szép volt, jó volt, de már itt az idő eltemetni ;-)

De jó, hogy mindjárt temetsz amikor az apja (2.2) és még a nagyapja (2.0) is köszöni jól van :)

ehh, nem úgy értettem :)

acpi=force volt? mert attól hogy még nem ismeri az alaplapod acpi-jét még lehet hogy ki tudja kapcsolni...

so az agyonpatchelt 2.4.18as woodys kerneled, meg a saját gányolásaid (most ezen meg ne sértődjél :)) biztonsági szempontból max annyit érnek, mint egy mostani legújabb 2.6.8.1 kernel.

Legújabb 2.6.8.1-es kernellel már gond nélkül tudok audio cd-t írni ?

PaX, grsec (TPE hiányozna nagyon) van rá? / én ezeket szoktam meg /.

azt hogy most mennyit kellene gányolnom magában a disztriben ahhoz, hogy 2.6os kernelt egyáltalán normlisan (=backportolt modultámogatással, backportolt fsck-val, meg most nem vágom fejből hogy még mivel, de van még a listán) be tudjak bootolni, azt már nem is említem.

akkor van olyan modul-driverem ami csak 2.4 alatt megy, és csak 2.4.2[1-3](?) alatt, mert felette nem fordul le. akkor a /home-ről vehetem le a crypto-t, mert 2.6al nem lehet visszakódolni.

amúgy nincs elég helyem, arra sem hogy visszakódoljam.

Neked 2.6.9-rc3, nekem 2.4.18 agyonpacsálva / azóta már pontscho drivereivel, patcheivel kiegészítve /. (és majd ha lesz elég időm, akkor talán 2.4.27-el , illetve akkor majd 2.4.28al :) , de ez még nagyon messze távoli jövőnek tűnik.), másnak 2.4.27-grsec, megint másnak valami egészen más.

Van aki még most is 2.2.x-es kernelt használ, mert a HW amit használ ugyanúgy támogatja, én mondjuk nem emléxem mikor volt utoljára 2.2.x-et érintő kernel bug. én mondjuk local gondra se emléxem, de javítsatok ki.

Ez a szép a linuxban, kinek ez, kinek az jön be. van választási lehetőség.

Bizonyos kereskedelmi termékek 1ébként adnak egy darab kernelt, aztán ha neked az valami miatt nem jó, akkor mindjárt kapod, hogy az márpedig tök jó, és biztos a géped szar, de másik kernelt még kipróbálni sem tudsz.

vagy ha acpi-val az istennek se megy, akkor még mindig lehet próbálkozni APM-el is.

az is le tudja kapcsolni a gépet leállítás után.

Mondjuk a billentyűzeten levő "power gomb"-ra ilyenkor nem kapcsol le.

be kell írni, hogy /sbin/poweroff, nem elég csak 1 gombot megnyomni :).

alapból csak apmet engedélyezné, de azzal nem tudott kikapcsolni. acpi=force-szal sem. most ez utóbbival igen

> Ez a szép a linuxban, kinek ez, kinek az jön be. van választási lehetőség.

Persze, ezt nem is akarom megcáfolni :)

vmiklos te meg minek flamelsz? Ha tenyleg komolyan raneztel volna hogy APM-el miert nem kapcsol ki a geped akkor megtalaltad volna a real mode poweroffot is pl, de ezt meg sem emlitetted, ergo lovesed sincs a temarol.

BTW nalam a csodas unpatched 2.6.8.1 azonnal elpanicol amint a reiserfs rootparticiomon elfogy a hely.

realmode-power-offal sem megy. ez volt az első, amit kipróbáltam

resier-bugról küldtél bugreportot? ;)

Aszongya, köszi hogy frissíted az emlékezetemet:

1. ptrace-lmod: discovered this stupid bug independently on January 25, 2003

2. do_mremap:

Date: March 1, 2004

Version: 2.2 up to and including 2.2.25

3. d_path:

Version: up to 2.2.20

Date: March 26, 2002

bazzeg, de jó memóriád van. :))

A legfrissebb exploitod (do_mremap) 2004.03.01-ei és 2.2.25ös kernelt érinti.

A 2.2.26 megjelent (hú , most keresem, mikor is, mingyá...) :

2004-02-25 00:28 UTC

Oszt még ilyenisvan:

http://pax.grsecurity.net/pax-linux-2.2.26-200406252135.patch