A Grsecurity felfüggeszti a stable patchek publikus terjesztését

Miért lenne? A GPL semmit nem mond arról, hogy kötelező mindent nagy nyilvánosság számára elérhetővé tenni. Mint ahogy te is nyugodtan meghegesztheted magadnak otthon, és nem kell kirakni (vagy, hogy ne legyen hülye a példa, mint ahogy a google is saját magának tartott karban kernelt belső használatra, és sose adta ki).

Amit mond, az az, hogy ha valakinek adsz gples progit, ott kell legyen a forrás. Ők bináris kernelt sose adtak tudtommal, csak kernel patchet, azt meg nem kötelező nyilvánosságra hozni, ha ők csak a szponzoraiknak akarják odaadni, have fun. (A bináris kernelt sem kellene egyébként, csak ha adják, kell mellé a forrást is mellékelni. Még a patchet sem kéne jó eséllyel, lásd redhat, egy nagy targéza a módosított srcvel jó.) Azt persze nem tilthatják meg a szponzoraiknak, hogy ezeket tovább terjesszék, ha akarják, hiszen gpl, de a ha akarják hangsúlyos, és van tippem, hogy nem akarják :)

Ha a patch bekerül egy szponzor rendszerébe, amit nem ő használ, hanem értékesít. Akkor az akinek értékesítette a GPL miatt kérheti a forráskódját.

Szerintem bármikot jelentkezhetsz támogatónak! :)

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Akkor ez azt jelenti, hogy ha mondjuk én 1 hónap múlva úgy döntenék, hogy az otthoni akármi disztribúciót futtató gépemre jó lenne grsecurity, akkor nem lesz elérhető verzió?

Én kb. 2002 (?) óta használok grsec-et.

Ha stabilabb, megbízhatóbb kernelre akartál grsec-et, régen is úgy ment, hogy egy kinéztél egy kernelverziót (praktikusan egy longterm fára) az utolsó public. grsec test verziót feltetted, lepróbáltad, működött, aztán a vanilla/distro kernel módosításait nyomtad fel a kész grsec-es kernelforrásra.

Ritkán fordult elő, hogy problémák voltak, ha voltak is , általában kezelhető volt a dolog.

A longterm kernel pont azért jó, mert nem basztatják annyira, mint a vanillát, nem kezdenek rendmániás őrültek függvényátnevezésekbe, kódtisztításokba általáluk deprecated-nek vélt részeket illetően. Amik miatt a külső kernelpatchek alkalmazása finoman szólva is körülményes.

Egyszerű ember számára a változások a longtermben könnyebben követhetőek..

A módszer hátránya, hogy a grsec verzió kötött, tehát azt nem fogod emelni. Pl. jelenleg 3.14.y-ra van 3.1.-es grsec, ha kiadnak egy 3.2-est az újdonságok már kimaradnak. Illetve ha átállnak a fejlesztők másik kernelre, akkor neked marad az uccsó teszt verzió kiindulási alapként a választott longterm kernelhez.

A módszer másik mellékhatása / hogy előny vagy hátrány ezt nehéz eldönteni / ritkábban akad majd össze a grsec a distro kernelek longterm fáival. (pl. debian)

A grsec stabil fába ugyanis nem csak grsec ficsőrök, hanem normál kernel hibajavítások is bekerülnek a jelenlegi rendszerben.

Ugyanezen hibákat a distrok is javítják / pár nap, vagy pár hét késéssel ;-) / a saját kernelükben.
De a két javítási módszer időnként jelentősebb mértékben eltér, ami miatt vagy distro kernel, vagy grsec stabil fa volt a választás a jelenlegi rendszerben.

Ezeket a duplikációkat most könnyebb lesz elkerülni.
A grsec teszt verziókba ezeket a gyorsjavításokat ezentúl nyilván nem teszik bele, ha pl. 3 hét múlva úgyis kernel verziót emelnek.

Nem fognak ezzel vesződni, régen is csak rendkívüli esetben tették.

ráadásul az a grsecurity változat is jobban teszt, próbálkozások ez-az is van benne.

Otthoni használatra a ficsőrök amiket használni fogsz, vagy használnál, azért nem tegnap kerültek a grsec-be. ;-)

Maradjunk annyiban, hogy ezek a grsec test verziók azért nem annyira félelmetesek.
A test valójában inkább szól az új kernel verziónak, mint a grsec-nek. ;-))

off: Az egyik kedvencem még a régi időkből az, mikor valamelyik grsec verzióban az UDEREF és az intel dri összeakadt / az intel dri-t akkor éppen nem tudom hányadszorra írták újra exa/uxa -val volt valami cirkusz /,
korábbi verzióval jó volt. De az adott kernelverzióval nem indult az X, ha az uderef ment.

Aztán jött még ki jónéhány intel dri javítás a kernelbe, közte volt null.deref-es is ;-)), aztán egyszercsak megint jó lett. És ezek úgynevezett "stable" kernelek voltak.

Szóval a test nem feltétlen a grsec-nek szól. ;-)

A virtualizáció kérdése az már komolyabb, ott esetleg lehetnek hiányzó funkciók, bár egy ideje már benne van az is. kvm-el szvsz nem lesz gond. virtualbox, vmware már neccesebb lehet, fene tudja.

---------

Én nem lennék meglepve, ha megint lennének a neten barkácsverziók, barkácsbackportok egy idő után grsec-re, mint pl. ez volt annak idején, amikor nem volt stable grsec forrásfa:

http://kernelsec.cr0.org/.

Én valószínűleg ezt az utat választom majd a bttv , lirc miatt amúgy is backportolnom kell saját használatra.

-----------

Én a 3.14-y-t a jessie ciklusa végéig használom a longterm fa változásait pakolgatom be a mostani forrásfába, talán nem lesznek olyan horderejű változások - ált. nem szoktak longterm fában - ami miatt összeakad a grsec-el.
Nekem szerintem jó lesz. régen is kb. így ment.

Közbe begyűjtögetem a test verziókat, ha lesz changelog azokat is, aztán vagy visszaáll a stable support egy idő után - van bő 1,5 év ;-)) jessie végéig - vagy valaki elunja és kernelsec.* módjára lesz barkácsbackport,
vagy ha egyik sem, megnézem jessie után milyen longterm fa lesz, aztán elkezdem azt követni virtuális gépben, mire a jessie lejár, addigra legyen kész utódlás.

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.