BreezyBox je open-source shell a virtuální terminál pro populární jednočip ESP32. Nabízí základní unixové příkazy, sledování aktuálního pracovního adresáře (CWD), jednoduchý instalátor a spouštěč aplikací v podobě ELF binárních souborů, zabudovaný HTTP server nebo třeba ovládání WiFi - ukázka použití coby 'malého osobního počítače'. Ačkoliv je BreezyBox inspirovaný BusyBoxem, oproti němu má tento projekt několik externích závislostí, zejména na ESP-IDF SDK. BreezyBox je dostupný pod licencí MIT.
Byl představen cross-assembler xa.sh, napsaný čistě v Bourne shell skriptu. Tento nástroj umožňuje zpracovávat assemblerový kód pro Intel 8080, přičemž je možné snadno přidat podporu i pro další architektury, například 6502 a 6809. Skript využívá pouze různé běžné unixové příkazy jako jsou awk, sed nebo printf. Skript si lze stáhnout z GitHubového repozitáře projektu.
Byla představena nová verze modelu Claude Opus 4.6 od společnosti Anthropic. Jako demonstraci možností Anthropic využil 16 agentů Claude Opus 4.6 k vytvoření kompilátoru jazyka C, napsaného v programovacím jazyce Rust. Claude pracoval téměř autonomně, projekt trval zhruba dva týdny a náklady činily přibližně 20 000 dolarů. Výsledkem je fungující kompilátor o 100 000 řádcích kódu, jehož zdrojový kód je volně dostupný na GitHubu pod licencí Creative Commons.
Kultovní britský seriál The IT Crowd (Ajťáci) oslavil dvacáté výročí svého prvního vysílání. Sitcom o dvou sociálně nemotorných pracovnících a jejich nadřízené zaujal diváky svým humorem a ikonickými hláškami. Seriál, který debutoval v roce 2006, si i po dvou dekádách udržuje silnou fanouškovskou základnu a pravidelně se objevuje v seznamech nejlepších komedií své doby. Nedávné zatčení autora seriálu Grahama Linehana za hatecrime však vyvolává otázku, jestli by tento sitcom v současné Velké Británii vůbec vznikl.
Společnost JetBrains oznámila, že počínaje verzí 2026.1 budou IDE založená na IntelliJ ve výchozím nastavení používat Wayland.
Společnost SpaceX amerického miliardáře Elona Muska podala žádost o vypuštění jednoho milionu satelitů na oběžnou dráhu kolem Země, odkud by pomohly zajistit provoz umělé inteligence (AI) a zároveň šetřily pozemské zdroje. Zatím se ale neví, kdy by se tak mělo stát. V žádosti Federální komisi pro spoje (FCC) se píše, že orbitální datová centra jsou nejúspornějším a energeticky nejúčinnějším způsobem, jak uspokojit rostoucí poptávku po
… více »Byla vydána nová verze 2.53.0 distribuovaného systému správy verzí Git. Přispělo 70 vývojářů, z toho 21 nových. Přehled novinek v poznámkách k vydání.
Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 216. sraz, který proběhne v pátek 20. února od 18:00 v Red Hat Labu (místnost Q304) na Fakultě informačních technologií VUT v Brně na ulici Božetěchova 1/2. Tématem srazu bude komunitní komunikační síť MeshCore. Jindřich Skácel představí, co je to MeshCore, předvede nejrůznější klientské zařízení a ukáže, jak v praxi vypadá nasazení vlastního repeateru.
Byla vydána nová major verze 9.0 multiplatformní digitální pracovní stanice pro práci s audiem (DAW) Ardour. Přehled novinek, vylepšení a oprav v poznámkách k vydání.
Hodnota Bitcoinu, decentralizované kryptoměny klesla pod 70 000 dolarů (1,44 milionu korun).
O standardu ACL byla na stránkách AbcLinuxu.cz již řeč (ACL prakticky). V tomto článku si situaci trochu upřesníme.
Tak o tomto formátu ACL jsme již zde mluvili, takže jej nebudu po funkční stránce dále rozebírat. Je to v podstatě nerozšířenější formát ACL (v Linuxu určitě). Jeho problémem však je, že (jak už sám název této kapitoly napovídá) následuje jen draft doporučení - žádná jasná specifikace RFC pro toto neexistuje, takže těžko předpovídat, jak se tomuto formátu bude do budoucna dařit.
V Linuxu ovšem nemusíme mít obavy, tam (jak už jsem řekl) je jasným vítězem. I co se týče podpory klasických souborových systémů (ext3, reiserfs, cokoliv_dalsiho) v podstatě nenalezneme problém, všude je tento typ ACL podporován. Jak to ale vypadá s jeho kompatibilitou s nejrozšířenějšími síťovými filesystémy? Na to se podíváme trochu podrobněji.
Není jistě tajemstvím, že i Windows znají přístupová práva (NTFS ACL), a je nutno přiznat, že co do bohatosti se jim POSIX ACL nemůže rovnat. Právě proto není pro Sambu větším problémem tato ACL namapovat na příslušná NTFS ACL. Opačně už samozřejmě problém je - např. pokud kopírujeme soubor z NTFS disku na SAMBA share, konverze ACL je ztrátová a výsledek nemusí být zrovna uspokojující.
Faktem ovšem zůstává, že Samba tuto konverzi zvládá vcelku pěkně a bez zbytečných cavyků - nic není třeba zapínat, vše funguje ve výchozím nastavení.
Jak to vlastně vypadá s podporou ACL u rodiny protokolů NFS?
Protokol nepřenáší ACL atributy. NFS klient provádí kešování za účelem zvýšení výkonnosti. Toto kešování bere v úvahu pouze klasická Unix přístupová práva. Použití ACL může v tomto případě vést až ke ztrátě dat.
Nejrozšířenější typ NFS - definuje nový typ ACCESS dotazu pomocí RPC které řeší nebezpečí ztráty dat při použití ACL. Protokol jako takový však nepřenáší atributy ACL. Linux toto zajišťuje pomocí sideband protokolu rpc-statd, který se mimo jiné stará i o zamykání souborů po NFS. Tento protokol se bohužel víceméně také neopírá o žádné doporučení - to znamená, že Linux-klient si s Linuxem-serverem porozumí, ale mezi různými OS to pravdě podobně nebude fungovat.
Nástupce rodiny NFS verze 2 a 3 standard POSIX ACL vůbec nepodporuje - NFSv4 definuje vlastní formát ACL (včetně jeho přenosu), který se svým konceptem velmi blíží Windows ACL. Jakýkoli POSIX ACL atribut lze tedy vyjádřit pomocí NFSv4 ACL atributu, ale obráceně to nejde.
Ačkoli Linux od verze jádra 2.6 podporuje NFSv4, operační systém samotný tyto ACL „nevidí“.
AFS používá svoji vlastní implementaci ACL, která není podobná ničemu výše uvedenému. AFS má ACL jen pro adresáře a soubory tedy dědí přístupová práva podle toho, do jakého adresáře patří.
Jen pro úplnost dodávám i informaci ohledně nejznámějšího FS pro clustery tlačeného firmou Red Hat a vývojového FS budoucnosti od Oraclu. Tyto FS používají (stejně jako Ext3) pro ACL rozšířené atributy (xattr) souboru, tzn. POSIX ACL atributy jako základ, ale NFSv4 ACL by také neměly představovat problémem.
Z výše uvedeného je jasné, že určit jakýkoli směr vývoje ACL pro unixové systémy v budoucnosti je těžké. Já osobně si myslím, že klasické ACL POSIX atributy budou postupně nahrazeny ACL podle NFSv4, protože (kromě jiných předností) nabízejí větší kompatibilitu s Windows ACL a jsou založeny na standardech. Při nasazování ACL bychom ale neměli zapomínat na aplikační úroveň - např. při zálohování pomocí cpio nebo tar o ACL atributy přijdeme - stejně tak při kopírování souborů pomocí programů, které příslušnému typu ACL nerozumí.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
no strucnejsi to trochu je, ale bida to podle me neni.
12.2.2009 07:38
Lukáš Benda | skóre: 12
| blog: benBlog
| Štítina
Bohuzel nepoznam jestli autor tady pise nesmyly (jako se casto stava treba na rootu), ale pokud si primo nevymysli, tak pro mne je to pomerne pekne a rychle dostupne vstupni info. Aspon clovek vidi ze pokus o kompletni ACL z Windows na Linux je dosazitelny jen s tezkostmi (jestli vubec) a vidi i proc.
P.S.: Neni nejaky FS, ktery by umoznoval jak ACL podobne Windows tak to co ma Linux a udrzoval to dualne? To znamena, ze kdyz k systemu pristoupim z linuxu ACL se mi redukuji jenom na standardni Linuxove, ale kdyz to budu chtit sdilet napr. pres Sambu budou se mi prenaset kompletni?
Co hledáš je pravděpodobně FS s NFSv4 ACL + nějaká nejnovější distribuce Linuxu. Mělo by to fungovat tak, že atributy na disku uloženy ve formátu NFSv4 a konverzi na POSIX (pokud je potřeba) provádí libc.so. Ale jak říkám, v současnosti to asi nebude ještě fungovat, je to spíše hudba budoucnosti.
Mě se ten článek líbí. Informačně mi pomohl. Chtěl bych vidět, co napsal ten chytrák, který tvrdí, že je to bída. Už jsi zkusil někdy něco sám napsat chytráku? Napsat pár smysluplných vět zabere i několi dnů zkoumání a přípravy. Kromě toho, dobrý technik se vyjadřuje jasně a stručně.
Rychlé, stručné shrnutí bez přílišných keců okolo, díky :)
Tak tady bych to upřesnil:
RW přístup do souborového systému přes NBD samozřejmě jde, ale musíte na to mít uzpůsobený filesystém - tzn né Ext3, ale GFS kde možno mít více žurnálů. Co se rychlosti týče bych byl ale skeptický - každý lepší síťový FS dělá optimalizace, které si NBD nemůže principielně dovolit, takže pokud srovnám NFSv4 s agresivním kešováním na straně klienta i serveru, tak NBD bude vždy pomalejší.
Ale to už je námět na zvláštní článek....
Tohle mě docela zajímá... Je možné mít připojené 1 blokové zařízení (sdílené přes nbd, iscsi nebo třeba AtaOverEthernet) připojené na více místech pro zápis, pokud se použije nějaký cluster filesystem.
Má někdo přehled jaká je v Linuxu obecně situace? Existuje GFS, ale použitelné je to asi jen na RHEL, pak Oracle OCFS2 - na ten jsem viděl i HOWTO pro Debian. Ve spojení s DRBD to může být zajímavé.
Pak mě docela zaujal glusterfs - umí mirror / stripe ap. přes síť, ale není to klasický filesystem - funguje přes FUSE třeba nad ext3 a výkon má být dost zajímavý. Podle referenčních nasazení vypadá docela použitelně. Má s ním někdo zkušenost?
Co jsem si ale všimnul, tak OCFS asi glusterfs nemají podporu právě pro ACL, což je pro mě docela omezující.
Tým, že je GFS/GFS2 vo vanila jadre, tak by s jeho použitím nemali byť žiadne väčšie problémy ani inde ako v RHEL. Z bugzilly a mailing listu som si istý minimálne Debianom.
14.2.2009 20:29
onion | skóre: 8
| blog: onion
| Praha
Nasazoval jsem GlusterFS na takovém "mini-clusteru" (3 stroje, kapacita 4.6TB), běží tam asi 1,5 měsíce a zatím spokojenost. Mám je propojené 1Gbit LAN sítí a frčí to kolem 70MB/s (zápis). Problém byl, když to na začátku bylo spojené jen 100Mbitem, zápis se plazil ~3-4MB/s, ale Gbit to spolehlivě vyřešil.Pak mě docela zaujal glusterfs - umí mirror / stripe ap. přes síť, ale není to klasický filesystem - funguje přes FUSE třeba nad ext3 a výkon má být dost zajímavý. Podle referenčních nasazení vypadá docela použitelně. Má s ním někdo zkušenost?
Díky za informace. V Debianu jsou balíčky jenom v sid větvi a ještě dost stará verze.
Problém s ACL je snad v tom, že je nepodporuje / nepodporoval FUSE. Pokud budu sdílet Sambou adresář, který je v gluster AFR, tak ACL možná půjde používat, ale nepřenesou se na druhý server. ACL bych potřeboval asi jen v případě exportu přes Sambu, jinak to není takový problém.
GFS1 je pomaly, pri vice clienetech, je pomalejsi nez NFS server, ale videl jsem jej nasazen na clusteru 8web serveru a slo to, pokud clovek nevylistovaval soubory a vice cetl nez zapisoval.
GFS2 je na tom lip, videl jsem na tom jet SAP/R3 s Xenem, ale jelo to jenom na jednom nodu, druhy byl jako "aktivne pasivni" 
) Pokud GFS2 aktivne vyuziva jen jeden node, je vykon velmi slusny. Benchmark vice stroji u GFS2 neznam, testoval jsem to z 2 stroji pres GFS2 a cLVM2 ... fungovalo to dobre, moc jsem to ale nezkoumal na detailni benchmarky, DD na to psalo normalne.
Na tohle by měly stačit i POSIX ACL, které na ext3 fungují bez problémů. Podívejte se ještě na sticky bit na adresářích, který řeší právě to, aby uživatel mohl do adresáře volně přidávat, ale nemohl v něm mazat / měnit cizí soubory.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz