SUSE Linux 9.1 EoL

openSUSE, SUSE, SLES

A SUSE Linux biztonsági bejelentések listáján tájékoztatott tegnap Marcus Meissner arról, hogy a 9.1-es SUSE Linux (Personal és Professional) támogatása befejeződik. Ez azt jelenti, hogy 2006. június 15-től semmilyen biztonsági frissítés nem fog érkezni a nevezett disztribúciókhoz.

Ebből kifolyólag a SUSE Linux 9.1 disztró az ftp.suse.com-on levő /pub/suse/i386/9.1/ könyvtárból a /pub/suse/discontinued/ könyvtárba vándorol.

Azoknak, akik ezt a disztribúciót használják javasolt a frissítés.

A bejelentés itt.

( aperger | 2006. 05. 17., sze – 11:51 )

Sziasztok. Hát nem tudom ki mit gondol, de ...
Javítsatok ki, de ha jól emlékszem 2004-ben jelent meg a SuSE 9.1. Nem egész 2 év support után VÉGE. A legtöbb linux disztribúció sorsa is ilyen? RedHat 7.3, 9.0 is csak a Legacy projekt által supportált.
Most kijött a glibc 2.4 (SuSE 10.1, FC5 használja is), visszafelé persze nem kompatibilisek.
Mint programozó kérdezem: ha az operációs rendszer követhetelenül fejlődik, support NINCS, backward kompatibilitás NINCS, ki fog fejleszteni alá!
Egy MS VC++ 6-tal, Delphi 6-7-tel írt program gond nélkül fut Win98, Win2000, WinXP alatt. Az MS igéri a 32-bites API kompatibilitását Vista alá (pl.: a beta alatt fut a FireFox...), és menni is fog. Csak az összehasonlítás miatt említem.
Egy nagyobb rendszer kifejlesztése legalább fél év, beüzemelés 3 hónap... aztán kezdünk előlről mindent, csak azért mer ilyen a linux? Na neeeeeee....
Én kezdem feladni.....

"Nem egész 2 év support után VÉGE."

Mivel kimondottan pontosan két év a szupport idő, ezen én annyira nem csodálkozom. Ha neked ez kevés, akkor a Dapper Drake lesz a barátod, ahol desktopon 3, szerveren 5 év lesz a lifetime.

"Egy nagyobb rendszer kifejlesztése legalább fél év, beüzemelés 3 hónap... aztán kezdünk előlről mindent, csak azért mer ilyen a linux? Na neeeeeee...."

Az ne is zavarjon, hogy desktop OS-ről beszélünk.

De kérdezek tőled: szerinted az OpenBSD-nél mennyi a támogatási idő? Tippelj!

(segítek, mindig az aktuális (jelenleg a 3.9), és mindig az eggyel régebbi, (jelenleg 3.8). Fél éves kiadási ciklusok vannak. Ebből könnyen kiszámolható, hogy egy év a támogatás.)

FreeBSD-nél szintén két év.

De még sorolhatnám. Próbálj meg egy kicsit utánaolvasni a dolgoknak. Köszi!

--
trey @ gépház

Szia. Pontosam tudom, hogy desktop OS-ről beszélünk. Termelésirányító, követő, elemző rendszereket írunk és keressük az utat, hogy lehetne-e a linux világára is nyitni! A gyártosorokra kitett gépek bizony nem szerverek, amin a USER veri a billentyűzetet. Az áltatalam fejleszett Smart Storage ennek az iránynak egy próbája: adatbázis kezelés, nyomtatás, reportok. Számunkra a legideálisabb fejlesztőeszköz a Kylix lenne, mert egyben benne van minden amire szükségünk van. Ezért is használunk Delphi 7 és Delphi 2005-öt Windows alatt.

(http://www.pergersoft.hu, http://www.tfslean.com)
Azt hiszem alátámasztottad amire céloztam: nincs standard.

"A gyártosorokra kitett gépek bizony nem szerverek"

Ennek ellenére az Ubuntu Server (júniustól) verziója, a SLES és a RHEL is elmegy rajta (csomagösszeállítás és a szupport hosszának kérdése, hogy minek nevezik). Ezek pénzes rendszerek, mindegyiknek 5 év a támogatottsága. Ha fejlesztesz, ilyenre érdemes. Aki termel vele, és kell neki a hosszú szupport, az vegye meg.

Egyébként van a Red Hat-nak és a Novellnek (SLED) enterprise szintű desktop-ja. Annak kellene utánanézni.

--
trey @ gépház

Attól függ, hogy hogyan van megírva. Foglalmam sincs. BTW. mire gondolsz? Mi nem fog működni? A rendszer melyik elemétől fog függeni? Kernel? Userland program?

Ha Debian mellett Ubuntu-ra írod (javaslom, hogy arra is), akkor minimum 3 évig fog. Az a program, amit évente nem frissít a "gyártója", az nagyrészt úgyis elavul.

--
trey @ gépház

A frissítéssel egyet is értek... a http://www.pergersoft.hu oldal jelmondata is valami hasonló.
Amitől tartok:
- kernel
- glibc
- futnak-e 32 bites programok majd a 64 bites rendszer alatt?
Jelenleg csak a fejlesztőkörnyezet miatt kellenek kézi hakkelések és egy orosz programozó által készítet qt-2.3.2 patch (Unofficial bináris, van font-antialias, amit Debian alatt fordított libc 2.95-tel) miatt kellenek kompatibilitási lib-ek.
Eddig kernel és glibc a futtatásban nem okozott problémát. Csak aggódok...

Miután már egy jóideje mindenki tojik a Kylix -ra (nézd meg, hogy a Borland mennyire törődik vele, most kerestem rá a cég hivatalos weboldalán, és hát semmi érdemleges), és záros határidőn belül elkezdeném portolni az alkalmazásokat valami másra.
Arról nem is beszélve, hogy a Kylix csak egy adott verziójú Qt -vel működik együtt (asszem Qt 3.0, de javítsatok ki, ha tévedek), és azóta már azt a verziót sem fejlesztik.

Így múlik el a világ dicsősége...

--- GTK programozás C nyelven ---
http://hu.wikibooks.org/wiki/GTK%2B_programoz%C3%A1s_C_nyelven

Érdemes megnézni, hogy a Google micsoda releváns találatokat dob ki a Kylix szóra... ez is mutatja, hol tart ma ez a termék.

Mondjuk azt nem értem, hogy ha így alakult, és a Borlandnak nem a szívügye többé a Linux (és még sokminden más sem), mi a francnak nem adják ki valami nyílt forráskódú licenc alatt. Aztán majd utána kiderül, hogy a közösség mit tud vele kezdeni, és egyátalán érdemes -e bármit is kezdeni vele.

--- GTK programozás C nyelven ---
http://hu.wikibooks.org/wiki/GTK%2B_programoz%C3%A1s_C_nyelven

Hatalmas dolgok ezek, igazán kellemes dolog lehet egy closed-source dologhoz mindenféle thirdy-party dolgokat reszelgetni... olyan lehet, mint wc-papírból zoknit varrni... itt megvarrom, amott kiszakad...

--- GTK programozás C nyelven ---
http://hu.wikibooks.org/wiki/GTK%2B_programoz%C3%A1s_C_nyelven

Én úgy gondolom, hosszabb távon ez a "Kylix dolog" nem folytatható. Most még talán megoldható a portolása, de érdemes lenne emberi időben (vagyis már most) nekiállni a portolásnak, ha ilyen nagyságú projectről van szó.
Vagy újraírni az egészet.

Hosszabb távra más reális alternatívát nem igazán látok, és itt a hosszabb táv legfeljebb pár évet jelent.

Említetted, hogy van a Kylix -hoz Qt3 patch... én pedig megemlíteném, hogy a Trolltech honlapja szerint már 4.1.2 -nél járnak. Szóval, még így is egy komplett verzióval előrébb.

--- GTK programozás C nyelven ---
http://hu.wikibooks.org/wiki/GTK%2B_programoz%C3%A1s_C_nyelven

Amíg a KDE csak a Qt3-at használja... na de nem szőrözök. Bár FC4 alá már elérhetők a Qt4-es csomagok, de nem mertem feltenni, pedig van egy-két a WinXP alatt a Free Qt 4.1.2-gyel készített "Hello world" szerű adatbázisos projektem is, tesztből kéne újrafordítani linux alatt. tehát tudok róla.

De fél-egy éven belül szerintem ez már nem így lesz. Ellenben az alkalmazásod portolását nem biztos, hogy megúszod ennyi időből. Vagy neki kell "feküdni" rendesen a témának.

--- GTK programozás C nyelven ---
http://hu.wikibooks.org/wiki/GTK%2B_programoz%C3%A1s_C_nyelven

( openscope | 2006. 05. 17., sze – 16:16 )

A Novell támogatási politikája, hogy az openSUSE/SUSE Linux termékvonal támogatás 2 év (mivel évente 2 verzió jelenki meg), az eneterprise termékeké (SLES/SLED) pedig 7 év, amely kiterjed a hozzá tartozó SDK-kra is.

Ha én fejlesztenék ilyesmi alá fejlesztenék.

Valószínüleg a konkurenciáknál is hasonló a helyzet...

( Bodri v | 2006. 05. 17., sze – 17:46 )

Van freepascal és a linuxban az a jó, hogy olyan mint a lego, összerakod magadnak ami kell és nem fog elavulni (mivel fa funkcionalitása megmarad). Ez zárt rendszert meg kívülről nem kell elérhetővé tenni és akkor nem kell foltozgatni.

( Nagyapa | 2006. 05. 17., sze – 21:40 )

Biztos nem figyeltem eléggé, de ezt a "biztonsági frissítéses" dolgot nem értem.
Ha adva van egy (mondjuk) SuSE 8.2 amelyben az egyik programban biztonsági hibára lelnek és jönne hozzá "update", de nem jön, akkor forrásból lefordítom a javított kiadását a hibás programnak.
Számomra egyszerű.
Ám a zárt kódnál nincs forráskódelérés és ha nincs új verziójú program hozzá, mert bejelentik, hogy nem támogatják tovább, akkor 100% érthető a szituáció.
Vagyis ha nem jön javítás, akkor az egyedüli elérhető forrás lett elvágva.
Egy példa: a W98-hoz sosem jött ki SP tehát ha abban kellene valamit javítani, akkor az nem lenne egyszerű dolog.
Nem?