Na akkor sorban :)
A mentorom csak annyit mondott, hogy vissza kell utasítania, mert nem érdekli különösebben tomld, sem Tomoyo, ellentétben aaphoto-val.
A Debian minőségével kapcsolatban csomag készítő szemszögből azt gondolom, hogy olyan sok kritériumnak meg kell felelnie, hogy ez lényegesen megnehezíti a csomag készítést (viszont ezért hordoz egy nagyobb minőséget is). Konkrétan 20 db levelet váltottam a fejlesztővel az első aaphoto csomagomnál (20 db újra generálással) ahhoz, hogy elfogadja, pedig lintian hiba mentes volt :) A Debian policy-t követni meg tényleg erőn felülinek tűnik, nem beszélve a nulla doksiról, meg az agyament dh script-ekről.
Tomld-t pedig nem is a desktop felhasználóknak szántam igazán, és nem is venném bántónak amit mondasz, ha eredetileg sem így gondolnám. Egyrészt a kritika, vagy más vélemény mindig építő szerintem ilyen vagy olyan módon (önámítás eleve felejtős imho), másrészt pont a szervereket szerettem volna megcélozni.
Ugye majdnem mindegyik fő disztrónak meg van a maga gyárilag szállított MAC rendszere (RHEL selinux / Suse apparmor / Ubuntu apparmor). Debian-nak viszont semmi. Tomoyo ráadásul gyárilag bele van fordítva a kernelbe. Tomoyo-t relatíve könnyebben érthetőnek és kezelhetőnek találtam a többihez képest, ráadásul izgalmas is a dolog szerintem, hogy a teljes Linux meg Unix jogosultsági struktúra megváltoztatására tett próbálkozás nélkül tehetnénk valamit egy már mainline-ban elérhető technológia felhasználásával. A lehetőség az utcán hevert és adott lett, mondhatjuk. Persze nagy cég, meg nálam jobban hozzáértők eleve jobban / szebben / gyorsabban / hamarabb lefejleszthetnének egy hasonló megoldást.
Mageia / Mandrivát nem említettem fent. Ahogy az Ubuntu egyik IRC channel-jén megtudtam, elvileg Tomoyo-t szállítanak gyárilag MAC megoldásként. Hoppá. Tesztelni és megnézni nem lett időm. Főként azért sem, mert egyetlen visszajelzést sem kaptam a levlistájukról és IRC-jükön sem. Ez megint meglepő volt nekem.
A Tomoyo-s arcok jó fejek voltak. Áldását adta a fő fejlesztő, hogy ha nem sűrűn ;), akkor nem zavarja a levlistájukon a saját release-emmel kapcsolatos bejelentés. Sajna innét sem jött semmi mozgás, kivéve a legeslegelső python-os pre alfa verziómról tett infóval kapcsolatban. Viszont twitter-re meg egy Japán oldalukra feltették az oldalam linkjét.
Egy érdekesség egy live disztróval kapcsolatban, ahol említik a cuccomat:
http://tails.boum.org/todo/Mandatory_Access_Control/
Szóval visszatérve az eredeti célhoz; inkább arra számítottam volna, hogy olyan szempontból kapok érdeklődést, hogy felismernék a rengeteg időt és energiát megspóroló automatizmus segítségével gyorsan összerakható policy lehetőségét. (Mivel mindenképp korlátoz, ezért a semminél policy-től függően egyre biztonságosabb). Ugye megpróbálok véletlen nevekre is megoldást adni, de nem probléma ha visszatérnek bizonyos megtagadás bejegyzések, mert az általam kialakított tomld.conf-ban egyszerűen lehet egyetlen mappa név megadásával lekezelni ezeket. Tehát bár nem szeretnék engedni az 1 click solution-ből, a config fájlal is egyszerű a megoldás - szemben azzal, mintha pl. 3 ezer sort kell taknyolni rendszer update-enként kézzel - további erőfeszítést viszont csak akkor fektetnék bele, ha official csomag lenne, vagy más módon lenne felhasználása a dolognak expert user-ek részéről.
Kis megjegyzés ide: akárkivel beszéltem, mindenki úgy kezdi RHEL meg Fedora, CentOS vonalon, hogy kilövik a selinux-ot, hosszú magyarázattal hogy miért jobb az úgy, vagy miért nem tudnak saját policy-t csinálni (most voltam Ausztriában, és egy rendszer mérnök mondta ezt, aki cluster-eket épít). Ez azért gáz.
A desktop vonalat az itt jelen lévő felhasználók miatt erőltettem csak ikonokkal meg menüvel. Egyrészt nagyon hasznosak voltak az innét kapott visszajelzések, másrészt elvégre desktop-on is használunk sok hálózatos cuccot, pl. böngészőt (talán a legfontosabb biztonsági aggodalmat képviselő rész), illetve chat meg egyebet, ami hálón kommunikál. Tehát ugyanolyan hasznos lehetne, ha hamar beállítható, és mégis szükség esetén könnyen igazítható lenne a megoldás a MAC beállítására.
Legnagyobb őszinteséggel mondom, hogy egyszerűen csak meglepett az érdektelenség. Pedig az IRC csatikon és levlistákon (számos debian és ubuntu, mandriva meg egyéb) visszatérően szórtam az infót. Sok linux-os oldalnak is küldtem egy rövid leírást, de semmi. Nem is arra számítanék, hogy konkrétan a munkám eredménye keltsen érdeklődést, hanem maga a megvalósítás módja. Vagy pedig legalább negatív kritikát vártam volna a célzott megkereséseimre.
Lehet hogy csak én láttam egy olyan dologban fantáziát, amihez tartozó technológiát elkezdtem használni, és hozzáfejlesztettem valamit a dolog megkönnyítésére. Egyebet nem t'ok elmondani :)
lbzip2-hez meg annyit, hogy aki nem használ párhuzamos tömörítőt, az megérdemli :) És tényleg nehéz a csomagolás ennyi rendszerhez (habár atya-val vitatkoztam egyszer, hogy csak a mainstream-hez kell megcsinálni), az ilyen projekthez, mint a te tömörítőd, igazán jöhetne fejlesztő vagy karbantartó, aki az upstream verziódat becsomagolja szabadidejében. Nehogy már egy ilyen fontos core cuccnak a csomagolásával az upstream-nek kelljen foglalkoznia. De erről félek hosszú flame-et lehetne nyitni.