Friss infók a Debian "etch" kiadási idejéről

Debian

Andreas Barth a Debian release csapat részéről ma újabb részletes információkat adott a Debian kiadás előtt álló új verziójáról. A helyzetjelentésben olvashatunk a kiadás főbb céljairól, úgymint:

  • GCC 4.1 átállás
  • LSB 3.1 kompatibilitás
  • SELinux támogatás
  • mindenre kiterjedő IPv6 támogatás
  • mindenre kiterjedő LFS (nagy file) támogatás
  • új Python keretrendszer

Szintén képet kaphatunk az AMD64 port helyzetéről, de ami a legfontosabb: az "etch" kiadásának ideje nem változott a múltkori helyzetjelentés óta. Tehát jelenleg úgy fest, hogy a Debian "etch" 2006. december 4-én jelenik meg.

Bővebben a levélben.

( frank | 2006. 05. 30., k – 21:08 )

Akkor leszek 5 eves az asszonnyal. Remek kis ajandek. :-)

( Oscon | 2006. 05. 30., k – 21:44 )

Hát úgy látom az etch megjelenésével el kell temessem végleg a jól bevált 2.4-es kernelemet.

pedig annyi jó kis patch, meg miegymás volt benne (cryptoloop, i2c, sensors, grsecurity, acl, nvidia driverek, alsa)

------------------------
Nem a zsömle kicsi, a pofátok nagy...

Hm...
- cryptoloop: van gyarilag dmcrypto, letoltheto loop-aes, es meg biztos van mas is
- i2c, sensors, acl, alsa: ezekbol mind gyarilag bent van a "latest & greatest" miert jobb neked az hogy patchelgeted a 2.4-et?
- grsec: van 2.6-hoz is
- nvidia driverek: ez alatt mit ertesz?

Szoval igazabol azt ertem hogy bevalt es mukodik most nalad egy 2.4-es kernel, de ha egyszer frissitesz disztribet, akkor miert pont a kernel faj? Nem latok ra okot. (talan a cryptoloopot meg tudom erteni, de a tobbit nem, legalabbis azok kozul amit leirtal.)

az alsa, az nvidia (bináris), a lirc az modulban van.

a 2.6os grsec-el végül is megcseszhetem mert 2.6.14.6-oshoz van (a cryptoloopot talán még vissza tudnám tenni), feltehetően eléggé keményen meg kellene hegeszteni, hogy menjen a 2.6.16-ossal.pláne mivel a PaX ütközik az exec-shield-el, a grsec a LSM-el... ez egy olyan mulatság, amibe én már nem fognék bele. (a grsec-be az ip randomizációt is visszapakoltam.)

A patchelgetéssel meg annyit, hogy egyszer kellett igazán kiszenvedni még woody-d használtam akkor 2.4.26os kernellel, azóta igazából csak "simitgatni", ami viszonylag hamar megvan, azt is csak új grsec/új debian kernel esetén. (az alap a 2.4.27-es debian kernel).

minden hardvereszközöm működik a 2.4-el (AMD 64 3000+;A8N-E;MSI GeForce 6600GT PCI-E;ismeretlen gyártmányú tunerkártya '99es - most is nézem vele a meccset, mert tévém nincs -;HP656C USB;LG DVD-RAM;40 GByte Samsung;hangkártya integrált; hálókártya szintén (net eddig korlátos ADSL volt, most chellos korlátlan), bevált, stabil, nincsenek vele gondok, sec. supportja van.

nvidia SATA support nincs benne, de nincs is rá szükségem. :)

az informatikával cirka 1,5 éve végleg felhagytam, úgyhogy máshol sincs. :)

minek váltsak 2.6-osra? ehhez képest a grsec nélküli 2.6os visszalépés lenne.
ezért sajnálnám pont a kernelt leváltani...
és azért időnként az új 2.6os kernelek szépen összeakaszkodnak az nvidia driverekkel, bár lehet hogy az ATival keverem...(?)

-----------------------

Nem a zsömle kicsi, a pofátok nagy...

"az informatikával cirka 1,5 éve végleg felhagytam"
Akkor fogj egy jó könyvet, olvass, élvezd az it mentes életed és ezekkel összhangban ne sírj azon, hogy kernelt kell(ene) váltani!
__________________________________________________
Valaha nagyon gátlásos voltam, de ma már gátlástalan vagyok.

hátha egyszer visszalépést jelent ebben a speciális esetben, akkor miért ne?

mutass nekem egy security patchekkel ellátott "naprakész" 2.6 kernelt grsec 2.1.8-as peccsel (na jó annyi könnyítést adok, hogy ip randomizáció nélkül is jó lesz. :), amin mondjuk az nvnet és az nvidia modul is problémamentesen ketyeg. (ha csak naplót szemetel tele az nem gond, működjön!)

---------------
Nem a zsömle kicsi, a pofátok nagy...

nem. most már csak mezei vasuti kalauz vagyok, régebben rendszergazdaként (is) dolgoztam. :) nem, nem a NASA-nál... . :DDD

csak egyrészt sajnos javíthatatlan paranoiás vagyok (senki sem lehet tökéletes), másrészt volt már szerencsém pár puffertúlcsordulásos problémához valamelyik képkezelési polémián keresztül ha jól emléxem böngészés közben (tudom, nem kéne "ronda", ellenséges honlapokat látogatni, ahol a külső kódfuttatást a PaX csapta le, ill. hiányzik a TPE ha véletlenül külső programot indítanék el, vagy valamelyik alkalmazás tenné meg ugyanezt. valamint itt olyan extra korlátozást valósítottam meg, ami a rendszergazdától megvont mindennemű hálózati kapcsolatot legyen az kliens(socket), vagy kiszolgáló (server) típusú, és ezt csak grseczuty-vel tudtam megoldani.

harmadrészt nem egyedül használom a gépet, a többiek kattingatós típusúak, náluk méginkább fennál a veszély, hogy elindítanak valamit, amit esetleg nem kéne... (kdm, kde szép magyar, mozilla is, mplayer, kaffeine is, openoffice is úgyhogy azért elboldogulnak).

az meg megint egy más kérdés, hogy a chello számomra ismeretlen okból meg ugye szépen küldözget ide mindenféle olyan udp, meg tcp csomagokat is, úgy percenként 5-10-et, amit mondjuk ide nem kéne, olyan jó kis hálózati üzenetszórás jelleggel. ha már annyi energiát belefeccöltek tökfeleslegesen a MAC szűrésbe, ezzel is foglalkozhattak volna, hogy egy csomag csak oda menjen, ahol neki a helye van. :-)

------------------

Nem a zsömle kicsi, a pofátok nagy...