nem beszélve a nulla doksiról, meg az agyament dh script-ekről
Ja. Ez egy élő rendszer, ahol természetesen nincs erőforrás a dokumentáció karbantartására. (A policy-t mondjuk frissítik, de azt meg elolvasni kínszenvedés... :)) Alkalmi csomagolóként valszeg nincs annál jobb módszer, hogy levelezzük agyon a dolgot valakivel, aki napi szinten benne van. (Napi szinten én pl. egyáltalán nem szeretnék benne lenni, van elég dolgom.)
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.
Korrekt. Ez az összehasonlítás meglepetésként ért.
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.
Én foglalkoztam valamennyit SELinux-szal. NagyZ majd kijavít, én annyit tudok/akarok most mondani róla, hogy borzasztóan erős és sokoldalú eszköz, de dedikált képzés kell hozzá. Vagy tanfolyam, vagy célzott önképzés rendes dokumentációból. A CentOS/Fedora nem lep meg, de szerintem aki a RHEL-t igazán komolyan veszi és éles környezetben pénzkeresésre használja, az nem lövi ki az SELinux-ot, hanem megtanulja használni.
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)
Teljesen jogos, de az emberek nagy része önként van a facebook-on is :)
Egyébként az külön nehezíti a helyzetedet, hogy biztonsági komponenst készítettél. Akit nem érdekel a biztonság, az nem fog vele foglalkozni (ez a többség), akit pedig érdekel a biztonság, az esetleg nem lesz 100%-ban meggyőződve arró, hogy a tomld nem konfigurálja félre a tomoyo-t. (Pusztán azon az alapon, hogy egyfejlesztős projekt, feltételezhetően kicsi audittal / code review-val; ilyesmi.) Önmagában a tomoyo sem túl széles körben használt szerintem.
Pedig a "tanuló mód" önmagában biztosan jó ötlet; ha jól tudom, windows-on tűzfalak szoktak így működni.
aki nem használ párhuzamos tömörítőt, az megérdemli
Fene tudja. Ad-hoc napi használatra tök mindegy a többségnek. Rendszeres archiválásra / backup-ra elvileg van valami felettes szoftvered (vagy kellene lennie), joggal mondható, hogy tömörítsen okosan az, amivel tud.
Amúgy is, egy ideje tudatosabban kezdtem figyelni a rendszeremet, és rájöttem, hogy a párhuzamos (ki)tömörítéssel igazából kevés időt takarítok meg. A várakozás túlnyomóan a dög lassú diszkből és a rengeteg kicsi file-ból fakad. Az interaktív munkafolyamatomat mindig az ezerrel seek-elő diszk borítja fel. Mindig a diszk az, legyen akár munkahelyi laptop vagy otthoni gép, amely miatt toporzékolni és az asztalt verni van kedvem.
apt-get update && apt-get upgrade? Agybaj! Első
git checkoutvagy
git statuskernelfán? Agybaj!
du -sh /usr? Agybaj!
Itt egy példa:
# echo 3 >/proc/sys/vm/drop_caches \
&& for I in 1 2; do time -p du -sh /usr; done
4.2G /usr
real 92.11
user 0.34
sys 3.86
4.2G /usr
real 0.83
user 0.10
sys 0.47
111-szeres különbség. Ugyanez git status-ra:
$ time -p git status
# On branch master
nothing to commit (working directory clean)
real 22.57
user 0.35
sys 0.65
$ time -p git status
# On branch master
nothing to commit (working directory clean)
real 0.32
user 0.11
sys 0.11
Kb. 70-szeres különbség.
Ha eljutok odáig valamikor, hogy a gépemre költsek, akkor biztosan SSD-t fogok venni, kimagasló random write teljesítménnyel. Mivel ezek azonban ma aranyárban vannak, pár évig garantáltan nem fogok ilyesmit vásárolni :)