Jaderné noviny – 9. 9. 2011: Multiplatformní ovladače a Linux

19. 9. 2011 | Luboš Doležel

Články - Jaderné noviny – 9. 9. 2011: Multiplatformní ovladače a Linux  

Aktuální verze jádra: 3.1-rc5. Citáty týdne: Matthew Garrett, Linus Torvalds, fpletz. K multiplatformním ovladačům.

Obsah

• Aktuální verze jádra: 3.1-rc5
• Citáty týdne: Matthew Garrett, Linus Torvalds, fpletz
• K multiplatformním ovladačům

Aktuální verze jádra: 3.1-rc5

Aktuální vývojovou verzí jádra je 3.1-rc5 vydané 4. září. Pokračující problémy na kernel.org zapříčinily, že toto vydání je hostované na neobvyklém místě.

master.kernel.org je však stále mimo provoz a moc aktivně se nevyvíjelo, takže jsem uvažoval nad tím, že prostě přeskočíme jeden týden. Jenže celým smyslem (no dobře, *jedním* ze smyslů) distribuovaného vývoje je to, že jedno místo není ve skutečnosti odlišné od kteréhokoliv jiného, takže když už jsem si udělal účet na githubu pro můj divelog [záznam potápění], proč nevyzkoušet, jestli to vydrží, když tam dám celý repozitář jádra?

Ze zjevných důvodů není na kernel.org aktuálně dostupný kompletní seznam změn.

Stabilní aktualizace: během uplynulého týdne nevyšly žádné stabilní aktualizace a ani se žádné nerevidují.

Citáty týdne: Matthew Garrett, Linus Torvalds, fpletz

Není možné vyloženě říct, že mnoho distributorů Androidu již nemá právo distribuovat Linux. Ale nelze také vyloženě říct, že o toto právo nepřišli. Libovolný dostatečně motivovaný držitel autorských práv v jádře by se mohl pravděpodobně zapojit do značně efektivního nájezdu proti dodavatelům Androidu. Jestli to udělají, to se ještě uvidí, ale, upřímně, kdybych byl dodavatelem Androidu, měl bych obavy. Je zde řada lidí, kteří drží autorská práva na značné části jádra. Opravdu byste si vsadili, že všichni z nich jsou lidé s velkou ctí?

-- Matthew Garrett

Myslím si, že bychom se rozhodně měli podívat na naše postupy, ale já osobně přesto vkládám mnoho důvěry do „mezilidských vztahů“.

Často více než do „technických modelů“.

Takže obyčejné lidské „toto vypadá jako ten typ požadavku o přetažení, jaký očekávám“ je dosti bezpečné. Mnoho jaderných vývojářů píše hezké zprávy vysvětlující přetažení a v takovém textu nemusí být kryptografický podpis, ale je tam rozhodně „lidský podpis“, který pak začnete očekávat.

-- Linus Torvalds

Kernelroll je jaderný modul pro Linux pro pokročilé rickrollování. Funguje tak, že opatchuje systémové volání open() tak, aby došlo k otevření vybraného hudebního souboru namísto jiných hudebních souborů. Aktuálně hlídá jen příponu „mp3“ a následně zavolá původní open() s určenou cestou.

-- „fpletz“; zařazení do hlavní řady jádra není zaručeno

K multiplatformním ovladačům

napsal Jonathan Corbet

LWN se nedávno zabývalo diskuzí kolem přesunu bezdrátového ovladače Broadcom do hlavní řady ze staging. Tento ovladač vede k řadě otázek kolem toho, jak komunita jádra spolupracuje s výrobci hardwaru. Jeden důležitý aspekt této diskuze se ale zatím nedostal na povrch. Od ovladačů pro Linux se očekává, že jsou jen pro Linux. Pokusy o údržbu linuxového ovladače jako multiplatformního ovladače povedou z několika důvodů k neštěstí. Následuje článek, který zcela bez rozpaků zdůvodňuje, proč se multiplatformní ovladače do linuxového jádra nehodí.

S problémem přišel vývojář Broadcomu Henry Ptasinski, když psal o tom, proč společnost nemá zájem podporovat ovladač b43, který je v hlavní řadě jádra:

Ovladač brcmsmac je architektonicky v souladu s našimi ovladači pro ostatní operační systémy a máme v plánu tento ovladač udržovat souběžně s ovladači pro ostatní operační systémy. Údržba tohoto souladu mezi naším ovladačem pro Linux a ovladači pro jiné operační systémy nám umožní nabídnout podporu funkcí a čipů napříč platformami.

Vývojářům, kteří s jádrem už nějakou dobu pracují, toto zní jako elementární chyba. Ostatním ale přijde v pořádku: pokud chce Broadcom podporovat svůj hardware, proč je nenechat dělat to po svém?

Jednoznačným problémem při snaze udržovat „architektonický soulad“ s ovladači pro ostatní operační systémy je to, že jen původní firma je schopna tento soulad udržovat. Ostatní spolčené ovladače téměř jistě nejsou open source; nikdy jiný z komunity nemůže vědět, jaké změny jsou v souladu s těmito ovladači a jaké ne. Dokonce ani správce dotečného subsystému není schopen dělat taková rozhodnutí.

Je také nutné vzít v úvahu to, že většina ostatních vývojářů jádra není nijak motivována – a ani na tom nemá zájem – udržovat soulad mezi ovladači, i kdyby věděli, jak na to.

Jasným závěrem je to, že pokud máme ponechat výrobce, aby ve stromě jádra udržoval multiplatformní ovladač, tak musí mít nad kódem naprostou kontrolu. Pokud budou ostatní moci dělat libovolné změny, tak výrobce nebude mít šanci udržet ovladače konsistentními. Jenže v jádře nemá absolutní moc nikdo, leda s výjimkou Linuse Torvaldse. Pokud je třeba něco opravit nebo změnit, může to udělat kdokoliv s náležitými technickými schopnostmi. Pokud by kus stromu měl být obehnán plotem se zákazem vstupu pro vývojáře jádra, jádro jako celek by bylo o něco méně svobodné.

A na této svobodě záleží. Zvažme problém změny interního API. Jak všichni, kteří sledují vývoj jádra, ví, interní rozhraní se mění v jednom kuse následkem problémů a měnících se potřeb. Tyto změny mohou někdy znamenat velké změny pro uživatele dotčených rozhraní. Současná pravidla vyžadují, že vývojář, který dělá změnu v rozhraní, musí opravit veškerý kód, který tato změna rozbije. Kód, který je vyčleněn jako nepřístupný pro ostatní, bude těžké takto opravovat, což povede ke zpomalení rozvoje jádra jako celku. Jako příklad se můžeme podívat na odstranění velkého jaderného zámku (BKL); tento úkol si vyžádal významné změny v zamykání na mnoha místech. V průběhu bylo nutné změnit doslova stovky ovladačů. Odložení těchto změn by odstranění BKL ještě více zpomalilo – možná i znemožnilo.

Výrobci nejsou známí dlouhotrvající podporou svých produktů; nemají žádný dobrý důvod podporovat pět let starý čipset, který už neprodávají. Mají zajisté mnoho důvodů ukončit podporu a podporovat to, aby byl starý hardware nahrazen nablýskaným novým. Linux má ale tendenci podporovat hardware, dokud je používán. Tím, že bychom výrobci dali plnou kontrolu nad ovladačem, bychom jistě způsobili konflikt, jakmile by se výrobce rozhodl ukončit podporu starších čipsetů.

Plány výrobce se mohou lišit od potřeby komunity i v jiných směrech. Výrobci nemusí mít radost z patchů, které povolují nedokumentované funkce nebo zajišťují, že levnější produkty fungují jako jejich dražší alternativy. Nebo se podívejte na odpor Hanse Reisera vůči přidání podpory ACL a rozšířených atributů do reiserfs. Jeho argumentem bylo, že by uživatelé meli počkat na zbrusu nový souborový systém Reiser4, kde tyto funkce budou; kdyby jej ostatní poslouchali, tak by se uživatelé reiserfs těchto základních schopností souborového systému nikdy nedočkali. Jádro funguje, protože je spravováno tak, jak je dlouhodobě nejlepší pro uživatele, i když to někdy zapříčiní konflikty s krátkodobými touhami výrobce.

Multiplatformní ovladače od výrobců mají sklon k tomu být napsané kolem minimální sady funkcí dostupné na všech platformách. Výsledkem je spousta kódu, jenž duplikuje funkčnost, která už v linuxovém jádře je; vezměte si například kolik bezdrátových ovladačů mělo zpočátku vlastní vestavěnou podporu 802.11. Vývoj a údržba jedné solidní implementace 802.11 je obtížná; pokud bychom jich mělo v jádře několik, jádro by se nafukovalo a vedlo by to k řadě podřadných implementací – které by všechny musely být v budoucnu udržovány. Jinému podpůrnému kódu – od jednoduchých zřetězených seznamů po komplikovanou správu paměti – se multiplatformní ovladače rovněž často vyhýbají. Takové ovladače budou větší, chybovitější a pro vývojáře jádra obtížnější pro pochopení a podporu. Je u nich také mnohem menší pravděpodobnost, že by se chovaly konzistentně s jinými linuxovými ovladači pro stejný typ hardwaru.

Mimo vše výše uvedené je také zcela nejisté, že by údržba multiplatformního ovladače skutečně vedla k úspoře práce. Ovladače psané pro Linux mohou plně využívat veškerou podpůrnou infrastrukturu. Multiplatformní ovladače namísto toho musí duplikovat velkou část této funkčnost a také mudí udržovat abstrakční vrstvu nad operačním systémem. Udržovat multiplatformní ovladač znamená udržovat větší objem kódu bez pomoci komunity.

Abych to shrnul: snažit se udržovat jediný ovladač pro vícero operačních systémů se může na první pohled zdát jako dobrý nápad. Ale je to udržitelné jen ve světě, kde má výrobce naprostou kontrolu nad kódem. A i tehdy to vede k horšímu kódu, duplikaci vyvíjeného úsilí, problémy s dlouhodobou údržbou a celkově k většímu množství práce. Linux funguje nejlépe, pokud jsou jeho ovladače psané pro Linux a mohou být plně integrovány se zbytkem jádra. Komunitní vývojáři toto dobře vědí; to je důvodem, proč mají multiplatformní ovladače problém dostat se do hlavní řady.

Diskuse k tomuto článku

[tomo]

Ku tomu brcmsmac ovladacu by som len dodal ze som tym stastnym majitelom broadcom sietovky. Tudiz pravidelne sledujem ako na tom dany ovladac je. A smutne musim konstatovat ze pravdepodobne je kompatibilny s inymi operacnymi systemmi a dokaze sa vybuildit i v tom nasom linuxe. Na druhu stranu nieje pristupny (alebo aspon do nedavna vobec nebol) firmware ktory by dany ovladac zaviedol a tak mohol stastne multiplatformne fungovat.

Takze namiesto toho mam zavedeny nejaky binarny dvojmegovy kram ktory sa mi stara o sietovku a po 4-5 zmenach essid-u mozem akurat restartovat bo sa uz nejako nechyta. No a to ze treba pri kazdej mensej zmene cakat nato kym to niekto schopny z broadcomu zasa zkompatibilni...

[Ondrej 'SanTiago' Zajicek]

A neni jednodussi vymenit sitovku? Nova (treba od Intelu) vyjde na nekolik stovek a je po problemech.

[tomo]

Popravde toto ma to napadlo tiez tak som docasne kupil udajne podporovanu wifi do usb portu. Problem bol len v tom ze sa mi ovladac nezkompiloval voci recent kernelu (v tej dobe to bol tusim 2.6.39). Takze som sa chtiac nechtiac vratil ku boju s integrovanou.

Za druhe ide o notebook - samozrejme vymenit je mozne i tam ale ked uz na tom chlapci tak utesene robia...

Podla mna maju sancu udrzat ovladac napriec platformami iba po dobu ked bude v stagging akonahle "bude na ociach" tak so neho niekto nieco napise/ vyhodi a to uz zasa nebude kompatibilne z ich original ovladacom. A ak problem aspon trocha chapem tak nemozu len tak vystrihnut cudzi GPL kod a pichnut si ho do svojho uzavreteho ovladaca.

[Pali]

> A ak problem aspon trocha chapem tak nemozu len tak vystrihnut cudzi GPL kod a pichnut si ho do svojho uzavreteho ovladaca.

To som chcel prave napisat. GPL hovori nieco o derivative work, teda bud budu musiet otvorit aj ich windowsove ovladace pod GPL alebo nepouzit kod z linuxoveho kernelu - co ale uz nebude mutiplatformove...

[frr]

Mám pocit, že momentálně nejvanilkovější WiFi hardware je Atheros - PCI, USB, nejsem si jist nakolik i PCI-e. Konkrétní destičky hledejte u wifinářů: ASPA, i4wifi apod. Někteří lidé tvrdí, že hardware Mikrotik je lepší než ostatní značky (ačkoli to všem letuje třeba Wistron). Taková R52 mě pro běžné použití nikdy nezklamala - pod Linuxem ani pod Windows. Už jsem touto kartou nahradil spoustu podivných originálně dodaných wifin od značek jako je Via, Ralink apod.

[Luboš Doležel (Doli)]

Atheros R52 - tolik kernel panicků jsem ještě nezažil. Kamarádčin notebook s Windows mi dokázal server vždycky spolehlivě sundat

Pak jsem jí strčil do zakázaných MAC adres. Od té doby jsem neměl odvahu to znovu povolit.

[frr]

Žeby rozdíl spočíval v tom, že jsem R52 používal převážně jako klienta? Ta karta dokonce s ohyzdnou novotou zvanou CRDA nechce moc chodit v AP režimu... Jak je to dlouho, jaké jste používal ovladače, jakou verzi kernelu?

[Luboš Doležel (Doli)]

2.6.32, ovladač v jádře i aktuální z wireless-compat. A nikdy se mi nepodařilo tu kartu donutit používat všech evropských 13 kanálů. Zkusil jsem spoustu věcí, ale bez výsledku.

Teď tam mám 3.0.x, ale už se mi s tím nechce blbnout, jsem rád, že to běží.

[frr]

Jasně. Já se snažil naposled v 2.6.33.4. Od té doby nebyl čas a motivace. Jako jeden z nápadů na dlouhé zimní večery vidím "úplně vykostit CRDU". Právě aby ovladače povolily všechny kanály. Někde celou CRDU utnout hezky u kořene. Nastavit si country=CZ jako default ve zdrojácích kupodivu nestačí. Tuším jsem to někde četl, že s jinými ovladači není problém jet tu kartu v AP režimu na kterémkoli kanále (už si nepamatuju, jestli MadWifi nebo RouterOS). Aby mě někdo špatně nepochopil: mě nejde o to, používat nepovolené kanály. Mě jde o to, jet AP režim vůbec na nějakých kanálech - zejména na "povolených vyšších evropských". Třeba ČTÚ má mapu spektra celou přehledně čitelnou na webu, tak jaképak s tím softwarové vymyšlenosti. Celý tenhle regulatory softwarový blázinec je pěkná koule na noze. Zejména je natolik neintuitivní, že je prakticky nepoužitelný (zatím předpokládám, že je chyba spíš ve mně, že to není celé mozkově mrtvé, jak by řekl někdo méně trpělivý). Vnímám to jako opatření jak zařídit, aby se americký regulatory vlk (FCC?) nažral a open-source koza zůstala (skoro) celá. Že s tím zbytek světa bojuje, to hlavní vývojáře Amíky (žejo Linusi) nijak zvlášť netrápí. Asi je to prostě menší zlo.

[petr_p]

Nástroj iw umožňuje za běhu přepnout regulační doménu.

Definice regulačních domén má dva zdroje. Za prvé jednu tabulku můžete mít zakompilovanou přímo v jádře (CFG80211_INTERNAL_REGDB), za druhé tabulku můžete do jádra nahrát později nástrojem crda. Tabulka z uživatelského prostoru by měla jadernou přepsat. Integrace jde tak daleko, že když jádro údaje pro konkrétní doménu nemá, pošle netlinkem zprávu, tu zachytí udev a spustí crda, který jádru potřebné udaje dodá.

Pokud chcete mít regulační domény definované ještě před inicializací ovladačů rádií, zavádějte modul cfg80211 s parametrem ieee8021_regdom=CZ.

Z názvu modulu vyplývá, že regulační databáze je dostupná jen ovladačům, které používají infrastrukturu cfg80211, například ovladače nad vrstvou mac80211. Prakticky jsou to ty, které lze ovládat nástrojem iw. Dejete si pozor, že ovladače mimo hlavní strom si často vláčí vlastní historickou verzi mac80211, která s cfg80211 nemluví.

Nakonec je ještě třeba dodat, že existuje rozšíření 802.11 (mám dojem, že se schovává pod písmenem d), které umožňuje ápéčkám oznamovat identifikátor regulační domény nebo dokonce přímo frekvenční definici domény klientům. Takže pokud si někdo koupí router z dovozu, může se stát, že začne oznamovat blbosti. Oznamovaný kód lze najít na výpisu scanu nástrojem iw.

Jako úvod do problematiky doporučuji stránku na LinuxWireless.

[frr]

Ta externí REGDB, není v nějakém binárním formátu, nemusí být podepsaná? Pokud ano, dá se svévolně modifikovat? Ona věc stojí ale jinak: my nepotřebujeme hackovat REGDB. Defaultní REGDB obsahuje pro naši doménu správná data - není důvod záznamy modifikovat.

Horší je, že změna domény za chodu není úplně čistá. Ovladač si při startu usmyslí nějakou výchozí defaultní doménu. V případě ath5k a R52 EEPROMka indikuje, že ovladač má použít svůj default. A ovladač má ve zdrojáku natvrdo zadáno, že v téhle situaci defaultní doména je US. Pokud změníte doménu za jízdy na CZ, tak se prostě nevymění předpis pro US na předpis pro CZ. CDRA z obou domén vyrobí "společnou podmnožinu povoleného pásma". Fakt je, že jsem nezkoumal, jestli náhodou v našem případě tenhle průnik není identický s celou doménou CZ - ale obecně mi to leze krkem.

Má to řešení: v drivers/net/wireless/ath/regd.c je potřeba změnit zmíněný tvrdý default na CTRY_CZECH:

        if (reg->country_code == CTRY_DEFAULT &&
            regdmn == CTRY_DEFAULT) {
                printk(KERN_DEBUG "ath: EEPROM indicates default "
                       "country code should be used\n");
                reg->country_code = CTRY_CZECH;
        }

No a když jsem tohle všecko udělal, tak mi stejně R52 nechce na 5 GHz povolit AP režim. Všimněte si, že takové omezení v REGDB není přítomno (možná není ani kódovatelné? nebo ano?)

Co tam ještě schází? Zamítavý result kód vrací navenek CRDA. Ale mám podezření, že uvnitř za to může callback driveru ath5k, který se ještě navrch zeptá (opět) EEPROMky na kartě (a vrátí výsledek crdě). Tenhle callback je zmíněný v dokumentaci, měl by se jmenovat reg_notifier(). Takže odsud budu čenichat dál, až se k tomu zase dostanu

Ostatně jsem přímo tady na Ábíčku našel jeden konkrétní způsob

[petr_p]

Ta externí REGDB, není v nějakém binárním formátu, nemusí být podepsaná? Pokud ano, dá se svévolně modifikovat?

Pokud je crda přeložen s podporou kryptografie, pak přijímá jen podepsanou databázi. Veřejné klíče pro ověření lze doinstalovat vlastní. Postup je popsán na stránce, co jsem odkazoval.

CDRA z obou domén vyrobí "společnou podmnožinu povoleného pásma".

Ano, to je vlastnost. Výrobci zařízení se bojí, že by jinak nedostali od FCC certifikaci.

A ovladač má ve zdrojáku natvrdo zadáno, že v téhle situaci defaultní doména je US.

Z hlediska softwaru to je chyba. Z hlediska výrobce hardwaru to je vlastnost. Výrobce občas umožňuje hodnotu v EEPROM přeprogramovat. Samozřejmě z hlediska uživatele to je opruz. Napiš autorovi ovladače (nebo do mailing listu), co se s tím dá dělat.

[Majk]

Hoši, co se to tam stalo???

[pepazdepa]

broadcom ovladac je napsan pod NDA? pokud vyrobce poskytne dokumentaci pro vyvojare, tak si snad napisou vlastni ovladac a mohou (na)tlak vyrobce preposlat do patricnych mezi.

[osel]

Podle mě jsou jedinými problémy vývoje multiplatformního ovladače jeho začlenění do jádra a zpětně nekompatibilní změny použitých funkcí. Všechny ostatní věci v článku se dají bez problémů vyřešit. Třeba duplikace kódu, tak jak je popsaná v článku, je důsledkem špatného vývoje a rozhodně to není věc, která musí být v každém multiplatformním ovladači. Ale pokud by byli ovladače mimo jádro, tak by to vlastně znamenalo odklon od monolitického kernelu (museli by se definovat veřejná rozhraní pro připojení ovladačů).

[Luboš Doležel (Doli)]

Já si myslím, že nejlepší bude, když si ty svoje ovladače budou udržovat mimo jádro, zatímco komunita si bude v klidu hackovat "normální" ovladač.

[j]

Zjevne si to nepochopil, vem si nasledujici situaci:

system A podporuje funkci X system B ji nepodporuje

=> funkci X si musim do ovladace napsat. Mam dve moznosti - bud napisu extra volani ty funkce pro kazdy system zvlast (= pro me 2x prace), nebo to napisu jednou, protoze tu funkci sem si stejne dopsal. To ale bude znamenat, ze v systemu A se bude zbytecne volat moje funkce, kdyz system ji ma v sobe primo. Navic kdyz nekdo v systemu A zmeni volani X, tak bych musel prepisovat ovladac, coz takhle nemusim => presne jak je v clanecku to vede k pouzivani nezbytne nutnyho minima spolecnych funkcionalit a k nesmyslne obrovskym ovladacum.

Pokud bych sel tou pro me pracnejsi cestou => ze si napisu to volani pro kazdej system extra, tak uz neni zadnej podstatnej rozdil v napsani samostatnyho driveru pro kazdej system (kterej muze pripadne sdilet nejakou cast zdrojaku).

IMO vubecnejlepsi cesta by byla napsat driver pro rozsireny systemy + zverejnit nejakou rozumnou dokumentaci k tomu zelezu a pripadne nejaky nastrel zdrojaku, on uz se nekdo najde kdo to napise.

[Mordae]

Jo, souhlasim. Zverejnit komplet dokumentaci k HW a wokenni ovladac, on to na Linux uz nekdo naportuje.

[lertimir]

To je pravda, ale je pár vyjímek, Ve většině případů, když je ovladač sice méně efektivně implementován, ale správně, nic se neděje, hardware utlačí tu menší efektivitu. Ale grafické karty potřebují maximální efektivitu datových toků. Tam je vidět že bloby nvidie i AMD jsou výrazně rychlejší než komunitní ovladače. A AMD specifikaci uvolnila.

[jdsulin]

add b43 .. tady je zrovna situace celkem jednoducha. Kdyz uz je broadcom tak mily a zverejni zdrojove kody pro svou sitovku, pak nevidim duvod pro to, proc nemit ovladace 2. Jeden podporovany jako modul od broadcomu, s otevrenym zdrojovym kodem (klidne i pod necim jinym nez GPL) a druhy v jadre. Nejen, ze by ten v jadre podporoval i starsi sitove karty, ale mohla by do nej byt pretahovana podpora pro nove chipy a broadcom by si zachoval kontrolu nad svym ovladacem, vzdyt tak se to prece dela vsude ne ? Navic specialne u wifi karet - jejich pouziti je hlavne u wifi routeru a notebooku a tam je hlavni duvod funkcnost, vsem je jedno, jak a proc a jaka licence, kdyz se nepripoji na internet, tak tam stejne nakonec nahraji ovladac pres ndiswrapper. A co se tyka licence, pak neni na co si stezovat, ovaladace maji otevrene zdrojove kody. Jediny kdo si muze stezovat je tak maximalne Richard Stallman, ze nevi jak je navrzeny chip uvnitr.

[Mmad]

Průser je aktuálně jinde. M$ chtějí blokovat Linux pomocí podepisování UEFI - a bez podpisu se to prý nerozjede!
Návrh: Někdo koupí dostatek strojů s touto ochranou a pak je hodí výrobci na hlava pro a) nesouhlas se smlouvou M$ (nepotěšíte Ballmera), b) vázaný prodej (zdraví ČOI) a c) nemožnost nainstalovat jiný OS, který splňuje specifikaci, ale není podepsán (nakrknete dodavatele výrobce). V nejhorším hacknout certifikáty nebo napsat vlastní svobodnou implementaci UEFI a pak nechat manuálně aktualizovat chipy (nakrknete všechny).
Totální finále by ale asi bylo postavit si vlastní architekturu, která by byla kompletně pod svobodnými licencemi.

[Mmad]

Tak sorry, koukám, že už to tu drbete.