abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 06:00 | Zajímavý software

Byla vydána verze 0.56 open source platformy Home Assistant (GitHub) pro monitorování a řízení inteligentní domácnosti naprogramované v programovacím jazyce Python verze 3 a bežící také například na Raspberry Pi. Pro vyzkoušení je k dispozici demo [reddit].

Ladislav Hagara | Komentářů: 0
včera 16:55 | Nová verze

Byla vydána verze 1.0 klienta F-Droid určeného pro instalaci aplikací do Androidu ze softwarového repozitáře F-Droid (Wikipedie), alternativy k Google Play, nabízející pouze svobodný a otevřený software. Podrobnosti v přehledu změn [Hacker News].

Ladislav Hagara | Komentářů: 5
včera 00:55 | Nová verze

Po téměř 13 měsících vývoje od verze 0.11.0 byla vydána verze 0.12.0 hardwarově nenáročného desktopového prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklého sloučením projektů Razor-qt a LXDE. Přehled novinek v příspěvku na blogu.

Ladislav Hagara | Komentářů: 9
21.10. 12:33 | Zajímavý software

Článek ne Medium představuje nejnovější stabilní verzi 2.0 svobodné decentralizované mikroblogovací platformy a sociální sítě podobné Twitteru Mastodon (Wikipedie). Detailní přehled novinek na GitHubu [Hacker News].

Ladislav Hagara | Komentářů: 0
21.10. 06:00 | Komunita

V Praze na půdě Elektrotechnické fakulty ČVUT dnes probíhá RT-Summit 2017 – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt. Přednášky lze sledovat online na YouTube.

Ladislav Hagara | Komentářů: 0
20.10. 14:33 | Zajímavý projekt

Blender Animation Studio zveřejnilo první epizodu z připravovaného animovaného seriálu The Daily Dweebs o domácím mazlíčkovi jménem Dixey. Ke zhlédnutí také ve 3D s rozlišením 8K.

Ladislav Hagara | Komentářů: 0
20.10. 12:34 | Komunita

Aktualizovanou počítačovou hru Warhammer 40,000: Dawn of War III v ceně 39,99 eur běžící také na Linuxu lze o víkendu na Steamu hrát zdarma a případně ještě v pondělí koupit s 50% slevou. Do soboty 19:00 lze na Humble Bundle získat zdarma Steam klíč k počítačové hře Sid Meier's Civilization® III v ceně 4,99 eur běžící také ve Wine.

Ladislav Hagara | Komentářů: 0
20.10. 00:22 | Nasazení Linuxu

Společnost Samsung oznámila, že skrze dokovací stanici DeX a aplikaci Linux on Galaxy bude možno na Samsung Galaxy S8 a S8+ a Galaxy Note 8 provozovat Linux. Distribuce nebyly blíže upřesněny.

Phantom Alien | Komentářů: 19
19.10. 23:55 | Komunita

Společnost Purism na svém blogu oznámila, že její notebooky Librem jsou nově dodávány se zrušeným (neutralized and disabled) Intel Management Engine (ME). Aktualizací corebootu na již prodaných noteboocích lze Management Engine také zrušit. Více v podrobném článku.

Ladislav Hagara | Komentářů: 2
19.10. 21:44 | Nová verze

Organizace Apache Software Foundation (ASF) na svém blogu slaví páté výročí kancelářského balíku Apache OpenOffice jako jejího Top-Level projektu. Při této příležitosti byl vydán Apache OpenOffice 4.1.4 (AOO 4.1.4). Podrobnosti v poznámkách k vydání. Dlouhé čekání na novou verzi tak skončilo.

Ladislav Hagara | Komentářů: 8
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (9%)
 (0%)
 (0%)
 (1%)
 (76%)
 (13%)
Celkem 221 hlasů
 Komentářů: 8, poslední včera 23:02
    Rozcestník

    Jaderné noviny - 3. 10. 2007

    18. 10. 2007 | Robert Krátký | Jaderné noviny | 3512×

    Aktuální verze jádra: 2.6.23-rc9. Citáty týdne: Ingo Molnár, Andrew Morton, Ted Ts'o. Co je v realtimovém stromě. SMACK a Jediný Správný Bezpečnostní Modul.

    Obsah

    Aktuální verze jádra: 2.6.23-rc9

    link

    Aktuální předverze je (3. 10. 2007) 2.6.23-rc9, vydaná 1. října. Tato -rc verze nebyla v plánu, ale od -rc8 bylo začleněno tolik dalších oprav, takže se Linus rozhodl pro ještě jedno kolečko.

    Od vydání -rc9 přibylo do hlavního repozitáře asi dvanáct patchů.

    Aktuální verze -mm stromu je 2.6.23-rc8-mm2. Mezi nedávné změny patří opožděná podpora alokování pro ext4 a několik oprav. Andrew poznamenal, že -mm má teď skoro 32 MB patchů oproti hlavnímu stromu - předzvěst toho, co se chystá pro 2.6.24.

    Pohled dopředu: vypadá to, že vývojový cyklus 2.6.24 začne sloučením i386 a x86_64. Více informací o 2.6.24 najdete v začleňovacím plánu Andrew Mortona. Do další verze se pravděpodobně dostane práce na správě paměti, další anti-fragmentační patche, přiškrcování zápisu podle jednotlivých zařízení, LSM ne-moduly, souborové kvalifikace, další randomizace rozložení paměti, kontrolní skupiny (dříve kontejnery), jmenné prostory PID, jaderné značkovače a mnoho dalšího. Nezapomeňte, že tento dokument obsahuje pouze patche, které začlení Andrew; hlavní část kódu přijde přímo od správců subsystémů.

    Citáty týdne: Ingo Molnár, Andrew Morton, Ted Ts'o

    link

    Nesmíme ignorovat, když nám někdo řekne "něco je tu špatně", jen proto, že to on sám neumí vyhodnotit. Často je to tak, že když nakonec prohlásíme "nevíme, co se to děje", tak je to _naše_ chyba. Také se nesmíme schovávat za požadavky typu "prosím, proveďte těchto 10 jednoduchých kroků, 2× rekompilujte jádro, 10× restartujte, potrvá to jen půl dne, a pak se ozvěte, až budete mít ty podrobné debugovací údaje".

    -- Ingo Molnár

    Včera jsem s úžasem zíral na tu čekající hromadu sysfs patchů. Čtyřicet sysfs patchů a asi dvacet patchů pro ovladačové jádro a vrstvu kobject. Na to, že jde o jeden z hlavních kusů jaderné infrastruktury, která už je na místě čtyři nebo pět let, je to pořádný závar. To není dobré znamení. Teda, není to tak vážné, jako kdyby, řekněme, vývojáři plánovače procesoru neustále přepisovali ten svůj kód.

    Totiž, moment...

    Andrew Morton

    Vzhledem k bezpečnostním otázkám, které se mě týkají [my threat model], a tomu, na kolik si cením svůj čas, je život moc krátký na SELinux.

    -- Ted Ts'o

    Co je v realtimovém stromě

    link

    Už jsou to skoro tři roky od chvíle, kdy Sven-Thorsten Dietrich poslal sadu vylepšení pro realtime. Původní kód byl později nahrazen realtime preempcí od Ingo Molnára a dalších, ale i tak si zasluhuje uznání za nastartování vývoje, který pokračuje dodnes. Po třech letech byly mnohé části realtime preempce začleněny do hlavního jádra, a to včetně podpory dynamického tiku, přepsaného subsystému přerušení, mutexů, dědičnosti priorit, časovačů s vysokým rozlišením a dalších věcí. V tuto chvíli už všichni používáme jádra, která využívají kód z projektu pro podporu realtime preempce.

    Začleňování částí kódu realtime preempce však ještě není dokončeno. Pohled na oznámení k verzi 2.6.23-rc8-rt1 ukazuje, že tam čeká skoro 400 samostatných patchů. Podívejme se tedy, co ještě zbývá k začlenění.

    Jádrem této sady patchů zůstává kód realtimových mutexů. Je-li jádro nastaveno pro realtime provoz, zařídí troška (vylepšené, ale pořád strašidelné) preprocesorové magie, že se spinlocky nahradí realtimovými mutexy, které mají jiné vlastnosti. Především jsou realtimové mutexy plně preemptivní a mají dědičnost priorit. Když jsou jaderné spinlocky těmito mutexy nahrazeny, zbývá už v jádře jen málo míst, která by mohla způsobovat nekontrolovatelné latence.

    Začlenění realtime mutexů by teoreticky neměl být problém; nepoužívají se, pokud nejsou výslovně zvoleny při konfiguraci jádra, a předpokládá se, že většina uživatelů takovou konfiguraci nezvolí. Tak zásadní změna základního mechanismu vzájemného vyloučení však zákonitě vzbudí nedůvěru. Takže se o začlenění zatím ani neusilovalo a je pravděpodobné, že si do hlavního jádra nejdříve najde cestu většina ostatních částí realtime stromu.

    Kód, který by mohl dostat přednost, je patch s vláknovými rutinami pro obsluhu přerušení. Když jsou tyto rutiny ve vláknech, je možné je plánovat společně s většinou ostatních systémových aktivit a odstraňuje se další potenciální zdroj latence. Může to také vylepšit robustnost systému a zjednodušit hledání chyb v kódu přerušení. Takže tento patch by mohl být začleněn a možná i nastaven jako výchozí chování - i když vždycky zůstane určitý malý počet obsluh přerušení, které bude nutné spouštět přímo.

    V realtime stromu je i patch, který přesouvá veškeré zpracovávání softwarových přerušení do dedikovaných vláken. Další patch obsluhovacím vláknům hardwarových přerušení umožňuje zpracovat čekající softwarová přerušení a pak teprve uvolnit procesor. Tato optimalizace odstraňuje nutnost přepnutí kontextu na samostatné vlákno softwarového přerušení, aby mohla být ta přerušení doručena.

    Jedním z problémů realtime patchů byla spolupráce s mechanismem read-copy-update. Stávající kód vyžaduje, aby byla preempce vypnuta, pokud existují reference na RCU-chráněné datové struktury - ale vypnutí preempce zhatí záruky, které se realtime kód snaží poskytovat. Řešením je poněkud komplikovanější implementace preemptivního RCU.

    Do realtime stromu se dostaly patche od Nicka Piggina pro podporu bezzámkové keše stránek [lockless pagecache]. Provádějí několik nízkoúrovňových změn ve správě paměti a kódu radix stromů, aby mohly být některé operace s keší stránek prováděny bez zamykání. Tento kód už je v oběhu nějakou dobu, ale do hlavního jádra se nedostal, i když se zdá, že by mohl v mnoha situacích opravdu pomoci se škálovatelností. Další patch (od Petera Zijlstry) se zbavuje zamykání v kódu kmap(), což zlepšuje latence u systémů, které používají vysokou paměť.

    Ještě jeden patch už je dlouhou dobu mimo hlavní jádro - a asi to tak zůstane: /dev/rmem od Teda Ts'o. Toto zařízení umožňuje přímý přístup k fyzické paměti - funkce, která je vyžadována u všech systémů, které chtějí splňovat realtimové podmínky Javy. Nakolik je moudré nechávat javovské programy, aby se vrtaly ve fyzické paměti, to není téma, nad kterým by bylo nutné déle hloubat.

    Realtime strom obsahuje širokou paletu nástrojů pro odhalování částí jádra, které způsobují přílišné latence. Tento kód byl během let často využíván k zjišťování a rozebírání jaderného kódu, jenž zbytečně zatěžoval procesor. Tyto patche se zdají jako dobrý kandidát pro zařazení do jádra - zvláště vzhledem k nedávným diskuzím o přidávání více nástrojů. Prvním krokem k řešení problémů je mít možnost je měřit.

    Není mi jasné, proč realtime strom obsahuje i letitý realtime bezpečnostní modul, který byl již před lety definitivně odmítnut. Je označen jako zastaralý - ale pořád tam je.

    Strom však obsahuje i dost dalších změn. Například není možné s realtime jádry používat SLUB alokátor, takže strom obsahuje upravenou verzi slab alokátoru, který nahrazuje na přerušeních založené jednoprocesorové zamykání sadou zámků pro jednotlivé procesory. Globální files_lock bylo odstraněno ve prospěch pevně zamčených seznamů pro jednotlivé procesory. S vytvářením takových seznamů pomáhá nově přidaný typ zamčený list [locked-list]. Kód taskletů byl přepraován kvůli lepšímu využití vláken, ale patch pro odstranění taskletů tam není. Kromě toho je tam docela dost patchů specifických pro architektury, které přidávají různé funkce (např. clockevents) a opravují chyby.

    I přes všechno začleňování do hlavního jádra, které probíhalo v uplynulých dvou letech, je v realtime stromu prostě hodně kódu. Plán zní začlenit většinu z toho v ne příliš daleké budoucnosti, ale kdy by to mělo být, to není jasné. Někteří vývojáři realtime patchů navíc budou pravděpodobně dost vyrušeni spojením i386 a x86_64 v rámci vývojového cyklu 2.6.24, takže se jim možná nebude moc dařit kód začleňovat.

    SMACK a Jediný Správný Bezpečnostní Modul

    link

    Simplified Mandatory Access Control Kernel [jádro se zjednodušenou povinnou kontrolou přístupu] je bezpečnostní modul určený k zabezpečení linuxových systémů prostřednictvím přidání pravidel pro povinnou kontrolu přístupu (vizte Smack: zjednodušená kontrola přístupu). Podobně jako SELinux, i SMACK připojuje k procesům, souborům a dalším systémovým objektům štítky a implementuje pravidla popisující, jaký druh přístupu jednotlivé kombinace štítků umožňují. Na rozdíl od SELinuxu byl však SMACK navržen především pro snadnou administraci.

    Třetí verze SMACKu vedla k zajímavé diskuzi. Andrew Morton ji odstartoval:

    O bezpečnosti vím tak málo, že nemohu být ani nebezpečný. Pročetl jsem si tu srpnovou diskuzi o první verzi a vyrozuměl jsem, že byl kód přijímán kladně a sám o sobě vypadá dobře. Ale SELinux by mohl být nakonfigurován tak, aby dělal něco hodně podobného.

    Nepřipadá mi, že by to "ale" mohlo být bráno jako důvod, proč SMACK nezačleňovat. Spíš si říkám, že bychom to mohli začlenit a počkat, jestli to lidé začnou používat.

    Andrew navrhl SMACK přijmout do jádra 2.6.24. Trochu se diskutovalo o jednotlivých částech patche (některým vývojářům se líbí síťové CIPSO nálepky více, jiným méně), ale nevypadá to, že by někdo nějak zvlášť proti začlenění SMACKu protestoval. Obecně je to považováno za dobře napsaný kód, který dává z bezpečnostního hlediska smysl.

    S jedinou předvídatelnou výjimkou: kdykoliv se uvažuje o začlenění nového bezpečnostního modulu, vývojáři SELinuxu bývají proti. Tentokrát přišel s obecnou připomínkou James Morris: SMACK by byl už druhým uživatelem systému Linux security module (LSM) [linuxový bezpečnostní modul]. To by znamenalo, že už by bylo prakticky nemožné LSM z jádra odstranit. James tvrdí:

    Pokud LSM zůstane, nikdy nebude bezpečnost v jádře brána vážně. Vývojáři aplikací budou mít k dispozici několik bezpečnostních schémat a buď si nabijí ve snaze je podporovat všechna, nebo je, a to je pravděpodobnější, budou ignorovat. Vývojáři jádra pořád nebudou mít dostatek informací, aby věděli, co ty LSM háčky [hooks] v jejich kódu mají dělat, což nakonec povede k potížím se správou a potenciálním bezpečnostním problémům.

    Programátoři SELinuxu by patrně byli raději, kdyby byl SELinux jediným bezpečnostním systémem, který Linux podporuje, aby se mohlo veškeré vývojářské úsilí zaměřovat na jeho vylepšování.

    Problém je samozřejmě v tom, že ani po několika letech, kdy byl v jádře pouze SELinux, to nevypadá, že by existovaly zástupy vývojářů aplikací, kteří by na podpoře SELinuxu pracovali. Představa, že budou všechny aplikace obsahovat soubor s pravidly pro SELinux, se nenaplnila. Trochu se pokročilo s přípravou vysokoúrovňových nástrojů pro správu selinuxových pravidel a vývojáři Fedory a Red Hatu odvedli dost práce ve snaze vytvořit distribuci pro obecné použití s omezenou sadou pravidel, ale i přesto zůstává pro většinu lidí SELinux prostě moc komplikovaný. Na stroji s RHEL možná SELinux funguje rovnou po instalaci, ale jakmile admninistrátor narazí na problém, je dost pravděpodobné, že prostě SELinux vypne.

    Vývojáři SELinuxu by pravděpodobně argumentovali tím, že tyto problémy lze řešit koncentrací na jediný bezpečnostní systém. Místo vytváření konkurenčních zjednodušených systémů by bylo lepší implementovat přístupy jako AppArmor nebo SMACK v rámci SELinuxu a SELinux tím vylepšit. Tito vývojáři také tvrdí, že natahovatelné [pluggable] bezpečnostní moduly povedou (podobně jako natahovatelné plánovače) pouze k rozdělení vývojového úsilí a zabrání vytvoření opravdu univerzálního řešení:

    Opravdu chcete lidi podporovat v přípravě vlastních bezpečnostních modulů místo práce na společné bezpečnostní architektuře a jediném vyváženém řešení (což, mimochodem, nemusí znamenat SELinux, ale určitě by si z něj mohlo něco vzít)? Stejně jako u natahovatelných plánovačů, i LSM přístup zabraňuje sdílení a nutí uživatele si vybrat.

    Reakcí na to je argument, že existuje mnoho bezpečnostních prostředí a různých uživatelských potřeb; nic nenapovídá tomu, že by jediný bezpečnostní přístup mohl fungovat ve všech situacích. A i kdyby byl takový jednotný přístup možný, stejně by bylo obtížné přesvědčit vývojáře, aby se na něm shodli. Ted Ts'o k tomu napsal:

    Skutečný problém s bezpečností je to, že, jak říká Linus, neexistují žádná "definitivní čísla". Místo toho máme různé skupiny požadavků lišící se v tom, co je pro ně platný threat model --- a to se bude lišit podle prostředí, způsobu využití serverů a také podle toho, jak schopný je protivník, který se snaží do systému proniknout --- a nakolik jsou uživatelé ochotní dělat kompromisy mezi bezpečnostní a pohodlím.

    Architektura LSM byla výsledkem úplně prvního jaderného summitu, kde Linus prohlásil, že si nechce vybírat mezi různými způsoby - místo toho chtěl, aby bylo jádro schopné podporovat všechny bezpečnostní systémy. Jeho postoj se od té doby nezměnil; pořád si nevšiml, že by se schylovalo ke všeobecné shodě o bezpečnostních přístupech, takže chce, aby byl Linux v tomto ohledu i nadále pružný. Napsal k tomu:

    Takže LSM zůstane. Žádné pokud, ale, možná nebo cokoliv jiného.

    Až začnou vývojáři bezpečnostních věci předkládat rozumné argumenty a na něčem se shodnou, tak se to změní. Ale upřímně, spíše čekám, že dřív bude v pekle sněžit a prasata budou hnízdit na stromech, než k tomu dojde. Ale co, doufat můžu.

    Takže se zdá, že cesta k začlenění SMACKu do 2.6.24 je volná. Jakmile se to stane, nebylo by velké překvapení, kdyby se ozvali s žádostí o začlenění vývojáři modulů AppArmor a TOMOYO Linux; ostatně, patche TOMOYO Linux byly právě znovu poslány do LKML. Přes přání jeho vývojářů bude nakonec SELinux muset o pozornost, vývojáře, distributory a uživatele bojovat s ostatními bezpečnostními přístupy. V dohledné budoucnosti nebude mít Linux žádný Jediný Správný Bezpečnostní Modul.

           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    18.10.2007 13:45 valesek | skóre: 10
    Rozbalit Rozbalit vše Re: Jaderné noviny - 3. 10. 2007
    Haha, jsem prvni
    18.10.2007 14:53 dzony
    Rozbalit Rozbalit vše Re: Jaderné noviny - 3. 10. 2007
    gratuluju
    18.10.2007 14:58 MiK[3]Zz
    Rozbalit Rozbalit vše Re: Jaderné noviny - 3. 10. 2007
    k debilite
    20.10.2007 10:31 valesek | skóre: 10
    Rozbalit Rozbalit vše Re: Jaderné noviny - 3. 10. 2007
    zavidis a proto urazis, typickej clovek - pokud se mu neco nepodari, tak to musi svadet na jineho, STYD SE ...... :)
    vencour avatar 20.10.2007 20:02 vencour | skóre: 55 | blog: Tady je Vencourovo | Praha+západní Čechy
    Rozbalit Rozbalit vše Re: Jaderné noviny - 3. 10. 2007

    Ona ta mlčící - a neúčastnící se - většina zas nemusí být hloupá ;-)

    Ty nejhlubší objevy nečekají nutně za příští hvězdou. Jsou uvnitř nás utkány do vláken, která nás spojují, nás všechny.
    18.10.2007 15:08 outsider
    Rozbalit Rozbalit vše Re: Jaderné noviny - 3. 10. 2007
    Zajímalo by mě, jestli tu někdo zná někoho, kdo se s SELinuxem kamarádí... :-)
    18.10.2007 15:47 Jiří Veselský | skóre: 30 | blog: Jirkovo | Ostrava
    Rozbalit Rozbalit vše Re: Jaderné noviny - 3. 10. 2007

    No, kolega mi říkal, že jeho kamarád prý má kamaráda, který SELinux umí... Akorát teda nevím, co to přesně znamená. Já třeba taky umím SELinux. Vypnout. :-)

    18.10.2007 21:06 jakubh | skóre: 4
    Rozbalit Rozbalit vše Re: Jaderné noviny - 3. 10. 2007
    Nevim, jestli se kvalifikuji do kategorie "kamarad SELinuxu" ale na serverech (CentOS 4 a 5) jej nechavam zapnuty..zatim velice malo problemu..s aplikacemi, ktere jsou soucasti CentOSu zadne, s third-party je obcas potreba udelat nejaky selinux modul ale obecne to neni moc prace..(v podstate audit2why, vyhodnotit, jestli chci, aby to ta aplikace delala, pokud chci, tak audit2allow. A mam vydelano :-) )

    Mimochodem, nekde jsem cetl, ze prave SELinux byl duvodem, proc RHEL dostal nedavno nejakou vysokou bezpecnostni certifikaci..takze asi existuji lide, kteri v nem vidi prinos.

    Co se tyce notebooku tak vypinam pri instalaci...
    michich avatar 18.10.2007 21:19 michich | skóre: 51 | blog: ohrivane_parky
    Rozbalit Rozbalit vše Re: Jaderné noviny - 3. 10. 2007
    Pro mě byl SELinux jedním z hlavních důvodů, proč jsem se začal zajímat o Fedoru. Něco jsem si o něm přečetl a myslím, že jsem ho pochopil. Nevypínám ho. Pokud narazím na chybu v targeted policy, jsem schopen ji u sebe dočasně vyřešit vlastním modulem, než ji Dan Walsh opraví a vydá update. Taky si chci napsat vlastní policy pro svoje démony.
    19.10.2007 09:05 outsider
    Rozbalit Rozbalit vše Re: Jaderné noviny - 3. 10. 2007
    No prave, ja jsem si o nem taky neco precetl a nepochopil :-) Zdalo se mi to prilis slozite. Fakt, ze vznikaji veci jako SMACK me v tomto zdani jen utvrdil... Takze je fajn videt, ze jsou lidi, co to dokazou pouzivat ;-)

    O potrebnosti a uzitecnosti neceho jako SELinux se vubec nepru, tyhlety bezpecnostni udelatka jsou bezva, jen proste SELinux je takovej... na vypnuti :-)
    18.10.2007 15:57 David Jaša | skóre: 44 | blog: Dejvův blog
    Rozbalit Rozbalit vše Re: Jaderné noviny - 3. 10. 2007
    Moc pěkný díl. A že tady dlouho nebyl češtinářský koutek, tak něco přidám: :-)
    což, mimochodem nemusí znamenat SELinux
    Tady bych dal čárku i za mimochodem, nebo bych nepsal čárky vůbec.
    18.10.2007 16:12 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Jaderné noviny - 3. 10. 2007
    Programátoři SELinuxy
    SELinuxu?
    Quando omni flunkus moritati
    18.10.2007 16:16 Robert Krátký | skóre: 94 | blog: Robertův bloček
    Rozbalit Rozbalit vše Re: Jaderné noviny - 3. 10. 2007
    Dík, opraveno (i ta čárka).
    19.10.2007 09:38 cronin | skóre: 48
    Rozbalit Rozbalit vše Realtime patches
    Sú realtime patche v niečom zlé, aby bol problém s ich začlenením, resp. aby boli súčasťou defaultného správania sa? Neviem o RT veľa, ale podľa toho čo viem, jedná sa o všeobecne prospešný mechanizmus, ktorý by ako taký nemal ničomu škodiť. Vlastne sa pýtam: ak existujú RT fičúry v jadre OS, aký je dôvod chcieť ich vypnúť?
    michich avatar 19.10.2007 10:08 michich | skóre: 51 | blog: ohrivane_parky
    Rozbalit Rozbalit vše Re: Realtime patches
    RT kernel má o něco málo menší celkový výkon. Náhrada spinlocků mutexy není zadarmo.
    19.10.2007 13:36 cronin | skóre: 48
    Rozbalit Rozbalit vše Re: Realtime patches
    RT kernel má o něco málo menší celkový výkon. Náhrada spinlocků mutexy není zadarmo.
    No, "o něco málo menší celkový výkon" mi príde ako kvantitatívny rozdiel, ktorý bude za niekolko mesiacov bohato kompenzovaný nárastom výkonu hardvéru, zatiaľ čo "byť realtime" mi príde byť ako kvalitatívny rozdiel, ktorý nie je nahraditeľný ničím iným. A preto sa ďalej pýtam:

    - Čo presne zamená "o něco málo menší celkový výkon"?

    - Nakoľko významná a potrebná je fičúra "byť realtime"?
    michich avatar 19.10.2007 14:06 michich | skóre: 51 | blog: ohrivane_parky
    Rozbalit Rozbalit vše Re: Realtime patches
    Čo presne zamená "o něco málo menší celkový výkon"?
    V některých benchmarkách je pokles v jednotkách procent, v jiných více. Vím o jednom databázovem benchmarku, kde byl pokles o 30%, ale bylo to před nějakým časem a je možné, že od té doby došlo ke zlepšení.
    Nakoľko významná a potrebná je fičúra "byť realtime"?
    Jak v pro kterou aplikaci. Někde je to naprosto zbytečné a jinde nezbytné.
    19.10.2007 23:18 Ondrej 'SanTiago' Zajicek
    Rozbalit Rozbalit vše Re: Realtime patches
    > Někde je to naprosto zbytečné a jinde nezbytné.

    Navic samotny fakt, ze OS je realtime, muze byt zcela k nicemu, pokud to zkazi BIOS kvuli prilis dlouhym SMM obsluham.
    23.10.2007 18:31 ..... Izak ..... | skóre: 14
    Rozbalit Rozbalit vše Re: Realtime patches
    RT linux nenasazovat nikde, kde to neni potreba, je to dost nebezpecny nastroj, napr na server bych to nedaval nikdy.

    Ne nadarmo se RT masiny nasazuji jako jednoucelove, kde jde skutecne o pristup v realnem case jao s/ms/us ....

    Napr tim lze zpusobit DOS

    Dal ma uplatneni v hudbe, zvlaste pokud nekdo dela s MIDI
    24.10.2007 07:18 cronin | skóre: 48
    Rozbalit Rozbalit vše Re: Realtime patches
    RT linux nenasazovat nikde, kde to neni potreba, je to dost nebezpecny nastroj, napr na server bych to nedaval nikdy.
    Tak si potom lámem hlavu nad tým, ako môže byť Solaris tak úspešne nasadzovaný na serveroch.
    24.10.2007 07:21 cronin | skóre: 48
    Rozbalit Rozbalit vše Re: Realtime patches
    A nejaké argumenty? Ideálne aj s číslami.
    michich avatar 24.10.2007 08:15 michich | skóre: 51 | blog: ohrivane_parky
    Rozbalit Rozbalit vše Re: Realtime patches
    RT linux nenasazovat nikde, kde to neni potreba, je to dost nebezpecny nastroj,
    V čem podle tebe spočívá to nebezpečí?
    napr na server bych to nedaval nikdy.
    Ani kdyby jeho účelem bylo třeba doručování zpráv s minimálním a předvídatelným zpožděním?
    Napr tim lze zpusobit DOS
    Tohle bys měl nějak rozvést, jinak je to jenom FUD.
    19.10.2007 12:57 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Překlad SELinux label
    Existuje ustálený překlad pro SELinux label? Značka, štítek, nálepka?
    19.10.2007 17:47 Robert Krátký | skóre: 94 | blog: Robertův bloček
    Rozbalit Rozbalit vše Re: Překlad SELinux label
    Je pravda, že v minulém článku o SMACK jsem to překládal jako "značka", ale pak jsem usoudil, že "štítek" bude lepší - jednak je to IMO výstižnější, ale především to není tak univerzální slovo jako "značka". Proto ta změna.
    vencour avatar 20.10.2007 20:21 vencour | skóre: 55 | blog: Tady je Vencourovo | Praha+západní Čechy
    Rozbalit Rozbalit vše Re: Překlad SELinux label

    Říkáte, že je vhodné vše překládat? Mně by stačil label. Zřejmě se pohybuju častějš v anglofonním prostředí.

    Ty nejhlubší objevy nečekají nutně za příští hvězdou. Jsou uvnitř nás utkány do vláken, která nás spojují, nás všechny.

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.