CentOS 7 RC

AlmaLinux, CentOS, Fedora, Red Hat, Rocky Linux

CentOS 7 RC

Karanbir Singh ma bejelentette, hogy elérhetők a CentOS 7 kiadásra jelölt változatának csomagjai. A csomagokkal egy időben a live image-ek is elérhetővé váltak. A bejelentés itt olvasható.

( hanzo v | 2014. 07. 05., szo – 08:31 )

Birnam viselni, ha lenne gyari centos7 mate felulettel :) Mert fedora main repobol kicsit kuzdos feltenni..... De ha mas nem akkor marad a heggesztes. :)

--
http://szolarenergia.hu - A hálózat építést csak elkezdeni lehet, befejezni nem....

systemd után nem tökmindegy? :( - így is úgy is szar. http://ewontfix.com/14/

az igaz, hogy Gnome3 nem jó advanced használatra. G3 tényleg csak arra jó hogy az egység júzer bohóckodjon.
én cinnamon használok de egy ideje már idomítom az openboxot. amint jól fog menni a kezem alatt már dobom is a cinnamont meg az összes csicsát. úgy sem használok semmit belőle.
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/

ez azért így nem igaz.

http://ewontfix.com/15/
http://ewontfix.com/14/

egy kérdés, hogy a 6.x verzióban mi volt kényelmetlen a service-k kezelésén, valamint milyen biztonsági hiányosságai voltak?
én nem tapasztaltam nehézséget, viszont ha a systemd valamit nem fog jól csinálni akkor azon csak a fejlesztő fog tudni módosítani mert bináris alapú az egész. úgy leszünk mint MSnél hogy ez van, ezt kell szeretni, vagy majd magad túrod a kódot?
szerintem ez nem jó megközelítés.
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/

Na, a 15-ös új, azt még nem láttam. Viszont gyönyörű, hogy saját maga is leírja nem egy esetben, hogy pl. a pid fájlok takarítását a systemd végzi és (többek közt) ezért kell neki PID 1-nek lennie.

Ami az aszinkron indítás megbízhatóságát és a systemd függőségét illeti: van hivatalos guideline, hogy ha D-Bus/Socket activated service-t akarsz, akkor hogy írd meg, és ott is gyakorlatilag minden példakód úgy kezdődik, hogy #ifdef SYSTEMD. Opcionális, de valóban, fordítási időben. Ami meg a többire vonatkozik: egész pontosan a korábbi init rendszerek honnan is tudhadták, hogy a process már ténylegesen figyel is, úgyhogy indíthatóak a tőle függő service-k? Körbetaknyolt init-script? Működik az is (bár az init scriptek kiiktatási is cél volt, felesleges N+1 példányban ugyanazt a boilerplate sablont és sandboxing kódot beszúrni mindenhova).

If the daemon has to sandbox itself (e.g. chroot, namespace/container, dropping root, etc.) before it finishes initializing

Az egyik cél, hogy erre ne legyen szükség. Hogy ne kelljen N daemonban N különböző sandboxolási implementációt (és hozzá tartozó konfigurációt) készíteni, ezeket elvégzi helyette a systemd (sőt, sokkal többet is - pl. service fájlonként 1 új sorral és egy új slice unit fájllal pl. egy teljes LAMP stacket tudsz memória, swap, CPU limitelni)

én nem tapasztaltam nehézséget, viszont ha a systemd valamit nem fog jól csinálni akkor azon csak a fejlesztő fog tudni módosítani mert bináris alapú az egész.

Wut? Ha a SysVinit nem jól csinál valamit, akkor ott is a SysVinit forrásába kell belenyúlnod. Ha a service fejlesztője meg nem a számodra megfelelő service fájlt terjeszti (ugye ez kerül a /usr/lib/systemd alá), akkor simán a /etc/systemd alatt létrehozod ugyanazzal a névvel, esetleg include-olod is benne a "gyárit" és egy-egy sorral felülütöd a neked szükséges beállításokat.

Az Option 1 pedig gyönyörű: ugyanúgy mókolki kell hozzá az összes service-nek szánt futtathatóban, de legalább nem a csúnya és gonosz redhat-os interfészt használjuk, hanem amit ő talált ki (a 14-es cikkben a saját libc-je emlegetésével is hasonló érzésem volt). A Polling-os móka... sshd-ra pl. pont van gyári konfig, ami xinetd-szerűen on-demand indítja az sshd-t a 22-es portra csatlakozáskor, addig pedig a systemd figyeli a portot (és nem használ felesleges erőforrást az sshd) - btw. ez alapján az inetd-vel is gondja lenne a tagnak, mivel lehet, hogy nem indul el a szolgáltatás, amikor csatlakoznak hozzá?

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Nekem semmi bajom a systemd-vel. El vagyok vele most is mas rendszerek alatt.
Meg kell szokni, ennyi. Hogy ma a regi mukodonel maradnank mindig, akkor nem fejlodnenk sehova.
Ez a kellemelen resze, nekem a gnome3 faj, mert en desktopon is hasznalom a centost, laptop, melohely, otthon is az fut, sot szuleimnek is az megy es meg a ceges gepen is centos 6.5 fut ahonnan epp irok most :)

Hanzo

--
http://szolarenergia.hu - A hálózat építést csak elkezdeni lehet, befejezni nem....

Én is meglestem. Tapasztalatok. Ez az első CentOS 7 telepítő, amivel találkoztam és már az xfs-et használja alapértelmezetten, közelítenek a RHEL-hez. Ebben már alapból ott vannak a CentOS repok a yum/repos.d-ben, de per pill 403-at ad a repodata, mert a mirror.centos.org-on még nincs fenn a 7-es (ill. ha jól rémlik a mail listán azt írták, hogy az RC és előtte levő változatok nem lesznek updatelhetők a végleges kiadásra - de lehet rosszul emlékszem)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

> Ez az első CentOS 7 telepítő, amivel találkoztam és már az xfs-et használja alapértelmezetten, közelítenek a RHEL-hez.

Ezt a mondatot megmagyaráznád? 6-osig a REHEL sem XFS-t használt, a SciLi se, meg a CentOS se. A 7-estől REHEL-ék alapértelmezetté tették az XFS-t, nyilván az lenne a logikus, hogy a klónok is XFS-re váltsanak. Szóval én nem érzem, hogy ettől lennének közelebb az őshöz.

Annyiból kerültek közelebb az őshöz, hogy az első letölthető boot.iso-tól (afaik: x86_64-20140614) mostanáig a telepítő automatikusan ext4-et csinált, most már az automatikus partícionálás XFS-t hoz létre.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)