Kimondhatatlanul gyűlölöm...

A következőket:
- grub2
- systemd
- networkmanager

A lista bővülhet.

- debian féle default editor választás/nano
- debian féle apache
- debian féle pure-ftpd konfigot
- nscd és minden más dns caching cuccot

Hogy pusztulna el aki kitalálta ezeket a szarokat...

( sj | 2013. 03. 11., h – 20:19 )

meg az sfd-n hallgattam meg egy eloadast a systemd-rol, es egyfolytaban azon toprengtem, hogy egy heterogen unix(-like) kornyezetben mennyi wtf-eles johet elo, amikor az eddig rc/init scripteket (csak adott linuxon ertelmezheto) systemd ala takolni kell...

Diktatorok kezikonyve

( turul16 v | 2013. 03. 11., h – 20:36 )

systemd tapasztalatok erdekelnenek, kifejtened ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

A dbus-nak időnként már az ötletén is fennakad az ember (nem biztos, hogy message bus-ra vágysz, de ma már nincs Linux disztró nélküle).

Majdnem az összes program egyébként, amely a topikban felsorolásra került (systemd, avahi, pulseaudio, udev) Lennart Poettering-hez illetve közvetlen környezetéhez köthető. (Lásd még https://fedoraproject.org/wiki/Features/UsrMove .) Ide tartozik még (bár más szerzőtől) a NetworkManager is.

Ezek mind ugyanabba az egy (vagy kettő) irányba mutatnak: (a) tegyük a linux desktop-ot mindenek felett felhasználóbaráttá, (b) a UNIX háborúkat idéző módon ne törődjünk a hordozhatósággal, hanem a kernel stb. képességeit maximálisan kihasználva hozzunk ki jobb, versenyképesebb terméket.

A megcélzott felhasználói bázisnak és a cserzett bőrű rendszergazdák halmazának a metszete nagyjából üres. Fogak csikorgatása azért hallik, mert a fenti fejlesztési irányzat / mozgalom nem alternatívaként jön be, hanem különféle okok miatt kiszorítja az eddig bevált (bár időnként döcögő / labilis), begyakorolt eszközöket, tömegesen érvénytelenítve a rendszergazdák eddig szerzett tudását ill. az általuk megírt egyedi cuccokat.

Desktopon dbus elott sem volt ismeretlen a dolog a Unix-like vilagban:
KDE: dcop
Gnome: corba :CORBA egy olyan szabvany aminek "nincs" ket kompatibilis implementacioja, nem is beszelve a verzikrol, neha meg is harapott :)

Olyan dolgokra, amik ma termeszetesnek tunek egy modern Linux desktopon volt 100 apro megoldas, amit magadnak kellett behegeszteni.
Neha egy-egy tamogatva lett egy-egy DE altal, de ezek is szinte havonta valtoztak, nem is beszelve arrol, hogy midnen distron kicsit maskep mentek a dolgok.

Hatalmas kaosz es meleg viz ujra feltalalsi mania szinte minden retegben.
Most mintha lene valami fele normalis architektura, ahol a DE -fejleszto DE -t fejleszt.

Server oldalon ezek valoban novelik a "magszokott" fapad szintet, nem olyan egyszeru mint egy ko, olyan egyszu lett, mint egy tucat ko. (Leragott csont, de ebben a szakmaban folyamatosan tanulni kell)
De ha vissza gondolok miert es hogyan piszkaltam meg rendszert anno, akkor eleg vilagos, hogy sok esetben nem is kellene volna megpiszkalnom, vagy joval egyszerubb lett volna a dolgom.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

KDE: dcop, Gnome: corba

konkrétan mindkettőt utáltam :)

A dbus valóban lerágott csont lehet; ha nem akarjuk, hogy alkalmazások a tudtunk nélkül kommunikáljanak egymással, akkor nem biztos, hogy az üdvözítő megoldás egy message bus telepítése, majd annak ilyen-olyan leszabályozása. A default az elhatárolás, a kommunikáció pedig explicit kivétel. Szerveren ilyesminek mint "dbus" nincs mit keresni. Akinek message queueing ésvagy multicast rendszer kell, az vesz/telepít/beszabályoz egy ipari kaliberűt, ahol a biztonság (jó esetben) elsődleges szempont volt. A dbus szerverre egyszerre kevés és túl sok.

De a lenyeg az, hogy akarjuk, hogy kommunikalhassanak egymassal es akarunk veluk beszelni parancsokon keresztul is.
Eddig is volt ilyen, csak az "eldugott" domain socketek nem voltak olyan latvanyosak, mint egy service.

domain socketnek van egy olyan magikus tulajdonsaga, hogy meg tudja mondani ki van masik vegen PID -> user/group, (dbus -nak is van)

Regen a gyakori nota az volt, hogy ha valakinek volt joga beszelni a socketen (megnyitas irasra), akkor barmit mondhatott, akinek ez nem tetszett feltalalta a kereket, es megnezte ki van a vonal masik vegen es maga dontott rola, hogy mi legyen, esetleg tobb socketet csinalt kulonbozo ACL-el.

Regen az volt a gyokori szokas, hogy root -nak kell lened, ha valamit akarsz egy servicot. Most be lehet allitani mast is, akkar reszleges jogokat is.
Regen az volt a szokas, hogy kozos group kellett a serviceknek, ha egymas kozott akartak chatelni es meg a root -t is beengedni, de mast nem.

Regen egyszeru filesystem ACL -t vagy service user-t kelett elbaszni, hogy labon lod magad, most egy "egyszeru" konfig filet.

Itt rendszeresen vannak olyan megszolalasok, mi szerint jobb a sok kis processz ami egyutt mukodik (IPC), mint egy nagy valami. Ha mas nem is, de az ujra felhasznalhatosag komoly erv!

dbus-nal a biztonsag elsodleges szempot volt http://www.redhat.com/magazine/003jan05/features/dbus/#security es mindent tud amire egy node-on szukseged lehet, es szinte mindent amire tobb nodon.

Az "ipari kaliberű" -dolgoknal, a fokusz a tobb nodon es tranzakcio kezelesen van es gyakarloatban az sem ritka, hogy az osszes biztonsagi funkciot letiltjak benuk.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

De a lenyeg az, hogy akarjuk, hogy kommunikalhassanak egymassal

Aki akarja, telepítse. Én nem akarom, de muszáj telepítenem.

http://www.redhat.com/magazine/003jan05/features/dbus/#security

John Palmieri [...] is fed up with the little annoyances people must go through to make their computers useful and has declared that computers should Just Work

get the fuck off my lawn

( kmARC v | 2013. 03. 11., h – 21:31 )

Azt nem akarod kifejteni, hogy ezekkel milyen problémáid vannak? Szívesen elolvasnám, hogy pl. a grub2-vel hogyan lehet szívni - Mármint én azt sem tudom, az van-e. Feltelepítettem Ubuntu 10.04-et aztán upgrade-eltem 12.04-re, de hogy a bootloader bármibe is beleszólt volna - nem emlékszem.

Szóval gondolom valami nem standard desktop felhasználás miatt utálod ezeket a toolokat.

A grub2 kis túlzással egy önálló programozási platform. grub2 konfigot nem fogsz közvetlenül kézzel szerkeszteni (hivatalosan legalábbis nem), hanem megturkálod a konfig beállításokat (ezek jó része természetesen dokumentálatlan), majd újragenerálod a konfig file-t. Ha nincs olyan grub2 config modul, amely a számodra megfelelő konfig szakaszt böffentené ki magából, akkor így jártál. (Beleírsz kézzel, aztán a következő kernel upgrade-nél odaveszik.)

+1
Sokkal jobban tetszett a grub1 nekem. Igen, kényelmes új disztró feltevésekor csak az update-grub-ot lefuttatni. De engem nem zavart az se amikor a grub1 -be kellett beírnom kézzel amire szükség volt. Olyan érzésem van a grub2 miatt, hogy egy szükségtelenül nagy bloatware egy lényegében piszlicsári feladatra. Egészen biztos, hogy a képességeinek 90%-át nem használja ki a felhasználók 90%-a. És igen, a legtöbb funkciója nem, vagy hiányosan dokumentált. És amire van doksi, abból is az jön le nekem, hogy rém bonyolult. Tényleg, mintha valami spéci programnyelvszerűség lenne. Azaz úgy van, én se szeretem.
-------------
Blogom: http://violazoli.blogspot.com
Könyvem a VIM-ről: http://mek.oszk.hu/09600/09648/#

Aha, az tényleg fura, amikor konfigfájl-generáló konfigfájlt kell szerkeszteni, így érthető.

Viszont az, hogy kernelupgrade után felülírja a generáltba kézzel beleszerkesztett dolgokat, az úgy gondolom nem a grub2, hanem az adott disztró hibája, gondolom egy postupdate-hook a konfigfájlgenerálókonfigfájlból generál újat (amibe reményeim szerint még a hírhedt "Autogenerated-DO NOT EDIT" üzenetet is beleírja) ;-)

Remélem, a grub3-ban már a konfigfájlt generáló konfigfájlt generáló program konfigfájljának generálóprogijainak konfigfájljait kell majd szerkeszteni. :P

"Kicsi" koromban ha a linux került szóba, volt egy betűszó: KISS - Keep It Stupid Simple. Rég volt.
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods 

Get dropbox account now!

Nekem is az az érzésem, hogy az implementációban nem egészen úgy használják, ahogy kellene. Túl egyszerűsítenek olyan dolgokat, amiket nem kellene, és feleslegesen bonyolítanak olyan dolgokat, amiket egyszerűen kéne tartani.

IMHO a gui leprogramozása még nem menne a KISS-el szembe, de a grub2 megvalósítása nagyon is.
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods 

Get dropbox account now!

grub2 doksi azt irja, hogy ne szerkeszd a generalt filet, mert ha user vagy labon loheted magad, foleg ha upgradelsz.
A valosag meg az, hogy a menuentry kezzel hozza adva is menuentry. De ha valami meghivja a konf gent ...

Mostansag (evtizede) divik, hogy szetkapjak a konfigokat "simple" funkcionalis reszekre.
Mostansag divik, hogy a mindenfele kozponti management rendszer templateket hasznal es rakja ossze a konfigokat..
Ha ilyen apro fileokbol nezzuk ossze veg-konfigot, azt jeletni, hogy egy file letorlese, vagy bemasolasa a tavoli gepen azt valtoztatja, meg amit szeretnenk.

Hogy kinek mi a simple..

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

/etc/grub.d/40_custom
Erről kell másolatot csinálni akármilyen sorszámmal és névvel. Mi ezen a bonyolult? Ki mit akart beállítani amihez ez + default config nem volt elegendő?

Szerk:
Én még háttérképet is beraktam a grub2-be, úgy hogy kernel vagy grub vagy akármi frissítés után is megmarad. Igaz ehhez már értelmezni kellett egy bash szkriptet.

( uid_2030 | 2013. 03. 11., h – 21:44 )

A nagy kedvencemet, a PulseAudiot kifelejtetted...

> BERUS
Motor: Kubuntu 12.04

"Mit javasolnal helyette"

Natív alsa-t.

A miértről már volt szó sokszor, kezdjük talán azzal, hogy mikor felkerült függőségként a gépemre a mai napig nem tudom, hogy mi indítota el indításkor a processzét (akkor még initscripts, rc.d-ben nem volt, se rc.confban, se X-es autoindítókban), és alig bírtam kilőni a configjában azt is, hogy ha már egyszer killelem (nem véletlen, hisz kinyírta a Skype-ot, ami előtte natív alsa-val ment), ne szülje újra magát.

Meg annak idején a Pulseaudionak volt köszönhető, hogy elterjedt az a legenda, hogy Linuxon csak egy alkalmazás használhatja a hangot, és az alsa dmixer hack sem segített rajta.

( Kobor | 2013. 03. 11., h – 22:44 )

Plusz mindent aminek XML-be van a config file-ja.

- fsck.ext3: Elcsúszott egy helyen a rendszeróra, indításkor pánikolt a gép hogy a jövőben változtatták a fájlrendszert, majd gyorsan ráeresztett egy fsck-t. A végeredmény testdisk lett. Azóta próbáltam manuálisan triggerelni a hibát, sikertelenül.

- virt-manager: Kedvenc funkcióm: gépkonfiguráláskor ha az adott oldalon nem accept-álom a beállításokat akkor eldobja. Szívtam már vele eleget.

- upstart: Sikerült majdnem egy órán keresztül szivatnom magamat, majd kiderült hogy ebbe a lassan 5 éves bugba futottam bele: https://bugs.launchpad.net/upstart/+bug/252996
Továbbá bosszant, hogy hiába módosítom pl. a mysql init scriptjét, hogy csak a networking után induljon el, falra hányt borsó: ha nincs hálózat, akkor is megpróbálja elindítani a mysql-t, az meg bepánikol hogy nincs ip amin figyelni tudna. Ugyanez a Samba és Postgresql esetén is fennáll. Mondjuk lehet, hogy csak az OpenRC beszél belőlem és csak bénázok valamit.

( poliverzum | 2013. 03. 12., k – 05:15 )

automount

(nem tudom, ennek mennyiben van köze a hotplughoz, de...) érdekes, ha az ubimat Unity felülettel használom, akkor ha bedugok valami USB 2.0 kütyüt, magától felcsatolja valami könyvtárba a /media alá, a könyvtárat ő maga hozza létre azzal a névvel, ami a fájlrendszer labelje. Oké. Ha azonban XFCE felülettel indítom tökugyanazt a rendszert ugyanazon a gépen, ezt nem csinálja meg. Az asztalon megjelenik az eszköz ikonja, de nem csatolja.

Nem baj hogy nem csatolja, mert amúgyis elvből ellenzem az automountot, de azért érdekes ez, mert ennek szerintem nem szabadna attól függnie, milyen az ablakkezelőm épp. Mi köze van annak egy efféle "szolgáltatáshoz"?!
-------------
Blogom: http://violazoli.blogspot.com
Könyvem a VIM-ről: http://mek.oszk.hu/09600/09648/#

Csak az XFCE-hez egy megjegyzés. Keresd ki a Fájlkezelő beállításait, és ott keresd ki a kötetkezelőt. Engedélyezd, és állítsd be, ahogy jól esik.

(Mellesleg én is azt tartanám logikusnak, hogy ha van ilyen, az nem függ a DE-dől - nem a WM-től függ amúgy, hanem a DE-től. De az pl. felvetné azt a problémát, hogy milyen fájlkezelőt indítson el? Kinek a nevében? Mi van, ha két-három X van a konzolon - más-és-más userrel, akkor kit válasszunk ki. Szóval ezért oldja meg inkább a DE saját maga.).

( Snitt v | 2013. 03. 12., k – 08:56 )

+ bluetooth stack
+ openct/sc/pcscd
+ gnupg
+ dia
+ linux acpi

(onkritikabol ki kellett torolnom a megjegyzeseket)

Gnupg, dia miért?

Re linux acpi, itt az igazi ludas az a csapat, amelyik a rémületesen bonyolult specifikációt összerakta (5.0: HP, Intel, Microsoft, Phoenix, Toshiba). Parse-olásra az ACPICA referencia-implementáció Linux portját használják, tehát nem a saját kódjukat. (A kinyert adatok értelmezése persze már Linux-specifikus.) A gáz sajnos a szokásos: a BIOS fejlesztők nem az ACPI szabvány ellenében fejlesztenek, hanem az éppen aktuális Windows ACPI parsere alá. Ami azon elmegy, az OK, a spec meg pusztuljon. (Valahol megértem őket, mert a spec agyzsibbasztó. Továbbá abban "csak" az általános dolgok vannak, mind az Intel-nek, mind az AMD-nek vannak saját táblái (külön spec).)

Természetesen olyan is van, hogy az ACPI bonyolultsága csak az x86 architektúra elbonyolítottságát tükrözi. Az egyik különösen fájdalmas pont az interrupt routing. http://www.openwatcom.org/index.php/PCI_Interrupt_Routing

( Gyuszk v | 2013. 03. 13., sze – 12:25 )

Normál esetben ezekkel nem kell foglalkozni, nem? Vagy disztribúciót kalapálsz? Esetleg naív vagyok? (használok Linux desktopokat munkára)

--
http://neurogadget.com/