SL 6.4

Megjelent.

( uid_4263 v | 2013. 03. 26., k – 09:29 )

Megnéztem, miben más mint a RHEL.

1) SL_desktop_tweaks

This adds a terminal icon to the kicker panel for GNOME.

2) SL_enable_serialconsole

This script makes all the changes necessary to send console output to both the serial port and the screen. This also creates a login prompt on the serial port and allows users to login at this prompt.

3) SL_no_colorls

Turns off "color" of ls.

Who Needs This?
People who don't like the colorized ls

4) SL_password_for_singleuser

Changes /etc/sysconfig/init to require the root password for single user mode.

Most ez komoly?

--
http://neurogadget.com/

:) Akkor nem tudod a hátterét hogy miért van SL. A CentOS-hez képest relative sok különbség van. Keress rá. De a fő különbség, hogy SL-t fizetett alkalmazott fejleszti, míg CentOS-t nem. A Cern (lásd. pl. a nagy Hadron ütköztető) és a FermiLab közös együttműködése eredményeképpen született meg azzal az igénnyel, hogy legyen 1 olyan szabad RHEL alternatíva, melyet házon belül használhatnak és nem függenek 3rd party-tól, hogy mikor és hogyan adja ki -ha ki adja- a frissítéseket.

Éppen most vetettek fel erről egy szálat a levlistán, érdemes elolvasni - benne van pl. hogy használtak RHEL licenceket is egy ideig:
http://listserv.fnal.gov/scripts/wa.exe?A2=ind1303&L=scientific-linux-u…
http://listserv.fnal.gov/scripts/wa.exe?A1=ind1303&L=scientific-linux-u…

Az, hogy publikusan elérhető a disztró, az egy kegyes döntés eredménye. Levlistán olvasható olyan, hogy a fejlesztő mond köszönetet a közösség visszajelzéseiért. Őket is segíti a közösségi teszt és visszajelzés.

Az SLC verziót használja Cern saját céges testreszabással és beállításokkal, és SL-t azért adják így ki, hogy egy alap disztrójuk legyen, amelyet a saját házon belüli igényeikre alakítanak (egyébként SLC előbb megjelenik a minor verziókkal).

Tehát a kérdés nem is az hogy mi SL létjogosultsága, hanem fordítva: létezik-e ezen kívül még egy olyan RHEL forrásból összerakott rendszer, mely 100%-ban kompatibilis TUV-val és nem közösségi fejlesztés? A válasz nem.

Egy témától kicsit független érdekes dolog: rákerestem múltkor, hogy szabad SLES alternatíva vajon miért nincs. Érdekes lehet utánaolvasni.

Szerintem:
Azért ez a fagyi könnyen vissza is nyalhat ám, gondol egyet a Cern ilyen-olyan döntésből, és azt mondja, hogy átállunk más disztróra, és akkor az SL ment a levesbe is, hiszen nagyrészt nem a community csinálja, hanem a fizetett nép, ezzel szemben pl. a Centos-t viszi a közösség tovább mindenféle gond nélkül.
Nem vagyok tisztában mekkora tömeg fejleszti, csinálja a SL-t, de én jobban bízok egy community dologban, mint egy one man show-ban.

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Persze, nem is arra gondoltam, hogy áprilisban mindent átnyomnak debianra, aztán suse-ra, aztán gentoo-ra, de egy cég életében benne van a pakliban, hogy váltanak.
És szerintem egy másik cégre támaszkodni, hogy reméljük nem váltanak, elég bátor, de lehet csak én vagyok félősebb.
És ahogy a credit listet látom, ha váltanak akkor ott vége is a disztrónak kb. :(

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Ennyiből mi a garancia arra, hogy jövőre is életben lesz még RH? Vagy Canonical? Ilyen dinamikusan fejlődő területen más dolog még ennél is jobban kihathat a jövőre mint az, hogy találnak valami újat ami jobb. Másrészt nem is találhatnak - sok ezer emberéves fejlesztésekről van szó.

Cégre szerintem kevésbé kockázatosabb támaszkodni.

Hogy a disztrónak vége lenne-e, az azért teljesen mindegy, mert nem SL a lényeg. SL az nem más mint RHEL újraépítése a forrásukból. Ez a nagyszerű benne. Tehát nem SL-ben van az igazi érték, hanem RHEL-ben. Az élteti Fedorát is.

Nagy küldönbség még köztük a repo és az abban kialakított rendszere a csomagoknak - mit szállítanak az upstream-en felül vagy helyett stb. SL-nél most külön sl-addon repó, azokat Epel-el is szinkronizálni kell (mármint a saját kialakításukon felül). Szerintem kis részét sem látjuk a problémának.

Akkor mióta utoljára néztem az SL-t, sokat változott, ez nem rossz dolog.
Ugyanezek a dolgok pl. Centosnál is vannak, közeli esetet mondok, én aktívan használom a Centos xen-c6 extra repot Xen-es virtualizációhoz, ugye azt a RHEL kiszedte ügyesen sajnos :(

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Több dolog:

Egy hosszú éves - évtizedes - felépített rendszert nem dobsz könnyen a már bejáratott és lefejlesztett hozzátartozó eszközökkel együtt. Ez nem így működik. Hosszú távra éri meg tervezni. Másrészt ha dobná, lehet jobb lenne az új amit választ és talán megérné váltani arra.

Nem 1 emberes - illetve más a fizetett 1 emberes meg a hobbi 1 emberes.

CentOS nem community fejlesztés szerintem ahogy ismerem (fix me!). Az nem úgy van hogy a közösség csak úgy tovább vinné. Múltkor (pár éve??) amikor a 6-os kiadás késett és net szerte "hőbörgött" a felhasználói közösség, senki sem vitte tovább és nem tudták csak úgy legenerálni az upstream forrásból egy release-t. Nem olyan egyszerű dolog az, hiába vannak ott a build script-ek.

Szerintem egy ilyen projektnél önmaga komplexitása a visszatartó erő arra, hogy csak úgy átugorjanak egy másik komplex rendszerre.

A sokadik meg az, hogy egyelőre 2 választása van az embernek, ha "free" szerver rendszert akar de abból is olyat, amelyet cég is fejleszt és maga a cég rakja össze (meg hosszú évig támogatott, meg karbantartja a régi ágakat a friss desktop vagy szerver alkalmazások becsorgatásával plusz sec fix-ek stb stb). SL vagy Ubuntu. Ennyi. Tehát azért nincs olyan sok választás.

Kieg.: itt az utolsó bekezdésben SL alatt persze azt értem, hogy RH fejleszti és SL-ék rakják össze, de ez a végeredmény szempontjából mindegy.

A fenti CentOS-nél meg úgy értem hogy nem community fejlesztés, hogy rendben hogy nyílt, de egy release kiadásáért nem net szerte közösségi tagok felelőssek, hanem ott is van egy adott fejlesztő brigád (fix me).

"Egy hosszú éves - évtizedes - felépített rendszert nem dobsz könnyen a már bejáratott és lefejlesztett hozzátartozó eszközökkel együtt. Ez nem így működik. Hosszú távra éri meg tervezni. Másrészt ha dobná, lehet jobb lenne az új amit választ és talán megérné váltani arra."
"Szerintem egy ilyen projektnél önmaga komplexitása a visszatartó erő arra, hogy csak úgy átugorjanak egy másik komplex rendszerre. "

-Igen józan ember így gondolkozik, de én elég sokszor tapasztaltam már pont az ellenkezőjét ennek, így ebben nem merek bízni már, hogy mi az ésszerű.

"CentOS nem community fejlesztés szerintem ahogy ismerem (fix me!). Az nem úgy van hogy a közösség csak úgy tovább vinné. Múltkor (pár éve??) amikor a 6-os kiadás késett és net szerte "hőbörgött" a felhasználói közösség, senki sem vitte tovább és nem tudták csak úgy legenerálni az upstream forrásból egy release-t. Nem olyan egyszerű dolog az, hiába vannak ott a build script-ek."

- Legjobb tudomásom szerint a srác eltűnt pont rosszkor..., a többiek meg nem álltak neki nélküle, egyébként ez a dolog részemről is egy nagy fekete pont, ciki.

"A sokadik meg az, hogy egyelőre 2 választása van az embernek, ha "free" szerver rendszert akar de abból is olyat, amelyet cég is fejleszt és maga a cég rakja össze (meg hosszú évig támogatott, meg karbantartja a régi ágakat a friss desktop vagy szerver alkalmazások becsorgatásával plusz sec fix-ek stb stb). SL vagy Ubuntu. Ennyi. Tehát azért nincs olyan sok választás.

Kieg.: itt az utolsó bekezdésben SL alatt persze azt értem, hogy RH fejleszti és SL-ék rakják össze, de ez a végeredmény szempontjából mindegy.

A fenti CentOS-nél meg úgy értem hogy nem community fejlesztés, hogy rendben hogy nyílt, de egy release kiadásáért nem net szerte közösségi tagok felelőssek, hanem ott is van egy adott fejlesztő brigád (fix me)."

- Itt az SL és a CentOS teljesen ugyanaz tudtommal (fixme), mindketten megfogják az srpm-eket, kicserélik a logokat miegymást, aztán buildelnek egyet, jónapot, ugyanazt kapod, éppen ezért ha egyik hamarabb jön mint a másik, de asap kell egy csomag, nyugodtan felnyomhatod a másikat.
A CentOS mögött milyen cég áll ha áll, sosem foglakoztatott :)

Ps.:
Nem vagyok az SL ellen, sőt használtam már sokszor SL rpm-et, de feltétlen egy cégre bízni egy másik céget, szerintem nem megnyugtatóbb mint a community-re.

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

"Itt az SL és a CentOS teljesen ugyanaz tudtommal.."

Nem az. Pont ez az érdekes. Mindkettő 100%-ban kompatibilis az upstream-mel, de egymáshoz képest mégis vannak különbségek. Múltkor multi arch lib gondokról olvastam CentOS-en, ami nem jelentkezett az embernek SL-en.

"..mindketten megfogják az srpm-eket, kicserélik a logokat miegymást, aztán buildelnek egyet, jónapot..."

Na ez az ami nagyon nem így megy :) ML-en követem és olyan rohadt sok változós a kérdés és annyi helyen el tud csúszni - hiába van forrás. Rohadt bonyolult összerakni - új release-nél változik egy csomó dolog, rendszer script-ek, szolgáltatások - hogy gondolom át kell írni egy csomó build script-et a készítéshez, nem beszélve a tesztelésről - és belegondolva még, hogy több ezer helyen változnak dolgok.. El sem tudom képzelni.

És még egy gondolat, amit érdekesnek tartok:

Ha belegondolunk, az Ubuntu az egyetlen free szerver OS, ahol az anyacég eleve free-nek gyártja és a rendszer 100% upstream. Ez nem áll SL-re és CentOS-re sem.

Talán nem véletlen a mostani cikkekben (cickó, openstack stb) az Ubuntu jelenléte / megjelenése. Ha jól belegondolunk, nincs is más (már ha feltétel a cégeknek az eredeti upstream keletkezés úgy, hogy free is legyen).

Minden flame-et kerülendő csak annyi ehhez, hogy Ubuntu-nál egy dolgot sajnálok, hogy nem invesztálnak jobban bele vagy AppArmor-ba, vagy más MAC rendszerbe (policy generáló cuccok pl. mint Suse-n meg egyéb fancy használatot és konfigot segítő megoldások, X alkalmazások sandbox-ozása stb.)

Azért aki a cernt üzemelteti, hát nagyon nagyon józan embernek kell lennie. Nem csak a feketelyukak miatt. :)

"Legjobb tudomásom szerint a srác eltűnt pont rosszkor..., a többiek meg nem álltak neki nélküle, egyébként ez a dolog részemről is egy nagy fekete pont"

Körülbelül se ez történt. Jóideje eltűnt már egy régi vezető, próbálták előszedni, de nem sikerült. A botrány inkább a támogatási pénzek miatt tört ki, amit elvben lenyúlt.

A vezetője meg - több ok miatt is - lemondott. Dag Wieersről van szó egyéként. Amíg ő volt a projekt vezetője, nagoyn jól ment a szekér. Időben jöttek a kiadások, épült a közösség, hírlevél volt stb. Mióta nincs, érezhetően megroskadt a banda. persze mostmár stabil, meg kiszámíthatóan mennek a dolgok, de akkor ez pont el6 előtt 2 nappal tapinthatóan nagy feszültséget okozott.
Nem ment amúgy messze, mert az elrepót például ő vezeti. Az meg király projekt.

Ennyit a történelemről. :)

centnél is van brigád, van vezető, vannak ütemtervek, meg minden ami kell. Ennek ellenére de, netszerte vannak szétszórva. Kicsit debianos a téma, mert 98%-ban centtel is dolgoznak a főállásukban.

Még annyit tennék hozzá, hogy én a communitybe mindig beleértem a céget is. Tehát már nem választható el, hogy eddig a közösség, innen a vállalat (RH) mert egyik a másik nélkül már ezen a vidéken nem értelmezhető. Gyakorlatilag egy nagy cég is a közösség része, annak ellenére, hogy üzeleti alapokon működik. Mert miért ne lenne?

>>: sys-admin.hu :<<

Csak annyit az utolsó részhez, hogy elválasztani egyetértek hogy nem lehet. Eleve RH is open source projekteket folyat bele a termékébe, aminek nagy része közösség.

Ezt inkább olyan szempontból érdemes szétválasztani, ha maga a for profit cég része bedől - akkor mi van?

Nem tudtam hogy Debian szerű a szervezeti felépítése Cent-nek meg amit leírtál. Ez szimpi akkor.

Én máshogy olvastam anno, lehet az a kozmetikázott verzió volt csak :))

"Még annyit tennék hozzá, hogy én a communitybe mindig beleértem a céget is. Tehát már nem választható el, hogy eddig a közösség, innen a vállalat (RH) mert egyik a másik nélkül már ezen a vidéken nem értelmezhető. Gyakorlatilag egy nagy cég is a közösség része, annak ellenére, hogy üzeleti alapokon működik. Mert miért ne lenne?"

Egyértelműen a RH az (egyik) legnagyobb közösségi játékos, ez szerintem vitathatatlan, nélkülük kérdés mi lenne a linux-al...
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

a Centos-t viszi a közösség tovább mindenféle gond nélkül.

Én úgy tudom, hogy nem tudja vinni. Zárt és szándékosan nem publikálják, hogy ne legyen millió másik ilyen disztró. Erről hosszú vita ment, és elvileg ha az ember végigolvassa a fejlesztői listát akkor össze lehet kukázni a részletekből, hogy mit is csinálnak.

Én úgy tudom, hogy a CentOS 6 azért késett, mert az egész build rendszer újraírták ami nagy meló volt. Cserébe két dolgot ígértek: egyrészt azt, hogy 6.x minor verziók már gyorsan fognak jönni (és gyorsan jönnek is), másrészt azt, hogy lesz majd idővel egy felület ahová bárki feltöltheti majd a saját src.rpm-jét és a CentOS saját build infrastruktúrán lefordul és bináris rpm lesz az eredmény. Ami binárisan kompatibilis lesz a CentOS-el.

Nem ellenőriztem, binárisan valószínűleg nem teljesen azonos a CentOS és az SL és a kettő közül valószínűleg egyik sem teljesen azonos binárisan az RHEL-el. Bár csak minimális eltérések lehetnek.

ldd a libekre és diff az eredményt, elvileg lesznek eltérések a függőségekben, amit az okoz, hogy nem azonos környezetben és függőségekkel fordítja a CentOS csapat és az SL csapat a forrást, és az is, hogy úgy tudom az RHEL nem ad ki minden libet, azaz van néhány lib ami függőségként szerepel a spec fájlokban, de forrás csomag nincs hozzá az RHEL szerverén. És ezeket a problémákat úgy tudom mindkét csapat máshogy oldja meg.

Még egy kis kiegészítés:
https://www.scientificlinux.org/documentation/faq/general1

What is Scientific Linux?

Scientific Linux is in essence, a commercial enterprise linux distribution, recompiled. What we have done is taken the source code from Enterprise (in srpm form) and recompiled them. The resulting binaries (now in rpm form) are then ours to do with as we desire as long as we follow the license from that original source code, which we are doing.

We then bundle all these binaries into a linux distribution that is as close to the commercial enterprise distribution as we can get it. The goal is to ensure that if a program runs and is certified on the commercial enterprise linux distribution, then it will run on the corresponding Scientific release.

...

Why did you pick to build Scientific Linux off of the commercial enterprise linux distribution you did? Why didn't you pick distribution X?

Speaking for Fermilab. We had several criteria when we debated about what we should make Scientific Linux out of. Some of the biggest ones were support for at least 3 years, ease of installation, security upkeep.