Po vlastních microSD kartách nabízí nově Raspberry Pi také vlastní NVMe SSD disky. Samostatně i v sadách s M.2 HAT+.
Byla zveřejněna (𝕏) Zpráva o činnosti Digitální a informační agentury (DIA) za rok 2023 (pdf). Začíná slovy ředitele: "Vznik Digitální a informační agentury (DIA) je v posledních letech možná jedním z nejvýznamnějších kroků, který dodá potřebný impuls digitalizaci státní správy."
Vývojáři AlmaLinuxu představili AlmaLinux OS Kitten 10, tj. vývojovou verzi AlmaLinux OS 10 vycházejícího z CentOS Stream 10. Přehled novinek v poznámkách k vydání. Proč Kitten? Verze AlmaLinux OS jsou pojmenované podle kočkovitých šelem. Z kotěte vyroste další kočka.
Kryptografická knihovna OpenSSL byla vydána v nové verzi 3.4. Přehled změn na GitHubu.
Bylo objeveno nové největší prvočíslo. Jedná se o Mersennovo prvočíslo známé též jako M136279841. To znamená, že v binární formě je prvočíslo tvořeno 136 279 841 jedničkami. Objeveno bylo v rámci distribuovaného výpočetních projektu GIMPS (Great Internet Mersenne Prime Search). Zajímavostí je, že na rozdíl od předchozích takto objevených prvočísel nebylo objeveno pomocí CPU, ale na grafické kartě NVIDIA A100 s pomocí programu Gpuowl.
Protokol MQTT (Wikipedie) dnes slaví 25 let (Mastodon, 𝕏). První publikovaná specifikace je z 22. října 1999.
Mobilní operační systém /e/OS (Wikipedie) založený na Androidu / LineageOS, ale bez aplikací a služeb od Googlu, byl vydán ve verzi 2.4. Přehled novinek na GitLabu. Z novinek lze zmínit podporu telefonu Google Pixel 7. Na stránkách Murena lze koupit Murena Pixel 7.
Připojte se ve středu 30. 10. 2024 od 10:00 do 12:00 na náš webinář "Řízení přístupu do PostgreSQL prostřednictvím externího autentizačního providera" (registrace zdarma) a naučte se, jak nastavit ověřování pomocí GSSAPI pro bezpečný přístup k databázím (Microsoft Active Directory nebo FreeIPA). Záznam předchozího webináře "Co je nového v PostgreSQL 17" můžete zhlédnout zde.
… více »Byla vydána nová verze 0.55 open source počítačové hry Unvanquished (Wikipedie), forku počítačové hry Tremulous. Instalovat ji lze také z Flathubu.
Dle plánu bylo dnes vydáno Factorio 2.0 a Factorio: Space Age, tj. aktualizace 2.0 počítačové hry Factorio (Wikipedie) oficiálně běžící také na Linuxu a velké vesmírní rozšíření Factorio: Space Age.
Během diskuse v rámci první konference LinuxCon 2009 Linus Torvalds prohlásil, že linuxové jádro neustále až příliš roste ("the kernel is huge and bloated"). "Někdy mi přijde trochu smutné, že nemáme to štíhlé, malé, hyper-účelné jádro, které jsem si představoval před 15 lety..." Další info o Kernel Panelu také na Linux.com.
Tiskni
Sdílej:
Že by měl býval A. Tanenbaum pravdu?
Samozřejmě, že měl pravdu.
Linus si myslí, že je odborník na všechno. Je „odborník“ na C++, stejně tak jako na řadu jiných věcí.
To, že koncepce monolitického jádra se časem rozpadne je jasné. Problém je, že jakákoli sw chyba v kernelu a jeho kritické části způsobé problémy v systému. V době, odkud konzervativní Linus čerpal byly kernely velmi malé a tento problém se neprojevoval.
Vycházelo se z premisy, že bude dokonale odladěný kernel, který bude imunní vůči chybám v user aplikacích.
Ale pokud už má kernel desítky milióny řádek, je naprosto utopické dále jet v tezi, že kernel bude dokonale odladěný, bezchybný kus kódu. Kernel musí přijmout koncepci, že i v kernelu se může leccos zhroutit a nemělo by to poškodit systém. V čistě monolitickém jádru ale smolenka. Takže se časem klidně může stát, že Windows bude spolehlivější systém (řekněme ve výhledu 5–10 let), než Linux právě proto, že nebude možné zaručit bezchybnost kernelového jádra (takový velký projekt zkrátka nejde bezchybně odladit, je to utopie).
Problém je, že Linus opravdu neudělal nic jiného, než přebral starou koncepci, která byla vhodná na tehdejší maličké kernely.
Právě nekoncepčnost je obrovská nevýhoda neřízených projektů. Evoluce daná tím kdo si co prosadí je sice dobrá, ale neumožňuje prosadit dobré koncepty, ale spíše snadné koncepty. Nebo koncepty, kde je rychleji vidět výsledek. Dost to eliminuje zkušené lidi v delším horizontu. A ono to jednou bude znát.
22.9.2009 14:06
Voty | skóre: 12
| blog: gemini
Možná máš pravdu, ale na druhou stranu, alespoň je tu teď něco funkčního, což se obávám, že by nemuselo být, kdyby se již od počátku snažil postavit mikrojádro, aneb Worse is Better v praxi :)
Já se naopak obávám, že linux kernel se stane obrovskou zásobárnou ztracené práce tisíců lidí.
Že jde postavit mikrojádro, snadno a úspěšně, dokazuje x projektů, které mikrojádry jsou. Například QNX, nebo Plan9, nebo Minix od Tanenbauma. Jediná nevýhoda mikrojádra je, že jej musí navrhnout zkušený člověk. Nelze jej odpracovat hrubou silou (jako linux kernel), ale je třeba převahu mozku nad odpracovanými programovacími hodinami. Na druhé straně je mikrokernel velmi malý (řádově desítky KB) a ve zbytku systému už nechť si působí ta hrubá síla.
Myslím, a vzpomeňte si na mě, že za 10 let budou lidi na Linux vzpomínat jako na no tak co s ním. Proč:
1) Jádro se rozroste a bude značně nespolehlivé. Prostě obrovskou kupu miliónů řádek ve stabilitě neudržíte. Dnes to funguje, protože nad tím spousta dosti kvalitních lidí tráví neuvěřitelné množství člověkoroků. A navíc jádro stále roste. (Každý dobrý javista, či vedoucí velkého projektu ví, co znamená udržovatelnost.)
2) Jádro má obrovské právní omezení dané GPL licencí. Řada lidí ani firem nebude chtít do toho dávat prostředky, protože licence je omezující. Možná se dočkáme ještě velké slávy, kdy BSD bude na výsluní díky právním omezením Linuxu. Tehdy se zúročí všechny ty akce proti výrobcům hw, proti binárnímu API v kernelu pro drivery a proti jakémukoli neGPL kódu tím, že od Linuxu dají ruce pryč jako od právně nepoužitelného projektu.
že by prasklá křišťálová koule?
Nikoli, pouze dvacetileté zkušenosti ohledně vývoje sw.
Stejně tak jsem v období největšího boomu OS/2 předvídal, že tento systém se neuchytí.
Já jen říkám, vzpomeňte si na mě.
Já se umím i vsadit. Upřímně, prohlašuji tady hodně věcí a zatím jsem se výrazněji nesekl.
Například o Windows, nebo BSD jsem nikdy za 20 let neprohlásil, že zaniknou.
Prohlásil jsem to jen o OS/2 o BeOSu (což bylo jasné každému) a Linuxu.
Umím být i konkrétní, největšího úspěchu dosáhne Linux kolem roku 2015. To bude zenit. Pak bude doba „za zenitem“.
Stejně tak prohlašuji, že C a C++ přežijí řadu programovacích jazyků s „moderní“ koncepcí kvůli jednoduchému faktu: Mají standard a ctí zpětnou kompatibilitu. Navíc jejich roli nemůže žádný jiný existující jazyk plnohodnotně nahradit.
Stejně tak přežije Java, Fortran, nepřežije Python, Perl se stane živoucí zombie, která sice nevyhyne, ale prostě bude.
Hlavním problémem Linuxu není ani fakt, že by mohl mít problémy technické. Hlavním problémem Linuxu je, že se vyvíjí davově a miliónový dav má obrovskou setrvačnost a velmi malou schopnost poučit se z chyb jinak, než totální katastrofou.
22.9.2009 15:44
Amarok | skóre: 33
| blog: blogoblog
Zjevně nevíte o zálibě pana Ponkráce v astrologii 
Já jsem ale teď nepoužil ani zlomeček astrologie.
Zahynutí Pythonu vysvětluji tak, že Python má vysoké nároky na údržbu vlastního jazyka. Každá další verze Pythonu chce minimálně znovu zkompilovat všechny knihovny, má jiný byte kód. Autor Pythonu se vysmívá zpětné kompatibilitě jako buržoaznímu přežitku. Python je překopáván často nikoli z důvodů praktičnosti, ale protože se to tak autorovi líbí. Například autorovi se nelíbí LISP, tak začal útočit na funkcionální části Pythonu a snažil se jej vystřílet ven.
Ovšem každá změna syntaxe programovacího jazyka nese sebou snížení spolehlivosti již hotových zdrojových kódů, případně další náklady na jejich revizi a přepsání.
Ovšem hlavní důvod, proč si to myslím je jednoduchý. Python změnu syntaxe udělal v nejblbější možnou dobu. Python byl dlouho jazyk v ústraní (je to jazyk asi 17 let starý) a poslední dobou (řekněme možná 2–3 roky) ho začaly objevovat masy a začal být oblíbený. A zrovna v tu dobu ho Rossum rozkope. A celou dobu jim ukazuje, jak ho rozkopává. Je to stejné, jako kdybyste měli nádherné luxusní hotely, o kterých by nikdo nevěděl a najedou by o nich vyšly velké reportáže na ČT1, Nově a Prima a byly na hlavních stránkách novin. A lidi by se přijeli ubytovat a našli staveniště a smrdící kanalizaci. Veškrou popularitu, kterou jste mohli získat v době, kdy se o vašich hotelích mluvilo a kdy hodně záleželo na dojmu a možnost získat klienty jste beznadějně prošustroval stavebními úpravami.
Jinak chtěl jsem udělat i astrologickou předpověď Linuxu, ale na mých stránkách lidi moc nevědějí, co je Linux, tak to odkládám, i když by mě to bavilo. Něco málo jsem zkusil na těchto stránkách, hodně jsem se držel vzadu, napsal jsem snad setinu, co bych napsal jinde. Přeci jenom othle není astrologický server a ctím to.
> Problém minixu, stejně jako hurdu je ten, že veškeré síky se soutředí kolem Linuxu. Staly se přímým konkurentem Linuxu a tím do nich střílí linuxová komunita jako do zavrženíhodných a vyrábí jim neoprávněně špatnou pověst.
> nepřežije Python
O jednom člověku, který se snaží jednomu projektu dělat špatnou pověst kudy chodí, bych věděl. Ve skutečnosti v případě Hurdu a Minixu jde o to, že vývojáři nebyli schopni (v případě Minixu to snad ani nebylo tolik cílem, ale u Hurdu to je zarážející) dostat projekt do použitelného stavu. Nikdo jim klacky pod nohy nehází, prostě jim to nejde. Lidí ochotných zkoušet ledacos bylo a je dost a dost, ale o projekt, který na hlavní stránce píše "The GNU Hurd is under active development. Because of that, there is no stable version. We distribute the Hurd sources only through CVS at present.", zavadí opravdu jenom velice nadšený experimentátor. Zvláštní je, že projekty typu FreeBSD, které jsou daleko OPRAVDU přímými konkurentem Linuxu a stojí za řeč, takové problémy nemají. Tam ti zlí linuxáci, kteří zašlapou každou konkurenci, asi škodí málo.
Pokud nepřežije Python (a to bychom měli asi definovat, co tím kdo myslí), bude to jenom proto, že konkurence bude výrazně lepší. Pokud Python něco "zabije", bude to renesance staticky typovaných jazyků s podporou typové inference. Nejúspěšnější z nich je C#, dalšími významnými příklady jsou Scala (s podporou frameworku Lift), F# (microsoftí kopie OCaml) a Boo (silně inspirovaný Pythonem). Python "nepřežije" tenkrát, až od něj odejdou lidi, kterým bude těsný a ne pár zhrzených milenců. Python 3 se snaží problémy původního návrhu (dva paralelní objektové modely, absence podpory anotace typů apod.) řešit. Pokud by zůstal stát na místě, "umřel" by právem. Tolik můj názor.
Jenom poznamku - Guido proti Lispu nic nema, spis naopak. Pokud byste si precetl treba specifikaci Common Lispu, tak byste zjistil, ze semantika Pythonu byla v mnoha ohledech inspirovana prave Lispem. Duvod pro odstraneni funkci map/filter/reduce bylo, ze zbytecne zatezovaly namespace zabudovanych funkci, a pritom se diky generator expressions da ma map a filter vyjadrit citelneji. Reduce presunuli do modulu, protoze se nepouziva az tak casto (ja ho treba v Pythonu pouzivam podstatne mene nez v Common Lispu, zejmena asi proto, ze v Pythonu neni vse vyraz).
zde by me zajimalo, jak vidite php
Vidíte nějakou náhradu za PHP? Já ne. Je fakticky bez konkurence.
Ano, dají se stránky psát v Javě (ale pro většinu lidí je to vyšší meta, navíc většina javovských postupů je dělaná enterprise způsobem, tedy složitěji, než by být musela). Pak je tu .NET, ale ten jednoduchostí také neoplývá, a široce se mimo MS svět krátkodobě také nerozšíří. Pak je tu Ruby a Python, ovšem minoritně.
23.9.2009 08:48
Amarok | skóre: 33
| blog: blogoblog
Sam zminujete Ruby a Python, pridal bych jeste Perl. Vsechny 3 tyto jazyky nejsou tak slozite jako Java a maji velkou vyhodu, ze se velmi aktivne daji pouzivat i mimo web (narozdil od PHP, kde to sice taky jde, ale je to silenost). Problem je pouze v tom, ze webhostingy nabizeji v drtive vetsine jen PHP, popr. .NET (ale Python uz se trochu zacina prosazovat). Sam ted zacinam testovat Python misto PHP, tak jsem zvedavy, zatim to vypada dobre.Vidíte nějakou náhradu za PHP? Já ne. Je fakticky bez konkurence.
Problem je pouze v tom, ze webhostingy nabizeji v drtive vetsine jen PHPPouze ani omylem. Porovnej si počet lidí, kteří bastlí v PHP a kteří chtějí něco jiného (Perl a spol.) Zjistíš, že na každého perlistu vychází asi tak 250 PHPkářů.
Konec světa jsem za svůj život zažil už několikrát. Konkrétně si pamatuji předpovědi 1970, 2000 a teď 2012.
Ale pravdou je, že na rok 2012 jsou drsnější konstelace, takže jendoduché to nebude.
Umím být i konkrétní, největšího úspěchu dosáhne Linux kolem roku 2015. To bude zenit. Pak bude doba „za zenitem“.Něco podobného jsi ohlašoval i na letošní březen. Vyčisti si dalekohled.
C++ nema spatnu kompabilitu. S kazdou novou verziou gcc je kompletne rozbity projekt.
24.9.2009 01:55
mutable | skóre: 7
| blog: mutable_the_mutative
IMHO (nesnazim se zpochybnovat nebo z tebe/vas delat blbce !!!) budoucnost cehokoliv (v IT) hodne (nejvic?) ovlivnuji penize (takze se hur predpovida podle toho co je v cem dobry).
Proc by se perl mel stat "zivouci zombie" a co to znamena?
Proc by se perl mel stat "zivouci zombie" a co to znamena?Že funguje ďalej, hoci nikto nechápe ako a v tých, čo ho stretnú a nepoznajú ho, budí hrôzu
25.9.2009 19:42
Marek Bernát | skóre: 17
| blog: Arcadia
K tomu binárnímu API. Obvyklý protiargument je, že API vytesané do kamene brzdí pokrok - ale to asi nemá cenu moc opakovat. Spíš chci uvést jednu praktickou zkušenost.
Napsal jsem historicky pár triviálních linuxových ovladačů pro hloupoučký hardware, a občas po mně někdo chce, abych je přizpůsobil na aktuálnější kernely. Port ze 2.4 na 2.6 (okolo 2.6.18) byl překvapivě docela jednoduchý. Když jsem pak mezi 2.6.22, 2.6.26 a 2.6.28 musel cca třikrát drobně upravit nějaké prototypy okolo pci_register_driver() a device_create(), tak jsem se už trochu šklebil. Nemluvě o tom, že se postupem času změnily flagy a prototyp request_irq(). Kdybych ty drivery protlačil do vanilky, možná by to někdo udělal za mě automaticky - ale to asi nepřipadá v úvahu, tak schopnej nejsem. Dalo se to obsloužit nějakými #ifdefy, ale to mi nestojí za to - kdo chce novější ovladač, ať si pořídí novější kernel (a naopak).
No ale taky jsem mezitím zkusil napsat něco pod Windozama s přístupem na sériový port, "Setup API" a "RAS API". Připojení ke GPRS přes RAS/PPP, včetně automatické instalace ovladače modemu. Kromě obecně větší ukecanosti toho zdrojáku mě HODNĚ iritovala jedna věc: že jsem skoro každou API funkci musel volat dvakrát, napoprvé abych vůbec zjistil verzi rozhraní (přesněji: velikost structu, který budu předávat) a teprve napodruhé, abych dostal potřebná data. Je to horší opruz než #ifdefy? Těžko říct... Že přenositelnost mého softwaru mezi několika verzemi Windows snad za tu námahu a nepřehlednost stojí? Za prvé si nejsem jist, za druhé beztak neexistuje, protože jsem odhalil další rozdíly v chování, a stejně jsem neměl čas a důvod to mezi verzemi podrobně testovat...
Možná je to tím, že to programování je pro mě vlastně hobby. Kdyby mě zásadně živilo, měl bych toho za sebou víc, třeba bych měl jiný názor...
A zkoušel jsi to do vanilky protlačit? Možná by to šlo, pokud jde o prodávaný HW. Pak by výše uvedené změny určitě někdo udělal za tebe, ani bys o tom nevěděl :) Navíc ten, kdo by to dělal, by určitě přesně znal, v čem změna spočívá, a měl by to rychle hotové.
Právě že ten hardware je dost obskurní. Nějaké průmyslové I/O karty a řízení krokových motorů... nic pro masy spotřebitelů. Naposled mi na pciids.sf.net odmítli vzít PCI IDčka do databáze, protože Advantech zneužívá PCI subvendor/subdevice atypickým způsobem
Právě že ten hardware je dost obskurní. Nějaké průmyslové I/O karty a řízení krokových motorů... nic pro masy spotřebitelů.
Stejně bych to zkusil, viz např. http://www.mail-archive.com/linux-pcmcia@lists.infradead.org/msg02181.html ?
Naposled mi na pciids.sf.net odmítli vzít PCI IDčka do databáze, protože Advantech zneužívá PCI subvendor/subdevice atypickým způsobem
Pokud to neodpovídá nějakým pravidlům, tak to chápu, ale funkční driver pro komerčně prodávané zařízení? Zkusil bych to :)
Samozřejmě, že měl pravdu.Což dokazují ty stovky hotových a funkčních mikrojader, mezi kterými lze vybírat, kdežto na monolitický kernel člověk dneska nenarazí.
Což dokazuje to, že snad všechny větší os dnes zavádějí alespoň částečně mikrojádrovou architekturu. Ono za rozumných podmínek spolehlivost/cena jinak už větší os dělat nejde. Linux bohužel tento tlak nemá, toho cena vývoje netrápí.
Například ve Windows 7 už chyba v driveru není problém pro stabilitu systému. Driver nemá plná práva jádra os a není na úrovni kernelu.
QNX můžete také bez problému používat.
A x dalších.
presne tak mate pravdu. problem minixu a mozno aj jeho zachrana je ze ide ciste o akademicky projekt teda vyvijaju ho studenti alebo ludia co su tomu blizko to je jeho vyhoda lebo ako hovorite prevazuje hlava nad hrubou silou.. QNX je super ale je v rukach jednej firmy ktora si ho drzi na uzde... jedine co ma napada a sam vkladam do tohto systemu nadej je Haiku... nie je to cisty mikrokernel ale je silne modularizovany a obsahuje message system a servery.
Problém minixu, stejně jako hurdu je ten, že veškeré síky se soutředí kolem Linuxu. Staly se přímým konkurentem Linuxu a tím do nich střílí linuxová komunita jako do zavrženíhodných a vyrábí jim neoprávněně špatnou pověst. Následkem toho je pak používají jako „důkaz“, že koncepce LInuxu je nejlepší možná. Bohužel to Linuxu kazí projekty, které stojí mimo přímý zásah linuxové komunity, kde se ukazuje pravda. Minix je možná do určité míry vyvíjen studenty, ale pod zkušeným vedením. Ostatně třeba jiné akademické jádro mach se stalo základem mnoha systémů, třeba Mac OS X.
Linus je zase člověk, který nikdy neprošel praxí. Nikdy se nepřizpůsobil požadavkům nikoho. Už jako student prostě začal s Linuxem s tam zůstal. Proto Linusovi chybí nadhled a zkušenosti mimo jeden projekt (a několika subprojekty k němu). Vše se přizpůsobuje Linusovi, ale fyzikální zákony se Linusovi přizpůsobovat nebudou.
QNX je možná v rukou jedné firmy, ale hlavně je to důkaz, že postavit mikrojádro není těžké, je to relativně snadné, a operačních systémů s mikrojádrem není málo. Ale Linus prostě rozhodl, že mikrojádro je blbost, a tak se mu všichni vysmívají, protože co řekne Linus je zákon (i když je to blbost).
Mikrojádro je nejjednodušší cesta ke spolehlivému systému. Základní statistiku, že počet chyb v programu stoupá s jeho velikostí nepřevezete. Můžete snížit o něco jejich průměrný počet na řádek, ale to je tak všechno. O několik řádů se to ale nepovede.
Modularizovaný systém je málo, tím sice zlepšíte udržovatelnost projektu, ale pokud jednotlivé moduly nejsou odděleny i pro případ chyby, moc to situaci nezlepší. Je třeba uvažovat, že nebezpečný je jakýkoli kód, včetně kernelového.
Podle mého by Linux udělal nejlépe, kdyby začal z další řadou, třeba 2.8, která by začala stavět na konceptu mikrojádra. Ovšem s tím, že by se jasně tento koncept preferoval a nezdržovaly se většinou vývojových kapacit na aktuální monolitické řadě. Pokud se to neudělá, je Linux potencionálně mrtvým systémem cca do 10 let.
Podle mého by Linux udělal nejlépe, kdyby začal z další řadou, třeba 2.8, která by začala stavět na konceptu mikrojádra. Ovšem s tím, že by se jasně tento koncept preferoval a nezdržovaly se většinou vývojových kapacit na aktuální monolitické řadě. Pokud se to neudělá, je Linux potencionálně mrtvým systémem cca do 10 let.
Predelavat Linux na mikrokernel je hodne velka blbost, ktera by vas jako zkuseneho programatora nemela ani napadnout. Takovy architekturni skok se neda udelat pres noc, ale ani za jeden dva tri roky ... :/ Je to vicemene to same jako rict si "pojdme naprogramovat mikrojadro se sluzbami, ktere se vlastnostmi priblizi Linuxu".
Zvlastni ale je, proc firmy, ktere na Linuxu stavi sve reseni (IBM, HP, ...) stale investuji do rozvoje Linuxu a misto toho nenaprogramuji poradny mikro kernel.
Já jsem přeci nenapsal, že to jde přes noc. Ale doba 2–3 let na plný přechod na mikrokernel je velmi reálná a ještě s velkou rezervou.
Upřímně, úsilí, které se vrazí do snahu udržet jádro linuxu stabilní bude větší, než udělat ten architekturní skok. Na jedné straně jsou náklady architekturního skoky a toho co to přinese a pak na druhé straně jsou náklady toho, když se ten skok neudělá. V tuhle chvíli možná mírně převažují náklady na přechod na mikrokernel, za pár let to může být přesně naopak.
Firmy staví svá řešení na tom, co je vyjde levněji. Proč by proboha nevyužili práci druhých, kterou jim někdo dá zadarmo. To že do ní maličko přispějí a zaplatí si tak stotisícinu toho, co by musely platit jinde – tomu se říká optimalizace nákladů. Stejně tak IBM a HP milerády opustí Linux jakmile najdou levnější/výhodnější řešení. Podívejte se kolem sebe a odpovězte si sám, jestli se vyrábí spíše kvalitní věci, nebo spíše nízkonákladové věci.
Ale doba 2–3 let na plný přechod na mikrokernel je velmi reálná a ještě s velkou rezervou.
Vyvoj 2.6 trval neco pres 3 roky, rikate tedy, ze je to podobny skok jako "prechod" na mikrojadro? (Nehlede na to, ze pri vydani 2.6.0 bylo jadro polovicni)
Firmy staví svá řešení na tom, co je vyjde levněji. Proč by proboha nevyužili práci druhých, kterou jim někdo dá zadarmo. To že do ní maličko přispějí a zaplatí si tak stotisícinu toho, co by musely platit jinde – tomu se říká optimalizace nákladů. Stejně tak IBM a HP milerády opustí Linux jakmile najdou levnější/výhodnější řešení. Podívejte se kolem sebe a odpovězte si sám, jestli se vyrábí spíše kvalitní věci, nebo spíše nízkonákladové věci.
Nicmene tyto firmy maji taky trochu prehled o tom, ze mini delat v budoucnosti. Pokud, jak tvrdite, pujde Linux brzo do kytek, meli by uz ted vynakladat znacne penize na vyvoj naslednika Linuxu - coz ale nikde nevidim.
Vyvoj 2.6 trval neco pres 3 roky, rikate tedy, ze je to podobny skok jako "prechod" na mikrojadro? (Nehlede na to, ze pri vydani 2.6.0 bylo jadro polovicni)
Řeknu to jinak. Windows změnilo architekturu od základů už několikrát.
Nicmene tyto firmy maji taky trochu prehled o tom, ze mini delat v budoucnosti. Pokud, jak tvrdite, pujde Linux brzo do kytek, meli by uz ted vynakladat znacne penize na vyvoj naslednika Linuxu - coz ale nikde nevidim.
Pokud mi budete tvrdit, že dnes firmy dlouhodobě plánují dopředu, pak se asi začnu chechtat. Dnešní firmy určitě na něčem nepracují 10 let, aby jim to za 10 let přineslo zisk. Akcionáři dnes nenechají žádnou firmu vydělávat peníze až třeba za 5, nebo 10 let, oni chtějí ty peníze v kratších horizontech.
Nicméně, pokud by zanikl Linux, pro tyhle firmy je to jedno. On ten kód bude fungovat. No tak ho sem tam trochu opráší a až to bude aktuální, tak najdou, či vyvinou jiné řešení. Dodnes jsou řešení, která fungují na MS-DOSu, nebo na WIndows 3.1, ale určitě se nedá říci, že MS-DOS, nebo WIndows 3.1 má budoucnost.
Řeknu to jinak. Windows změnilo architekturu od základů už několikrát.
To je mozne. Postaral se MS taky o predelani vsech ovladacu?
Nepostaral. A není to ani třeba aby to dělal. Stačí, že dobře definoval API. K tomu napsal pár tisíc základních generických ovladačů.
Linux je báječný v tom, jak definuje svět. Když už dělá kernel, tak si k tomu přidá ještě drivery. Předpokládám, že další meta bude výroba umělé planety pro běh linuxu.
Není třeba dělat monstrózní projekty za každou cenu.
Zapomínáte na to, že nebýt tohoto stylu vývoje (udělej si všechno sám) tak má Linux na desktopu z nás jen málokdo. Prostě nelze srovnávat Windows co běží snad na 96% všech desktopů a Linux. Microsoft si (teoreticky) může s kódem svého jádra a s jeho API dělat co chce, protože jsou na něm všichni závislí, uživatelé,výrobci i prodejci. Budou muset následovat - to je způsob vývoje v Microsoftu.
Taky je naprostá blbost srovnávat rychlost změny architektury Linuxu a Windows. Zatímco v MS se udělá nějaký projektový záměr, vyčlení se peníze a začne se efektivně rozdělovat práce, v ohromné komunitě často na svých projektech pracujících vývojářů Linuxu toto není naprosto možné.
myslim, ze tady by se hodil vyrok (tusim, ze ho rekl tetenbaum (ale nevim jiste));
"zadny operacni system jeste neprezil delku zivota cloveka" (mysleno s nadhledem, ne ze nekdo se narodi a zemre pod "tramvaji")
takze dle meho p. ponkrac nema zas tak mylnou uvahu.
Jak by taky mohl, ze? :)
ENIAC, ktery je casto povazovany za prvni skutecny pocitac je stary jen neco malo pres 60 let.
IMHO neni duvod, proc treba by uz zde zminovany QNX nemohl v embedded zarizenich vydrzet treba sto let.
Jinak, taky si myslim, ze Linux jednou fakt vyhnije, ale to prvni musi prijit nastupce.
Pod Windows si driver může stáhnout a nainstalovat kdokoli, protože drivery se distribuují typicky v binární podobě přes sajty třetích stran, a často nemáte jinou šanci než použít "nepodepsaný" ovladač.
Pod Linuxem většina normálních lidí používá drivery vanilkové nebo ještě snad "distro-specific" a kvalita důležitých generických driverů je znatelně lepší než u různých paskvilů, co si musíte postahovat pro Windows (třeba pro různé USB cetky).
Nicméně pokud to Windows dotáhne do stavu (nebo jiný os), kdy drivery nemá šanci poškodit systém, pak na tom binární drivery budou lépe, než generické v Linuxu.
Zatím to tak na 100% není, ale je to správná cesta.
Takže nekvalitní binární driver do mikrokernelu je lepší než kvalitní generický v monolitickém jádru? To pak vysvětlujte uživateli, proč jemu s moderním mikrokernelem nejede disk, zatímco kolegovi s monolitem to šlape v pohodě.
Vy jste položil otázku špatně. Je jasné že je lepší dobrý ovladač na monolitickém jádře. Problém ovšem nastane, když velké množství kódu různých ovladačů přinese chybu (a to nastane velmi jistě, není to hypotetická možnost). Pak dojde ke zhroucení kernelu, což je nezastavitelná operace. V případě mikrokernelu dojde ke zhroucení jen separátní části a jádro zůstane běžet, což umožňuje záchranné operace nebo vzpamatovní se z chyby. Tedy, kdyby se dala zajistist bezchybnost velkého jádra, tak by to byla nejlepší cesta. Například je vždy program jednoho člověka lepší než stejný program vyvíjený více lidmi. Jednotnost přináší kompaktnost, efektivitu a lepší časovou režii. Bohužel od určité úrovně nelze dělat jednočlověkové projekty z toho důvodu, že by trvaly moc dlouho. Totéž platí pro kompaktní kernel. Od určité velikosti je třeba řešit práci jinak. Je otázkou zda se došlo ke kritické velikosti už teď, nebo zda je to ještě daleko před námi.
Nene, já jsem ji položil záměrně takto. Znám kvalitu driverů pro linux a windows - v prvním případě jdou stále dopředu a opravují se i starší kusy, když na to někdo narazí a potřebuje, v druhém případě nemá výrobce žádnou potřebu utrácet finance na něčem, co už nepřinese ani korunu. Podle toho to také vypadá.
Nedělám si iluze, že v mikrokernelu bude kvalita binárních uzavřených ovladačů vyšší, než dnes. A když odejde ovladač důležité služby (např. právě disk), může se uživatel stejně jít klouzat, pokud se jej nepodaří nahodit. Souhlasím s argumenty p. Ryšánka.
Argument Linuse zcela jistě nebyl o monolit vs. mikrokernel, ale o rozdělení do více subprojektů, aby kompletace celého jádra nebylo jen na něm. Jenom po vytažení z gitu má ten adresář 400MB.
V případě mikrokernelu dojde ke zhroucení jen separátní části a jádro zůstane běžet, což umožňuje záchranné operace nebo vzpamatovní se z chyby.Přehlédl jsem ji, nebo opravdu ještě nikdo tady nepoložil otázku, k čemu je dobrá záchranná operace, když ten zhroucený ovladač byl třeba k řadiči disku a jádro stejně spadne o chvíli později, protože se nebude moci hnout?
A ak to nie je ovladac k radicu disku, ale k zvukovke, sietovke - vtedy to predsa dava zmysel ...
Když vidím pokrok v oblasti virtualizace, přemýšlím, kolik práce by dalo vsunout před kernel nějaký mikrokernel. Vlastně tak fungují dnešní hypervisory i třeba RTAI/RTlinux nanokernely. Ale nejsem si úplně jist, nakolik by bylo přínosné toto prosadit pro běžný linuxový kernel pro všeobecné použití. Nejsem autor operačních systémů, jsem laik, jsem zvědav na protiargumenty...
Když se zblázní ovladač, a sáhne v paměti kam nemá, tak sice neohrozí mikrokernel, ale pokud nebude oddělen "ochranou paměti" od ostatních součástek kernelu které jsou taky mimo mikrokernel, tak možná nedotknutelnost samotného mikrokernelu není k ničemu, protože je tu spousta dalších klíčově důležitých součástek, které může chyba konkrétní součástky shodit / zacyklit / přetížit...
Má smysl vyrábět pro ovladače "kontexty" navzájem oddělené ochranou paměti (virtuální paměťové prostory)? Pro obsluhu hardwaru dost možná nikoli. A pokud některé dnešní hardwarově nezávislé kusy kódu běží v kernelu (třeba filesystémy) namísto v user space, typickým argumentem bývá rychlost. Pokud se začneme bavit o paměťové ochraně kernel-space modulů, řešíme v podstatě velmi podobný problém, jako je dnes volba mezi user space a kernel space - zda má být kus kódu zkompilován do podoby jaderného modulu, nebo user-space procesu. Proto je třeba NTFS-3G velmi spokojeno v user space, ačkoli je to potenciálně na úkor rychlosti.
Nebo jiný příklad: je hezké, že mikrokernel zařídí společný základ obsluhy přerušení (ostatně to má Linux systémově řešeno taky snad odjakživa), ale když "bezpečně oplocený" driver neobslouží správně konkrétní zdroj interruptu ve "své" hardwarové periferii, tak to stejně způsobí záplavu interruptů a v podstatě to shodí systém (nebo neshodí, pokud se systém umí bránit utlumením daného zdroje, ale to dnešní Linux umí taky).
Nakolik je užitečné, když máte memory leak v nějakém kernelovém modulu, že Vám skrytě nezapíše někam jinam do kernelu (a může nebo nemusí způsobit havárii), ale že namísto toho hodí GPFko a daný modul je odstraněn? Za určitých velmi příznivých okolností to může znamenat rozdíl mezi ztrátou a záchranou "rozdělané práce" uživatelů. (Ovšem ze své praxe si vybavuji spoustu různého "divného chování" systému pod divnými zátěžemi, kdy nedošlo k memory leaku, ale systém je přesto v nepoužitelném stavu a prakticky se musí natvrdo zabít.) Ochrana paměti je taky teoreticky užitečná pro ladění. Pokud se nepletu, vývoj v oblasti nástrojů pro ladění chyb práce s pamětí pro kernel-space dodnes probíhá. Ale za běhu? Je velký rozdíl mezi tím, když Vám chcípne důležitý modul sám o sobě, nebo když shodí celý systém? A vemte si tu cenu, kterou bychom za vzájemnou ochranu paměti v kernelu zaplatili: moduly by si nemohly sáhnout přes pointery kamkoli do kernelu, volat callbacky v úplně jiné části systému apod, ale musely by používat nějaké API (syscally) pro "přepínání kontextů ochrany paměti" a "mezimodulovou komunikaci"...
Mám pocit, že myšlenka interní ochrany paměti mezi různými částmi dosud monolitického kernelu navzájem je možná přeceňována. Použití interních API a rozdělení funkcí každého modulu na privátní a veřejné/exportované zajišťuje dost slušnou ochranu proti prasečímu programování. Zásadní memory leaky se hledají poměrně svižně.
Ostatně když tak zkoumám, jaké problémy trápí vývojáře, o čem se mluví apod., tak jsou to především problémy toho typu že konkrétní oblast nebo kus kódu má nedostatečný výkon (FS, I/O scheduling, snad i CPU scheduling, VM), nepodporuje nový hardware, není vývojářská dokumentace pro nový hardware, nebo že něco prostě nefunguje přestože by mělo, špatná/neaktuální uživatelská dokumentace modulů/fičurek, řeší se věčně nějaké nové ladící frameworky, na jednom konci virtualizace a na druhém power management, občas nějaká změna struktury kódu / přepracování na novou kostru, občas nějaký obskurní bezpečnostní problém - ale relativně málokdy vidím stížnost na záhadné zatuhávání celého systému nebo kernel panic, které by bylo dohledáno k vyslovenému memory leaku. Problémy jsou více na "sémantické" úrovni algoritmů. Že systém občas někomu tuhne kvůli jeho individuální hardwarové závadě, to se nedá nic dělat.
Linus mluví podle mého spíš o tom, že kernel toho dneska už umí strašně moc a trvale je problém vůbec řídit údržbu a další vývoj - přestože nástroje a organizační uspořádání pro řízení vývoje kernelu se neustále postupně zdokonalují. Linusovi chodí obrovská hromada patchů ke schválení. Zdrojáky kernelu obsahují spoustu ovladačů pro různý hardware, různé filesystémy, vychytávky typu RAID a LVM, různé varianty drobných interních uspořádání pro různě "velký" hardware (od miniaturních jednoprocesorů po masivní SMP a NUMA systémy), různé instrukční sady procesorů. Linusovi a jeho partě se zatím daří tuhle obrovskou hromadu kódu rozumně strukturovat, takže je to celé spravovatelné a skutečně to funguje. Třeba zrovna teď jsem něco hledal v ASM zdrojákách pro i386 a s povděkem kvituji, že se vlastní kód i "režijní" soubory ve stromu za posledních pár major verzí hezky uspořádaly a vyčistily (viz např. x86 architecture merge/cleanup) a Kbuild mi taky přijde přehlednější a čistší, než býval. Nejnovější nalajnování toku patchů nad GITem (stromy "staging" a "linux-next") sice Linusovi jako vrcholovému šéfovi i jeho pobočníkům značně ulehčily od otravného řešení drobných nekompatibilit patchů s nejnovějším vývojem interního API (resp. se ta práce odsunula a rozdělila mezi víc lidí na nižších úrovních), ale taky tohle uspořádání usnadnilo přispěvatelům zasílat opravy a zcela nové ovladače, usnadnilo vzájemnou spolupráci celé komunitě kolem kernelu - takže objem provozu, který se sbíhá u Linuse na jeho šéfovském stole, co do počtu patchů a počtu změněných řádek dál roste.
Řeknu to jednoduše. Mikrokernel je programován jinak, než monolit.
Pokud chcete z počítače vyždímat maximum výkonu na 110%, pak monolit má mírné výhody. Jde o to uspořádat architekturu mikrokernelu tak, aby rychlostně byla optimální.
Linus a další mohou čistit kernel jak chtějí, ale jak vidíte, objevují se problémy velkých projektů: Pro Linuse je kernel už neřiditelný a objemově přesahuje to co by si přál. Časem začne být kernel i nespolehlivý. Zvyšuje také nároky na vývojáře, což se časem projeví v menším množství lidí, kteří budou moci zasahovat do vývoje kernelu.
V každém programu i v kernelu Linuxu je rychlostně kritických míst velmi málo, zlomeček procenta. A i tam často jde spíše o vymyšlení fikaného algoritmu, než o rychlost hrubého výkonu (ne vždy, ale často).
Ono už nemá moc smysl se ptát, jestli má smysl oddělovat galvanicky (schválně jsem použil slovo mimo it) různé části kernelu. Ono už má jenom smysl se ptát jak. Všechny velké os už pochopily, že pokud mají udržet provozuschopnost os na uzdě, pak musejí galvanicky oddělovat různé části kernelu a driverů tak, aby byly pokud možno hermeticky odděleny. Je to evoluce, takže každý os je napůl cesty a jen málo to má dotaženo do dokonalosti. Nicméně cestu k oddělování částí kernelu mezi sebou nastoupili všichni.
Unix prostě kdysi nastoupil cestu monolitu. Byl to směr a trend, který mu umožnil prosadit se na tehdejším slabém hw, ale také: dříve co programátor, to špička s dokonalou teoretickou přípravou. Dále dřív kernel dělal zlomeček toho, co dělá dnes. Kernel byl relativně malý. Pak řada klonů unixu šla touhle cestou, ale ne všechny.
Jsou jiné podmínky a jiné požadavky.
Ten termín "galvanická izolace" je trefný
Docela by mě zajímalo, jak přesně to mají různé OS s mikrokernelem řešeno. Které přesně oblasti má pod palcem samotný mikrokernel, a jak je "rozparcelovaný" zbytek. Takový MacOS - to je údajně základ z FreeBSD, ale je tam "vsunutý Mach mikrokernel". A to je vše? Nemáte nějaké linky na další čtení? Vím třeba o tom, že v user space je levnější "context switch" mezi vlákny než mezi procesy. Nicméně už z definice, pokud chceme nějaké oblasti od sebe "galvanicky izolovat", tak je tam potřeba především ochrana paměti, což je právě ta těžší tonáž.
Co tu tak pozoruju ostatní názory, asi by stálo za to vedle samotného mikrokernelu (IRQ, VM) jako další parcelu vydělit třeba všechno kolem přístupu na disk, další parcela by mohla být grafika, další parcela přístup na síť. Aby jako životně důležitý byl chráněný přístup na disk, a aby se na ten stroj dalo dostat pokud možno buď z lokální konzole nebo po síti. Nejvíc bince je v "hračkárnách" okolo multimediálních periferií a okolo USB endpoint devices - tam by mohly vést další "izolační přepážky".
Zaslechl jsem zmínku o "nízkém výkonu mikrokernelu Mach ve filesystému". To jako že FS taky patří do mikrokernelu? Nebo jenom VFS vrstva? Nebo jak je to?
Z povzdálí koutkem oka sleduji debaty na LKML, že tlusté obsluhy IRQ je potřeba systematicky vystěhovat z IRQ kontextu do nějakých kthreadů / taskletů / líných front. Čili někam mimo IRQ kontext, ale pořád v rámci kernelu, bez ochrany paměti od zbytku kernelu. Taky jsem zaslechl poměrně čerstvou zmínku, že těch kthreadů na každé jádro už je nějak moc, a že poměrně jednoduchou úpravou se ta práce dá sesypat do "líných front" (a celou frontu pak obslouží jediný kthread). Taky se občas něco "vymění za oponou" v oblasti kernelové správy paměti. Domnívám se, že různé oblasti kernelu včetně "kernel core" jsou už dnes dost opouzdřené do standardizovaných rozhraní, takže vyměnit součástku za něco jiného není velký problém. Řekl bych, že "přimalovat hranice" na dodatečnou ochranu paměti by nemusel být až takový problém z hlediska programátorské pracnosti. Pokud se tak dosud nestalo, možná jde především o příznak převažujícího názoru, že to momentálně vlastně není potřeba, a že by to zbytečně snížilo výkon.
Svého času jsem trochu zkoumal, kam se vlastně háčkuje nanokernel RTAI. Nějak mi nechodily APICové interrupty. Došel jsem k závěru, že si pro sebe vezme kus paměti, nainstaluje "superobsluhu" IRQček, prostě si pro sebe uzme vyšší prioritu a linuxový Kernel odstrčí až na druhé místo v řadě, ale jinak se mu do běžného provozu moc nemíchá (rutinní správa paměti, plánování procesů apod). Možná právě v koncepční jednoduchosti tohoto přístupu spočívá důvod, proč je relativně snadné takovou věc implementovat. Celý kernel pak ovšem běží dál vnitřně víceméně v klasickém režimu, tj. interně bez ochrany paměti, tj. náš "problém" to nijak neřeší. Přesto si myslím, že ani skutečné interní rozparcelování kernelu by nebylo z hlediska programátorské pracnosti o mnoho řádů větší problém. Problém bych viděl spíš s dopadem na výkon...
Ještě mě napadá jedna věc. IOmem okna by se v rámci mechanismu ochrany paměti dala mapovat podle potřeby do různých "parcel". Vyskytují se "složená" PCI zařízení, která mohou mít třeba několik principiálně různých periferií (IO footprintů) nacpaných pohromadě do jediného IOmem okna. Takže pak na jedno PCI zařízení musíte natáhnout ovladač třeba pro jeden paralelní a dva sériové porty. Pokud by ty ovladače bydlely v různých parcelách, může být problém. Je fakt, že na hardwarové úrovni se dá konkrétní IOmem stránka namapovat více "parcelám" (pak si ale různé parcely na tom zařízení mohou "lézt do zelí"). Taky je fakt, že tohle stěsnané využití adresního prostoru je typičtější spíš pro IO port resources (které se nemapují), zatímco IOmem okna (typická pro výkonnější zařízení) bývají pro jednotlivé funkce rozumně oddělená a zarovnaná. I když, představte si, že ten PCI device (síťovka, video) má někde uprostřed ve svém banku portů zakomponovaný I2C interface Nejsem odborník na x86 VM , ale řekl bych, že tohle se může trochu zašmodrchat Třeba už v "API PCI ovladačů" se pro konkrétní PCI device natáhne jenom jeden kernelový modul, a pokud je třeba loadnout více driverů pro různé "banky registrů", tak je musí tenhle hlavní modul loadnout / zaregistrovat programově přes specifická API, a ty "podřízené drivery" už si na sebe podruhé neregistrují dané rozsahy IO portů a IOmem, protože by ta registrace napodruhé selhala.
Hezky to popisujete.
Domnívám se, že mikrojaderná architektura Windows nebo Mac OS X je dneska jen pozůstatek historických ideálů a požadavků (spouštět programy pro různé operační systémy v rámci téhož skutečného systému), které jsou dnes opět jen na ozdobu (umí snad dnešní Windows pouštět aplikace pro OS/2 nebo umí běžet na PPC?) a že ve skutečnosti celý systém je z hlediska ochrany paměti monolit.
Pokud se podíváte na skutečný mikrokernel, nedávno tu byla diskuze o Helios nebo HelenOS nebo jak se ten systém jmenuje, tak mikrojádro ve skutečnosti dělá jen IPC, ostatní služby jádra běžné na monolitu jsou řešeny přes IPC a všechno je proto asynchronní a všechno může selhat a všechna selhání se proto musí nějak ošetřit. Kromě nechutně rozvláčného kódu (několik if-větví místo jediného open(2)) to musí mít nechutnou režii, pokud se používá ochrana paměti (kvůli programovaná MMU), jinak to akorát žere procesor (kvůli mnoha instrukcím).
Jako časem, až každý počítač bude několikaprocesorový SMP nebo ještě lépe NUMA, asi obětujeme kus výkonu, a budeme používat mikrokernely, jako jsme se smířili s oddělením jádra od uživatelského prostoru, protože prostě architektura to snese a aplikace si to budou žádat. Ale zatím ten čas ještě nenastal. I když prostřednictvím hardwarové virtualizace se k ní blížíme.
Když už chcete používat termity, ujistěte se nejprve, že aspoň tušíte, co znamenají:
http://en.wikipedia.org/wiki/Memory_leak
Ale pokud už má kernel desítky milióny řádek, je naprosto utopické dále jet v tezi, že kernel bude dokonale odladěný, bezchybný kus kódu.Souhlas; ale to je problém i jiných projektů, než jen jádra. Každopádně je spousta možností, jak z toho ven, a postupem času se nějaká uplatní. Jen v této diskusi jich zaznělo několik.
Evoluce daná tím kdo si co prosadí je sice dobrá, ale neumožňuje prosadit dobré koncepty, ale spíše snadné koncepty. Nebo koncepty, kde je rychleji vidět výsledek. Dost to eliminuje zkušené lidi v delším horizontu. A ono to jednou bude znát.Naopak to ještě v delším horizontu přinese lepší výsledek. Aneb katedrála a tržiště... ten Váš odborník to může vymyslet úplně bezvadně, ale až pojde, tak se z projektu stane jeho pomník.
Souhlas; ale to je problém i jiných projektů, než jen jádra. Každopádně je spousta možností, jak z toho ven, a postupem času se nějaká uplatní. Jen v této diskusi jich zaznělo několik.
Ano, to je problém všech velkých projektů. Proto také netvrdím, že jádro je špatné, jen že nabylo rozměrů, kdy se bude muset potýkat s problémy projektů velkého rozsahu.
Nepochybuji o tom, že se řada možností, jak zlepšit problém uplatní. Můžu přidat další možnosti. Sjednocení části kernelu (řada věcí se tam duplikuje), vyhození některých částí mimo kernel, použití sofistikovaných prostředků pro automatickou kontrolu kódu, zvýšení počtu samokontroly kódy, atd. atd. atd.
Nicméně je to jen odložení problému.
Naopak to ještě v delším horizontu přinese lepší výsledek. Aneb katedrála a tržiště... ten Váš odborník to může vymyslet úplně bezvadně, ale až pojde, tak se z projektu stane jeho pomník.
Nemám pocit, že by dobře vymyšlená architektura pošla po smrti autora. Aby bylo jasno, to největší co chce největší zkušenosti je návrh architektury a vnitřní struktury projektů. Klidně už to může naprogramovat, nebo udržovat i další člověk. Návrh mikrojádra chce zkušenosti silně převušující průměr. Znovu píšu návrh. Mimochodem, projektant Sixtinské kaple jí také nepostavil cihlu po cihle a kupodivu přežila i jeho smrt.
Nicméně je to jen odložení problému.Každé řešení je odložení problému... a popravdě to stačí.
Nemám pocit, že by dobře vymyšlená architektura pošla po smrti autora.Tak to asi málo čtete. Architektura je stejně měnitelná jako cokoliv jiného. Vychází z nějakých předpokladů, které časem přestanou platit.
Návrh mikrojádra chce zkušenosti silně převušující průměr.Už jen z normálního rozdělení vyplývá, že čím větší komunita, tím více takovýchto lidí v ní najdeme. A pak už jen stačí, aby si ten člověk sedl ke klávesnici a něco předvedl. Otevřená komunita má totiž tu výhodu, že přijímá pouze kvalitní produkty, ne kvalitní návrhy.
Kernel musí přijmout koncepci, že i v kernelu se může leccos zhroutit a nemělo by to poškodit systém. V čistě monolitickém jádru ale smolenka.Neviem aké máš v tomto smere skúsenosti ty a či linoxový kernel považuje za monolitický, ale nedávno som na vlastnej koži zistil, že linuxové jadro je schopné prežiť a kľudne fungovať s Ooops-om (referencovanie neplatného pointra), ktorý sa udeje v ovládači, ktorý je v module. Keďže drvivá väčšina z tých 11E6 riadkov jadra sú ovládače a môžu byť v moduloch, tak si nemyslím, že by stabilita linuxového jadra bola výrazne ohrozená bugmi v ovládačoch.
Jenom bych rad podotkl, ze Linus nemluvi o nestabilite, ale "bloatu", coz je neco jineho. Naopak, Linuxove jadro je pomerne dost stabilni (a myslim, ze to i v tom rozhovoru rika). To v cem je ale problem (IMHO) je, ze kazde pouziti jadra chce neco trochu jineho, a tim, ze se to jadro neustale zobecnuje, nastava tento bloat. Podobny efekt lze vysledovat i u jinych programu.
Takze, to o co jde vubec nesouvisi s mikro vs. mono jadro debatou (a proto je vase predpoved ponekud mimo). Tohle je obecny problem SW inzenyrstvi, ktery proste vyplyva z rozsahlosti pozadavku, a neni (zatim) rozumne resitelny.
Jojo. Pokud máte neřešitelný programátorský problém, třeba potřebujete pokrýt mnoho různých mírně odlišných případů, zkuste přidat úroveň abstrakce. Takže těch vrstev pořád přibývá. A debatuje se o tom, že lepší než přidat další mezivrstvu, je leckdy opouzdřit "často opakovaně implementovaný" kód do knihovny a tuto nabídnout ostatním autorům ovladačů stejné kategorie... O tom jsem četl tuším v souvislosti s libata. A objem kódu přesto bobtná. Je to špatně? Neřekl bych
Také dávám přednost "zobecnění" stávajícího driveru pro určitý čip před copy/paste/modify. Samozřejmě jsou výjimky, ale obecně mi duplicitní podpora stejných obvodů v různých kódech moc nevyhovuje. Někdy se při tom zobecňování přijde na chyby v původním kódu, nebo se doplní nová užitečná funkce (třeba debug výpis do procu).
22.9.2009 12:42
Amarok | skóre: 33
| blog: blogoblog
22.9.2009 14:35
vain | skóre: 16
22.9.2009 15:32
Amarok | skóre: 33
| blog: blogoblog
ja cekam az prijde mikrokernel s miniaturnim jadrem a skvele drajvry z linuxoveho jadra se hodi do user-level serveru.
Qnx je fajny system ale je na neho malo aplikacii.. sice teraz qnx presiel na pkgsrc s netbsd ale chybaju nativne aplikacie ktore by boli robene qnx gui (photon ci ako sa vola).. vyssie bolo spomenute ze napisat microkernel je lahsie a lepsie nez monolit ale to VOBEC NIE JE pravda... napisat mikrokernel a dobry je tazke... pozrite sa na Hurd stale daco prerabaju nemyslim Hurd ale mikrokernelove jadro nad ktorym bezi.. pretoze sa ukazalo ze mach ma velke vykonostne nedostatky hlavne vo filesystemovej vrstve.. preto skusaju vsetky free (predpokladam ktore su pod gpl) mikro jadra ake su a stale nemozu najst to svoje.. (coyotos, l4, atd..) je zazrak ze niekto vytvoril funkcny mikrokernel ako Qnx alebo minix.. ale to sa nestalo zo dna na den..
opensolaris je totalny monolit.. to radsej linux a freebsd je ospevovane preto lebo vyvojari nic nerobia len zdokonaluju sietovu vrstvu.. preto je dobry na servery
Napsat dobrý mikrokernel je jednodušší, než dobrý monolit.
Co je těžší je NAVRHNOUT dobrý mikrokernel. Špatně navržený mikrokernel začně mít výkonnostní nedostatky.
Pokud navrhnete dobře mikrojádro a systém komunikace, jste z toho venku. Ale to musí opravdu udělat velmi zkušený programátor ten návrh.
Je prostě pár sw problémů, které chtějí nadprůměrné zkušenosti. Například návrh dobrého databázového jádra chce zkušenosti. Návrh dobré architektury mikrokernelu chce zkušenosti. Návrh dobře optimalizujícího kompilátoru chce zkušenosti. Atd. Při všech těchto projektech musí hlavně hodně dobře přemýšlet a hodně navrhovat v mozku a na papíře, než vůbec napíšete první programátorský řádek. To programování je relativně jednoduché.
Zatímco jsou věci, které jsou jednodušší a monolit je jedna z nich. I já jako student a vlastně většina lidí kolem mě jsme napsali nějaké jednoduché monolitické jádro os ještě jako studenti bez větších zkušeností. To není nic sofistikovaného.
A znovu, každý projekt se dá i potentovat. A to, že někdo něco udělá špatně neznamená, že to řada lidí neudělá dobře.
22.9.2009 17:33
Shadow | skóre: 25
| blog: Brainstorm
.
Podívejte se někdo co o tom píše Seznam.cz. Je to k pousmání. A ta diskuze tam.
22.9.2009 21:03
Voty | skóre: 12
| blog: gemini
Jojo, taky jsem na to narazil a nevydržel to a napsal autorovi pár řádek.
24.9.2009 19:14
Amarok | skóre: 33
| blog: blogoblog
Ja by som zanik linuxu tak jasne ako tuna pan jasnovidec nado mnou nevidel. Kazdy softver zastarava, tak sa to deje aj s linuxovym kernelom. Nemusi ist vsetko do kyticiek. Cast sa znova pouzije, cast sa prepise, cast sa zahodi. Ani ludia, co pisali doteraz linuxovy kernel, o dna na den nezomru a s nimi aj skusenosti zostanu.
Silu linuxu vidim v tom, ze ma za sebou velku armadu mravcekov (myslim v dobrom zmysle slova). Ked sa udeje velka zmena, mravcekovia sa daju do prace a svoje kusy kodu tejto zmene prisposobia.
Ak sa to aj o par rokov nebude volat linux, tak to nezanikne, ista cast aspon prezije.
V GPL vidim velku vyhodu, pouzijes cudzi kod a na oplatku poskytnes vlastny kod. Viem si predstavit situaciu, ze sa pouzil "volny kod" nieco v zmysle BSD licencie a cele by to bolo obalene nejakym kodom zo sedej zony od korporacie xy, ktora by ho poskytovala len za uplatu.
Naprosto souhlasím. Např. know-how o funkci toho kterého hardwaru uložené ve zdrojácích a komentářích ovladačů - to nikam nezmizí a může se na tom dále stavět. To je stejně drtivá část kernelu, právě ta, která roste nejrychleji.
Ale zase mi nepřijde, že by rostla nekontrolovaně. Nevím jak v jiných subsystémech, ale např. v alse má každý chytřejší integrovaný obvod svůj modul a driver konkrétní zvukovky si tyto moduly skládá a konfiguruje dle konkrétního osazení čipů na desce. Také proto jsou ty moduly po nějaké době velice dobře odladěné. Narozdíl od nejmenovaného binárního systému, kde každý výrobce píše vše od začátku, pokud si nekoupí hotovou kostru od nějaké třetí strany. Ukázka vzorového zdrojáku pro takový ovladač přímo od výrobce jsem viděl a nebylo to hezké.
Nemám problém věnovat večery kódu pod GPL. V případě BSD bych se raději koukal na filmy :)
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz